(04.03.2020 16:34)Berserker Wrote:  daemon_n, при тестировании ни разу не замечал какой-либо загрузки сторонних скриптов. Ты точно ничего не напутал в сборке? )

Проверил на чистой Эре, Вог скриптах и героях.

1. Выбираем одиночную игру, настраиваем скрипты и сохраняем.
2. Выбираем кампанию
3. Скрипты грузятся из сохранённых.

daemon_n, тоже проверил, не подтверждаю. Какая кампания?
Единственное, что у меня при загрузке сейва из «во имя богов» сообщение об отсутствующем ресурсе.

Berserker, странно, проверил ещё раз - повторить не удалось
Кампания "Во Имя Богов"

daemon_n, потыкай в другие кампании. Проверял все четыре, но и на старуху бывает проруха.

Berserker, прошу создать новый тип ERM переменной (даже не новый тип, а просто синтаксис, но об этом ниже) и внести в ЭРУ её массив с прямым доступом (get) к массиву вог опций. Я понимаю, что геттеры и сеттеры (UN:P) идеологически правильнее. Но в данном конкретном случае это позволит нам уйти от массы навороченых конструкций такого рода в воговских скриптах.
Например:


К тому же при постепенном корректировании скриптов я смогу освободить массу использованных v переменных.

Так как все переменные с одним символом заняты - возможно ли ввести переменную типа optномер переменной (из двух или трех символов)?
Например: opt190 - прямой аналог UN:P190/?y1
или заглавной буквой, если два или три символа сложно P190 - прямой аналог UN:P190/?y1
К тому же set{} нам не нужен. Нужен только аналог get{}. Т.е. нам нужно только получение значения, без возможности установки

Раз уж я кардинально добрался до ERM скриптов, дополнительно поддержу ХЕРОМАНТа с предложением ввести 3 ERM команды
1. Получение структуры героя:
Воговская функция: !!SN:E7411341/1/[номер героя];
Команда ERM: HE:Z?y1 (y1 - структура героя, если y1=0 значит стуктура по каким-то причинам не получена)

2. Получение структуры боевого стека
Воговская функция: нет таковой
Команда ERM: BM:Z?y1 (y1 - структура боевого стека, если y1=0 значит стуктура по каким-то причинам не получена)

3. Расширение команды UN:C (добавить возможность сразу указать смещение)
UN:C<адрес>/<размер>/<данные>; старая команда if(Num==3)
UN:C<адрес>/<смещение>/<размер>/<данные>; новая команда if(Num==4)

Невероятно давно они все пользуются большим спросом, а прямой реализации в ERM нет.

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

Условия для триггеров в следующей 3.0.0 можно писать так:


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

!!FU(GetHeroStruct), !!FU(GetBattleStack), !!FU(MemAtOffset).
Для последней можно получить синтаксис параметра (?, SET или d) через !!FU:Sномер_параметра/?y1;

С Эрой я буду поставлю от силы пару скриптов, ни на что не влияющих, но задающих константы и некоторые полезные функции. Возможно, тебе покажется верным тоже иметь один мод вроде ERM Library, в котором твои хуки и множество функций с фишками UN:C. От такого мода могут зависеть ES Scripts, ACM и иже с ними.

(05.03.2020 11:28)igrik Wrote:  Так как все переменные с одним символом заняты

a, b, u?

Вообще с переменными-опциями было бы идеально отвязать их от номеров (чтобы там коллизий тоже не возникало) и реализовать условия в триггерах:

Нет !#UN:P123/?i^opt123^; не устраивает.
Какая в данном случае принципиальная разница от использования v переменных? Правильно - никакой. Рефакторинг и сокращение кода - нет ни смысла, ни возможности.

То же и по функциям. Вот щас Херомант напишет вставку героев, перенесет таблицу, а тут масса скриптов со своими функциями !!FU(GetHeroStruct), которые все никогда не отловишь.

Ладно, я понял твою позицию. Тогда я со своей стороны просто не вижу смысла перерабатывать воговские скрипты.
Максимум правка существующих багов. Жаль.

