ArKaNeMaN, Конечно можно, лишь бы в пользу.
1. Твой способ относительно правильный. Но, хранить в pev entity нужно не всякую чушь, а важную информацию, которая будет доставаться реже, чем в твоём синке. Допустим, если бы ты разрабатывал целое API то, мог бы действительно хранить какие-то важные данные в pev. А тут - инфа и не нужна никакому другому плагину (компоненту).
Пример, когда действительно стоило хранить что-то в pev storage для удобства я видел в
Haloween Mod от
Hedgehog Fog. Рекомендую к ознакомлению, это один из модов, где я видел использование pev с пользой. Наработок несколько и всех сразу не припомнишь.
Но, главное, по пустякам не дёргать цепочку amxmodx -> fakemeta -> metamod.
Ибо путь не самый лучший учитывая универсальную нативу:
https://github.com/alliedmodders/am...a862fa8a97/modules/fakemeta/pev.cpp#L160-L343
Некоторые данные, можно не стесняясь хранить в массиве, однако подходит такой метод не везде. По обстановке так сказать.
2. #include <file> - какой практический толк от этого? Учитывая это:
https://github.com/alliedmodders/amxmodx/blob/master/plugins/include/amxmodx.inc#L19
3. Какой замысел использования static типа переменной в локальной функции здесь?
4. Ты немного не верно понял мой посыл с кварами и их поинтерами.
Я не понял, а зачем вам в плагине pointer'ы на CVar'ы вообще?
ArKaNeMaN написал(а):
Убраны 'pointer'ы на CVar'ы'
Имелось ввиду: зачем тебе поинтеры,
если ты их не используешь? Пользуйся ими без опаски - это полезно.
Ты создал CVar'ы и снял их значения на старте карты. Без возможности изменения. Получается главное преимущество CVar'а загубил.
CVar - Console Variable. Консольная
переменная. То есть, мы можем её менять и она будет учитываться в дальнейшем использовании. Во всём движке и игре есть множество кваров, которые именно для этого и задуманы. 90% CVar'ов ты можешь спокойно менять "на лету".
В твоей же реализации: ты сделал константы, которые юзеры зачем то указывают в конфиге, а должны указывать в исходном файле перед компиляцией. (Да, не нужно производить плагины для глупого контингента, к хорошему не приведёт.).
К конкретике: Сделай CVar'ы только для необходимых настроек, которые нужно будет менять на протяжении игры, или же от карты к карте с помощью AMXX. К примеру, захочет человек на время повысить шанс выпадения подарка.
Квары,
достойные "горячей" смены:
- awDgDropRarity
- awDgTimeout (наверное, AwDgLifeTime ?!)
- awDgMoneyMin
- awDgMoneyMax
Не понятно, зачем вообще являются кварами:
- awDgModelPath (есть вероятность, конечно, что пригодится от карты к карте менять модель подарка... но... вряд ли)
- awDgChatPrefix - в каком случае понадобится его менять вообще после компиляции?
и там где это необходимо - не бойся использовать get_pcvar_* (получать значение квара по поинтеру.
Оно ничего не стоит для вирт.машины.
А, ещё лучше - откажись от поддержки старого AMXX 1.8.2 в пользу нового AMXX 1.8.3 и его новых функций, которые позволят тебе всегда держать в переменных актуальные данные из CVar'a. Ибо там появились нормальные хуки кваров.
create_cvar,
bind_pcvar_*, в этой реализации можно заранее указать clamp (ограничение диапазона), описание квара, а так же автоматическое развёртывание в конфиг значений средствами AMXX. (
AutoExecConfig(true)). Пример реализации смотри тут:
https://dev-cs.ru/resources/296/
Сам Arkshine говорил, что несколько расстроен тем, что AMXX 1.8.3 не используют активно (и не дают репортов и предложений), хотя те, кто разрабатывают его стараются обновлять не ломая совместимостей. Так помогайте же развивать AMXX 1.8.3 пересаживая пользователей с их глупыми догадками на стабильный AMXX 1.8.3. Это отдельная тема для разговора, заслуживающая времени.
5. Используй константы, делай читабельнее код, чтобы другим не было противно копаться в нём.
https://github.com/alliedmodders/amxmodx/blob/master/plugins/include/file.inc#L27-L30
Если увижу желание автора исправлять плагин - подскажу ещё несколько... а пока и этого хватит.
