Berserker, у тебя в примерах константы типа ARR_AUTO, PM_LMB_PUSH и пр. определяются пользователем или захардкодены?
В первом случае - это потенциальные коллизии, во втором - требуется справочник констант, что может быть более неудобным.
Поясню:
ARR_TEMP - соответствует 0 (массив не сохраняется)
а как будет 1 - "массив сохраняется"? ARR_CONST? ARR_PERM? ARR_STATIC? Ну вот, лезть в справочник...
PM_LMB_PUSH? или PM_LMB_PRESS или MOUSE_BUTTON? Да фиг я буду помнить названия большинства констант, если не сам их строкой выше определил
Я до сих пор психую и использую !?PI вместо onAfterERMInstruction... или onPostInstruction... или <еще 2-3 варианта>.... да ну его нахрен, пусть будет !?PI. Иногда даже с учетом подсказки редактора попадаю не с первого раза, если недавно не использовал.

Получение Ид массива сразу при автовыделении - здорово.
В UN:U максимум 12 значений задать можно?

Есть еще один весьма напрягающий момент - разнообразие нового синтаксиса при работе с переменными.

Если раньше все было просто
?v# - сохранить значение в переменную
v# - использовать значение из переменной
в некоторых командах # - сохранить значение в переменную v# или z# (что уже нестройный остыль)
%V# - подстановка значения в строку

то теперь к ним добавляются
i^^
blabla:y
$blabla$
(blabla)
+ отдельно массивы (но тут вопросов нет - это новая сущность)
и, вроде, что-то еще упустил

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

Предлагаю :

обычные или (именованные) переменные
?v#, ?v(bla), ?z#, ?z(bla)
v#, v(bla), z#, z(bla), x#, x(bla), y#, y(bla)

переменные из json (только использование значений, без подстановок)
t(key)