(05.03.2020 15:19)Berserker Wrote:  Возможно, тебе покажется верным тоже иметь один мод вроде ERM Library, в котором твои хуки и множество функций с фишками UN:C. От такого мода могут зависеть ES Scripts, ACM и иже с ними.

Такие зависимости не очень хороши тем, что моды и даже скрипты в рамках одного мода привязаны к определенной библиотеке и не могут использоваться отдельно. Когда "точка привязки" - это сама ERA, ясен хрен удобнее

Но, если нет других вариантов, подобное решение позволит сократить код и, при необходимости внести изменения, править только в одном месте. И этот плюс перевешивает минус от привязки к доп. библиотеке.

(05.03.2020 15:29)igrik Wrote:  Рефакторинг и сокращение кода - нет ни смысла, ни возможности.

Тут не соглашусь, возможностей со времен написания WoG-скриптов прибавилось очень много.

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

Опять же, функция библиотеки расширяющая UN:C, принимающая и базовый адрес, и смещение - почему нет?

Ну, так тем более, что такое нужно реализовывать на движке ЭРЫ, а не на библиотеке. К тому же библиотека может быть отключена в любой момент, потому что она не является базой игры.
Мне понадобилось всего 3 функции, которые внести в существующий движок ERM займет не более 10-15 минут. Очень маленькое обновление, но достаточно важное с точки зрения ERMa. Почему не дать эту возможность на базовом уровне. Зачем для такого нехитрого и частовызываемого функционала нужно изобретать ERM библиотеку, которая будет работать на порядок медленее?

(05.03.2020 15:29)igrik Wrote:  Вот щас Херомант напишет вставку героев, перенесет таблицу, а тут масса скриптов со своими функциями !!FU(GetHeroStruct), которые все никогда не отловишь.

Как раз поэтому для ERA под новых героев я постараюсь обойтись без переноса этой таблицы. Только ради совместимости с erm-скриптами, плагинами, era.dll и HD-модом (если бы не эта проклятая совместимость, то можно было бы просто скопировать патч из MoP и новые герои появились бы ещё в первом релизе ERA PLUS, а так - запланировано только к лету 2020 года).

(05.03.2020 15:19)Berserker Wrote:  Меня далее будет интересовать библиотека на Lua.

Понадобиться большой повод, чтобы перейти с ERM на LUA. От лица непрограммиста скажу, что ERM более проста и понятна (с подробным хелпом) для освоения простому смертному. Возможно, что расширять ERM придётся уже в рамках ERA PLUS .

(05.03.2020 16:00)igrik Wrote:  Зачем для такого нехитрого и частовызываемого функционала нужно изобретать ERM библиотеку, которая будет работать на порядок медленее?

Именно поэтому выступаю за встраивание ERM-скриптов (или их часто используемых частей в виде функций) в dll. Правда до этого на ERA пока дело ещё не дошло (может года через 2-3 такое начнёт появляться, когда будет полностью готова базисная часть ERA PLUS).

Algor, если сделаем с игриком новую систему опций в добавление к старой (по другой кнопке), то новые опции для ЕРМ/Lua/плагинов будут именованными. Никакие костыли не нужны.

Quote:Нет !#UN:P123/?i^opt123^; не устраивает.

Это в любом ЯП глобальные переменные. Будут именованные функции, будут и на Lua вызывать GetOption. И на Pascal/C.
Отличие от v-переменных в том, что их пытаются другие скрипты переиспользовать. Из-за этих старых скриптов и сыр-бор. С именованными проблем нет.

Quote:Вот щас Херомант напишет вставку героев, перенесет таблицу, а тут масса скриптов со своими функциями !!FU(GetHeroStruct), которые все никогда не отловишь.

Если перенесёт, то вызовет RedirectMemoryBlock. Тогда в функции сделай !!SN:F^GetRealAddr^/старый адрес/?новый адрес. И такая команда переживёт всех.

Более того, получение опции правильно завернуть в функцию обёртку. Ибо сегодня это опция 53, завтра «opt.InfiniteMoney», а послезавтра параметр из json, который ты парсишь функцией. Правильный код — не создавать новые грабли и костыли, а предотвращать создание оных.

1) Номер опции в константу.
2) Проверку опции в функцию.