Пока подбирал подсветку синтаксиса, пришёл к выводу, что нужно менять сам синтаксис работы с переменными. Ниже пример кода и подсветки. Функция добавляет отряд в гарнизон текущего города или гарнизонного героя.
https://yadi.sk/i/u0ob72jMpB-cQA
Ниже пример кусочка старой функции из моего скрипта Call to arms, а затем его современной версии:
https://yadi.sk/i/nU8z2D2HDe7vMQ

Berserker, So will the code be even easier to write? I'm glad to know that Berserker are always there to make life easier for us

V_Maiko, and easier to read/understand, like in ordinary programming languages.

Berserker, напомни, не происходит ли коллизий, если в разных триггерах под одним и тем же именем объявляются переменные в первом случае - v, во втором - y?

(27.03.2020 08:27)Berserker Wrote:  V_Maiko, and easier to read/understand, like in ordinary programming languages.

Спорно. Для профессиональных программеров, возможно, более читаемо, но для многих других, когда код текста по большей части состоит из названий переменных, сама суть совершенно теряется в этой мешанине.

Возможно, проблема "растворения" сути кода и, как следствие, снижение восприятия в том, что команды в ЕРМ разбиты на 2 части и разнесены по строке. Будь они только в начале или просто одной не_однобуквенной_строкой, читалось бы легче:

!!VRy3:Vz2;
!!VR(dwellingType:y):V(dwellingTypeStr);
StrToInt(dwellingTypeStr,dwellingType);
(dwellingType)=StrToInt(dwellingTypeStr);

Algor, все переменные локальны, кроме v, которые тоже выделяются локально, но должны быть использованы на как можно меньшее время, чтобы другой триггер их не перезаписал.
Я долго подбирал подсветку под $...$, @...@, но выходит такая нечитаемая каша символов + необходимость постоянно префикс указывать + слишком яркий акцент на каждой сущности. Попробовал писать и понял, что неудобно. Потому прорефакторил правила имён констант, функций, переменных. Отделил объявление переменной и использование. Теперь опечатки гораздо проще находятся (ошибка при компиляции скриптов), а переименование идентификаторов происходит легче. dex.DoIt для sublime — два слова без единой индексации, dex_DoIt как функция — один. Сделал явные ограничения, что имена переменной с функцией или константой невозможно спутать ни человеку, ни компилятору.

Код читается легче в редакторе, где подсветка команд и оттенки (белый/серый, тёмно-зелёный/светлозелёный) упрощают навигацию по ресиверу и командам для получения основного смысла, а чтение имён переменных в качестве параметров происходит легче. Тут нужно попробовать, чтобы судить, наверное.

Berserker, по приведенному коду, скажи что именно выводится в обоих случаях.
А то фраза "кроме v, которые тоже выделяются локально, но должны быть использованы на как можно меньшее время, чтобы другой триггер их не перезаписал." у меня оставляет вопросы и сеет легкую панику..

По читаемости, думаю, всё же будет проблема, т.к. односимвольная команда ресивера на фоне предшествующих длинных имен не будет бросаться в глаза, хоть каким цветом выделяй ее.
Но тут лучше раз увидеть. Есть скрин?

Два скрина в посте по ссылкам же. Только скрины ужасны из-за jpeg + цветая субдескретизация (chroma subsampling), портящая оттенки. Цвет переменных как сейчас цвет функций в коде. Один для всех. Команды чуть ярче стали.

Локальные переменные локальны конкретному триггеру до следующего !?.
Нельзя объявить одновременно две переменные с одним именем, но разными типами/длиной массива (но можно с одним и те же).

Теперь все понятно, спасибо. Останусь на у в качестве локальных мне так привычнее и короче. Ну и SN:W с массивами для глобального использования.

Смотри сам, конечно. Тут практика — критерий истины.
Такой вариант хуже читаем на мой взгляд.

Полностью убраны ограничения на имена и кол-во *.ers файлов.

Есть вопросы/возражения по стандартному таймеру для Эры 3.0?
era_OnEveryDay
Доступны 4 аргумента: день, день недели, флаг единократного выполнения для текущего дня, ИИ?(1/0).

Конечный вариант на текущий день. Событие OnEveryDay, x-параметры установлены через ЕРМ.

I have no problem with new code interpretations, as long as it is compatible with old code there will be no problem for veteran modders who don't want to leave their old modalities. And most importantly, try not to lose more old mods that were wonderful, like Seer Huts, Display Events, and others that are from Valery that that are now obsolete..

Old mods are supported. New syntax is turned on by ZVSE2 signature on the first line.