элементы массива и переменные героя
?mi(#,#), ?ms(#,#), ?w#, ?w(#,#), ?w(HERO_ORRIN,#)
mi(arrname,#), ms(arrname,#), w#, w(#,#), w(HERO_ORRIN,#)

флаги (есть ли вообще смысл продолжать их использовать?)
?f#, ?f(bla)
f#, f(bla)

Строковые подстановки
%V#, %V(bla), %Vi,
%Z#, %Z(bla),
%Y#, %Y(bla),
%X#, %X(bla),
%T(key),
%Mi(#,#) %Mi(arrname,#), %Ms(#,#) %Ms(arrname,#),

Индексы (желательно)
vy1, xy(bla), vz(bla), mi(z(bla),y(bla))

Строковые подстановки с индексами (вот уж не знаю насколько целесообразно, но было бы просто обделаться как круто )
%T(%Ms(%Z(bla),%W(HERO_ORRIN,%X16)))

При желании, можно разнести строковые и целочисленные массивы по разным литерам:
!!VRm(bla,3):С4/5/6/7;
!!VRa(bla,5):S^six^;
!!IF:M^%A(bla,5) %M(bla,5)^; six 6

Чтобы не ломать/городить совместимость, сделать это только для ZVSE2, пока на нем еще ничего не написано.

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

(30.03.2020 20:25)Berserker Wrote:  wessonsm, и это заложенные мины.
Скажем, события TL и OnKeyPressed могут возникать в любых диалогах, включая в IF:G, IF:M и т.д. Ты не ожидаешь, что v600.v602 изменятся, а они меняются. Во всех ЯП давно пришли к мысли, что глобальное — источник ошибок.

Berserker, хочу прояснить для себя.
В таком случае f..t тоже нежелательно использовать? Они ведь тоже глобальные?

wessonsm, да, быстрые переменные безопасно можно использовать только внутри одного триггера. Или для передачи/получения данных в/из функции, которую в этом же триггере и вызываешь.
Передавать данные между триггерами небезопасно, т.к. при выполнении промежуточных триггеров они могут быть изменены.

Algor, я и имел в виду использование внутри одного триггера или даже внутри функции.
Но чем тогда отличается использование v1..v10, v600..v699 от использования f..t?
Я всегда думал, что это практически одно и то же.
Может все-таки риски не такие уж большие?
Ведь как я понимаю, для возникновения ошибки мало, чтобы во время выполнения скрипта сработало другое событие (TL или OnKeyPressed), нужно еще, чтобы к этому событию был привязан скрипт, который изменяет те же самые глобальные переменные, что и мой.
А скриптов, использующих TL или OnKeyPressed, на пальцах пересчитать.
Просто эти переменные очень удобны для передачи значений между внешней и вложенной функцией например, передавать все через x-параметры гораздо геморройнее..
SN:W конечно, но чтобы производить с ними какие-то действия, нужно сначала прочитать значение в переменную, а потом опять записать, тогда как с v-переменными это все делается напрямую, что опять-таки удобно.

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

(31.03.2020 09:40)wessonsm Wrote:  В таком случае f..t тоже нежелательно использовать? Они ведь тоже глобальные?

Я вообще ими никогда не пользовался (за весь свой опыт скриптописания (лет так восемь, наверное)). Ни разу! Потому что не вижу в них никакого смысла.
v переменные прекрасно выполняют данные требования.

... а "внутри одного триггера или даже внутри функции" лучше вообще пользоваться y-переменными. Они на то и есть "локальные".
f..t от v1..v10 почти ничем не отличаются. Некоторые ресиверы используют только v:

igrik, я тоже очень долго не пользовался. Сейчас же использую, но исключительно в качестве совсем временных, буквально на несколько строк.
Ну и i в циклах это просто классика. Т.е. примерно так:
Очевидно, что все быстрые переменные дальше цикла не используются.

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

В общем, ребята, я понял вас так, что "можно, только осторожно". Осознавая возможные последствия, так сказать)
А вот Berserker говорит, что вообще нежелательно.
Выводы я для себя сделал, буду стараться избегать их использования, насколько это возможно, но полностью из инструментария их пока не исключаю.

Algor, по константам:

1) Файл 1000 era - consts.erm
Там всё по группам.
+ я в erm_consts.sublime-completions добавляю, чтобы память не нагружать.

Большинство констант из английского файла помощи. Думаю буквально немного добавить для команд Эры вроде SN:M. Там три варианта сохранения массивов и два типа данных, например. Эти 0/1/0/1/1/0 напрягают изрядно.

2) По переменные уже закончил. Макросы обычно не используются, потому синтаксис либо старый, для уже существующих блоков кода, либо i^^, s^^ именованные глобальные, либо (локальные). Локальные раскрываются как константа прямо в месте использования. Так что y(itemPtr) вполне нормальная замена для yy17. Одна лишь разница, что при первом использовании локальной переменной нужно указать её тип. Но при этом отслеживаются автоматом опечатки. Ты не сможешь опечататься и использовать несуществующую переменную.

-------------------------

Быстрые переменные теперь локальны. Своя копия для каждого события.

Algor, по UN:U я наврал, исправляюсь:

[+] Added VR:C alternative for SN:M arrays. New command !!SN:U#1/#2/$3...up to $21 allows to set/check/get/modify
    many items of dynamical array.
    #1 - SN:M array ID.
    #2 - starting index
    $3... - items at starting index, starting index + 1, starting index + 2, etc.

Массивы именно прекомпиляцией в голый ЕРМ не сделаешь, так что пока через SN:M/U к ним доступ.

Из хороших новостей. ERT-хранилище переписано. Вместо линейного поиска строки с указанным ERT-индексом используется двоичное дерево поиска. Сняты ограничения на макс 50000 ERT строк. И скоро должно заработать такое:

Berserker, а само тело ф-ции !?FU(ShowDialog); самим надо будет прописывать, или это некая универсальная уже будет?