Berserker, кто по Era Scripts Rus может изменения вносить?
опция 790 mana arrow
строка 23:


Разве должно быть не:


Без второго параметра при касте вылезает часть интерфейса.

ElfbI, для этого мода есть одноименная тема. Поскольку он включен в сборку, которой также принадлежит тема, можно (желательно) отписывать и там -- внесу правки.

daemon_n, хорошо, учту.

Собираюсь приравнять отрицательные y/e переменные к положительным, полностью убрав разницу в их значении. В результате вызов любой функции/триггера будет обходиться без сохранения/восстановления лишних 1600 байт памяти. В основном используют в одном триггере или те, или другие. Есть возражения?

Взамен положительные e-переменные будут сохраняться/восстанавливаться всегда, а не только при вызовах функций.

Возражений то нет. Наоборот было бы отлично.
Но масса оригинальных воговских скриптов завязаны на одновременном использовании y-1 и на y1. Не поломаются ли они?

igrik, обе группы временные. На вскидку не удалось найти место, где использовались бы в одном триггере и те, и другие. Если кто найдёт — буду благодарен.

Enhanced Warmachines I


apart from that I found no other, but I will keep looking, I think there are some more

PerryR, argh, thank you very much. Bad example of script writing (though, it's really a mess with variables in ERM).

(03.09.2019 19:58)Berserker Wrote:  igrik, обе группы временные. На вскидку не удалось найти место, где использовались бы в одном триггере и те, и другие. Если кто найдёт — буду благодарен.

Для более простого понимания примем что y-1 это y-1 ... y-100, а y1 это y1...y100
Разве y-1 временная?
На сколько я знаю y-1 это глобальная переменная для данного для неё скрипта (т.е. в одном файле скрипта она будет иметь одинаковое значения для всех триггеров. А в разных файлах скриптов она будет разная). А y1 временная, которая будет иметь свои значения для каждого триггера.

UPD: ага, простейший тест показал, что это уже не так. Хм. Буду знать. Давно ли уже y-1 стала временной переменной?

(04.09.2019 13:28)igrik Wrote:  Для более простого понимания примем что y-1 это y-1 ... y-100, а y1 это y1...y100

Тогда уж сделайте наконец-то нормальный диапазон от у-100 до у100. Чтобы люди не путались. Например у себя я по-прежнему не использую отрицательные "у", считаю положительные "у" более безопасными, т.к. точно известно, когда они обнуляются в ERM.

What would happen with the spell function?


any script that uses this function expects y-99 to hold the spell :/ not sure if it would also work with y99.

igrik, ЕРМ руководство всегда было точно в отношении отрицательных y-переменных:
y-1...y-100 Trigger-based local variables. Integer vars
y1 through y100 Function local variables (unique for each function)

То есть, локальные для триггеров переменные.
А y1+..y+100 — локальные для триггеров-функций.

Этот бардак — рассадник багов. Поскольку функции не считались триггерами, а значит в них нет сохранения/восстановления отрицательных y-переменных. С другой стороны, в обычных триггерах не сохранялись/восстанавливались положительные y-переменные. То есть функция рассчитывает, что её y-переменные никто не тронет, генерирует событие !?BA, где переменные спокойно портятся.

Было принято стратегическое решение для ВСЕХ событий/триггеров/функций сохранять и восстанавливать положительные y-переменные, сделав их всегда локальными.
А отрицательные y-переменные предать анафеме.

Воговская FU$spell$ рассматривает отрицательные y-переменные как принадлежащие триггеру, который вызвал функцию (так и есть!), и использует их как глобальную память для возвращения результата.

Это ещё не всё.
z-1 through z-10 Function string variables (unique to each function)

То есть нельзя в обычном триггере использовать z-1..z-10!

И это не всё.
e1..e100 Function floating point variables
e-1...e-100 Trigger-based local variables. Floating point vars

То есть с e-ками такая же проблема. Обычные триггеры и триггеры-функции могут портить переменные друг друга.

По=хорошему разницы между !?XX и !?FU быть не должно. Отрицательные переменные не нужны (кроме z-1..z-10, которые долны быть локальными везде). Вопрос, как быть с обратной совместимостью.

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

Hd mod 4.208 rc 4 heroes3.ini

[Era]
CpuTargetLevel=50 - именно на моем ноуте(i5 3230m 2.6Ghz up to 3.1) смена значения на 100 вызывает странный баг - при закрытии игры на "крестик" выхода не происходит, но окно зависает. Подобный баг рапортуют пользователь Win 10 и win 8.1, но со значением "50", если они его не меняли.
Так понимаю, это связано с конфликтом с HD mod 4-ой версии?

daemon_n, убедитесь, что в hd-моде отключён патч на процессор. При CpuTargetLevel=100 Эра не делает ничего.
При меньшем — перехватывает функцию получения сообщения окну игры, в которую грамотно вставляет паузы.