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

Спасибо всем за ответы.
Да, я знал, что Слава Сальников это прописал в 100-й опции, которая встроена в ВОГ. Очень надеялся, что каким-нибудь UN:C можно эту потерю отключить. Попробую как-то решить проблему скриптом.
Э-э... я правильно понял, что в ЭРА, по желанию, это можно будет сделать?

SergOz, на здоровье. Скриптом/плагином — да.
igrik, формат сохранений не изменится для окружающих, если использовать WriteSavegameSection/ReadSavegameSection.
Сперва при загрузке делается так:
int mySectionSizeOrItemsCount = 0;
ReadSavegameSection(4, &mySectionSizeOrItemsCount, 'igrik.MonsExpOnMap');

Если в секции были данные, то первое число будет прочитано и не будет 0, если сохранялось не 0. Если не было — останется 0, можно смело пропускать.
Формат своей секции придумываешь сам.
Скажем, 4 байта — число сохранённых объектов. Далее — список из Координаты, Опыт. Если что — пиши в вк.

> Очень надеялся, что каким-нибудь UN:C можно эту потерю отключить
Режет слух вот это "отключить". Опыта в оригинале героев у монстров НЕТУ, когда ты выгружаешь отряд на карту - ты его ставишь за границы скрипта опыта, т.е. он попросту отключён у мобов на карте(нейтралам ставится уже в самой битве всем универсально, а не индивидуально)

Есть информация по поводу того, как сделать имена героям больше 12 символов?)

(09.12.2019 21:41)AuAu Wrote:  Есть информация по поводу того, как сделать имена героям больше 12 символов?)

В структуре героя выделено пространство только под 13 символов под имя. А любое расширение структуры героя - портянка на 300 с лишним адресов, поэтому можно считать что никак для простых смертных.

В течение 2 дней (ладно, одного, поскольку узнал верную команду лишь вчера) ломал голову, почему не работает "Освободитель z-переменных" (!?PI) для описания измененных ВН. Пробовал просто абсурдные комбинации, если честно.
Суть в том, что я проверку "активности скрипта" записывал в y1-y..(временные переменные, как я понял), предлагаемые самим скриптом, но ничего не вышло путного, как могли догадаться программисты. Следовало использовать v (обычные), что выяснил методом тыка - далее пришла мысль, что в самих скриптах изменения ВН уже присвоена нужная переменная "30 wog - enhanced secondary skills.erm":
, потому можно просто делать так в "3 wog - secondary skill text.erm":
Суть в том, что не требуется использовать лишние переменные для !?PI, слегка экономится длина кода, если не прописывать выше повторное занесение в ту же переменную !#UN:P201/?v7186; (критично ли переписывание одной и той же переменной к одной и той же ситуации разными скриптами?);
Вопросы:
1 - насколько корректны мои действи? (Не повлечёт ли данный процесс за собой проблемы даже теоретически)
2 - есть ли список с такими распространёнными переменными, которые используются в тех или иных скриптах? Или придётся каждый скрипт открывать и смотреть "а вдруг, здесь на эту проверку записано иное", что потребует перелопачивание всех вог-скриптов.

Нужно что-то такое, но не только для навыков (указано в 30 wog - enhanced secondary skills.erm):
Хочется максимально оптимизировать скрипты. Если ошибаюсь, то не расстроюсь: меньше работы

UPD: обнаружил в 2 разных скриптах
!#UN:P203/?v7188; [Check if Estates I is enabled in WoGify Options]
!#UN:P203/?v2368; check if Estates I (script48.erm, Arstahd) is enabled

и ещё это:
!#UN:P40/?v429; - First Money by Alexis Koz / !#UN:P45/?v429; - Castle upgrading
!#UN:P39/?v425; - Hero Specialization Boost / !#UN:P41/?v425; - Battle Extender
Но конфликта нет, вроде. Я явно не понимаю, как работают эти переменные, раз нет конфликта

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

daemon_n, отлично! Ошибку исправь, унифицировать ничего не нужно, лишняя работа. Да, данные, которые должны сохраняться среди всех событий в любое время, записываются в глобальную память (а время жизни y-переменных ограничено одним событием). Скриптописцы выбирали себе свободную v-переменную для каждой опции и использовали её.

А так ты всё верно понял. Можно в каждом триггере получать значение опции и выходить, если не установлена. Можно сохранить в SN:W переменную и делать то же. Но смысл? Сразу смотришь, куда автор через UN:P сохраняет опции — и всё )

Berserker, некоторые скрипты сохранены во временные, потому и возник конфуз. В том конкретном скрипте это даже удобно, поскольку учитывается много вариантов "вкл/выкл" скриптов.
А почему предложил унифицировать, потому что так я смогу использовать !?PI для смены описания для навыков, тем самым освободив немало v переменных глобальных.
Так , а ошибка - использование одной и той же v var глобальной для разных скриптов?Или только ситуация, где в одном скрипте было две проверки другого скрипта дважды?

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

!?CM2;
!!UN:P300/?y1; y1 — просто временный ящик, куда нужно положить значение опции, чтобы следующей командой подсмотреть её
!!FU&y1=0:E;
; далее можно использовать y1 для других целей (хотя лучше продолжать с y2, легче читать)

Berserker, так конфуз случился у меня в голове, когда я несколько часов потратил на разные варианты и комбинации.
!!UN:P300/?y1;
!?PI&y1=1;
!!SN . ..;
Ух, я потратил времени и нервов)
Ещё там было по несколько переменных в строке.

daemon_n, так ты разобрался или нет? Судя по последнему посту - нет.

Quote:!!UN:P300/?y1;
!?PI&y1=1;
!!SN . ..;

Так нельзя проверять через локальную переменную y1.

Правильно проверять

Quote:!?PI;
!!UN:P300/?y1;
!!FU&y1<>1:E;
!!SN . ..;

Потому что y1 - это локальная переменная. Она хранит значение только для одного триггера (!?). В следующем триггере или функции она будет или обнулена, или будет иметь другое значение.
Тебе нужно всего один раз понять что такое глобальная переменная, а что такое локальная переменная, и в чем их принципиальная разница.

igrik, это я описывал свой позавчерашний и вчерашний день. Привёл в пример свои горе попытки, отчего появилось идея проверять через глобальную, которая уже задана в ином скрипте на данную опцию.
Однако увидел в твоём сообщении и интересный вариант реализации. Спасибо за ответ.
И да, теперь ясно, что локальные переменные ограничены одним триггером. Ранее я думал, что ограничено одним скриптом либо просто не работает
То есть переименования всех вторичных навыков (каждый по одному разу, допустим), надо каждому задать ту форму, что ты отметил, что позволит, грубо говоря, задействовать всего одну переменную y1 28 раз в пределах одного скрипа(erm файла, на деле же это будет 28 скриптов, потому проверка через глобальные мне в голову пришла).(?)
Всегда нужна строка про выход <>1: Е, это чтобы быстрее код читался?

Можно к конструкции !!SN:H^secskill^3/1/z175017; добавить текст из иной строки (+z175108) без добавления переменных?

daemon_n, смысл !!FU&y1=0:E — выйти из триггера, если опция не включена. Остальные команды до следующего !?XX не выполняются. Без этого ты просто получишь значение опции.