По запросу GarryR пишу универсальный настраиваемый мод Mixed Neutrals. Феникс всегда возрождается.

3.0.4:

Синтакис освобождения, типа !#VA(-myArts); вызывает ошибку:


1000 era - consts.erm:
!#DC(PRIM_SKILL_FIRST) = 0;
!#DC(SKILL_ATTACK) = 0;
!#DC(SKILL_DEFENSE) = 0;
!#DC(SKILL_POWER) = 0;
!#DC(SKILL_KNOWLEDGE) = 0;
!#DC(PRIM_SKILL_LAST) = 3;

1000 era - stdlib.erm:
Не мешало бы добавить (week), (month) и переименовать (isAi) в (isAI)


Точно проверить не могу (см п.1), но сильно подозреваю, что в общем случае пример из changelog'а не корректен, т.к номера могут выделяться не последовательно:

Algor, спасибо, исправляю.

Я в именовании придерживаюсь соглашения о только первой заглавной в аббревиатурах. То есть ToHtml вместо ToHTML и GetId вместо GetID. Поскольку много капса сложно печатать.

Quote:Не мешало бы добавить (week), (month)

И monthWeek (0..3). Тут будет удобнее набор глобальных переменных. Их и проверять проще прямо в условии триггера.

Предлагаю:

i^timerDay^ 1..+inf
i^timerWeekDay^ 1..7
i^timerMonthDay^ 1..28
i^timerWeek^ 1..+inf
i^timerMonthWeek^ 1..4
i^timerMonth^ 1..+inf
i^timerOnce^ 0..1
i^timerOwner^ 0..7
i^timerIsAi^ 0..1
i^timerIsHuman^ 0..1

Quote:Точно проверить не могу (см п.1), но сильно подозреваю, что в общем случае пример из changelog'а не корректен, т.к номера могут выделяться не последовательно:

Я зарелизю мод сегодня, посмотришь. Индексы для массивов всегда последовательные.

Вылет исправлен.
https://dropmefiles.com/PSysA

(05.09.2020 22:52)Berserker Wrote:  Я зарелизю мод сегодня, посмотришь. Индексы для массивов всегда последовательные.

Да, ругается, что не может выделить, если нет нужного последовательного куска. С одной стороны это хорошо, можно использовать такое свойство непрерывности. С другой - могут появиться проблемы с фрагментацией.
Нужно ли что-то менять? Наверное, нет. Просто учитывать, что большой массив из локальных переменных не всегда можно выкусить и использовать временные SN:M-слоты с последующим освобождением.

Algor, для этих целей в SN:M добавилось значение 4-го параметра в виде (SN_M_TRIGGER_LOCAL). Массив автоосвобождается по выходу из текущего триггера. В моде на смешанные нейтралы активно пользуюсь.

По фрагментации всё верно. Можно через !#VA в начале функции объявить массивы, которые потом освобождать. Для огромных данных SN:M и SN:V в помощь.

(06.09.2020 02:04)Berserker Wrote:  Algor, для этих целей в SN:M добавилось значение 4-го параметра в виде (SN_M_TRIGGER_LOCAL).

Угу, видел в описании. Удобно.

(06.09.2020 02:04)Berserker Wrote:  По фрагментации всё верно. Можно через !#VA в начале функции объявить массивы, которые потом освобождать.

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

UPD: туплю (сонный уже), написал код, а запустить и посмотреть не судьба.
Будет 1.
Но вопрос не в том, а в том, что объявление (myVar:y) затерло фактически использовавшуюся y1, т.е.


С этим могут быть проблемы. Наверное. Подумаю на свежую голову.

Algor, 1

daemon_n, всё верно. будет 1 всегда. Потому как имена локальных переменных определены только до следующего триггера в тексте. Собственно, всё верно. Каждый обработчик будет насиловать y1..y100 по-своему.

(06.09.2020 02:22)Berserker Wrote:  Собственно, всё верно. Каждый обработчик будет насиловать y1..y100 по-своему.

Т.е., фактически, можно вообще никогда не использовать синтаксис освобождения, кроме отдельных способов особо циничного извращения (это я про попытки использования многих больших временных массивов без SN:M)

daemon_n, взаимно, но я пока еще не надолго.

(06.09.2020 02:14)Algor Wrote:  Но вопрос не в том, а в том, что объявление (myVar:y) затерло фактически использовавшуюся y1, т.е.

1. !?BR;
2. !!VRy1:S12;
4. !?BR;
5. !!IF:M^%Y1^; <-- тут 12
6. !!VR(myVar:y):S1;
7. !!IF:M^%Y1^; <-- а тут 1

С этим могут быть проблемы. Наверное. Подумаю на свежую голову.

Berserker, а вот да, вопрос почему !!VR(myVar:y):S1; возьмёт y1, а не y2. ERM2 разве не смотрит, есть ли в использовании y1 до присвоения ей метки myVar ???

Algor, да, но вдруг тебе сперва нужен массив на 50 ячеек, потом высчитать среднее по ним, потом сгенерировать другие 50 чисел на основе среднего + рандома. Вот тут и придётся, чтобы уместиться в y1..y100 и использовать два разных логических имени, таки освободить первый массив. А так будет очень редко использоваться.

Bes, локальные переменные локальны для одного триггера до следующего триггера в тексте. Реальный код точно также переиспользует y1.

!?BA0;
!!BA:H0/?y1;
...

!?BA0;
!!OW:C?y1;
...

(06.09.2020 02:41)Berserker Wrote:  Algor, да, но вдруг тебе сперва нужен массив на 50 ячеек, потом высчитать среднее по ним, потом сгенерировать другие 50 чисел на основе среднего + рандома. Вот тут и придётся

Это как раз тот случай, который я выше описал как "особо циничное извращение".

(06.09.2020 02:41)Berserker Wrote:  Bes, локальные переменные локальны для одного триггера до следующего триггера в тексте. Реальный код точно также переиспользует y1.

Берс, даже внутри одного триггера:


Т.е. использовать смешанный стиль вообще раскованно и, по-хорошему, недопустимо.

Это НЕ плохо.

Если взялся за оружие написал ZVSE2, будь готов получить пулю добр использовать только новые правила. Главное, чтобы при этом не возникало коллизий с используемым в сборке старым кодом. Навскидку, да, не должно. На практике - посмотрим.

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

!!HE-1:N?y1;
   при смене героя кликом на интерфейсе не изменятся, пока новый герой не совершит действие - считаю, это баг, ведь активный герой теперь другой