ага, SergOz, спасибо, уберу

(01.11.2019 15:29)PerryR Wrote:  

Code:

Acid attack damage 00441251

Calc with Hex in Deca

Example how to use it:

Хм, у кого кислотная атака?
Ржавые драконы разят врага в пост-атаке своей кислотой, минуя !?MF1, а потому не смог увидеть выпадание указанного значения

Ещё кошмарные гидры кислотой атакуют

да, она, спасибо
идёт атака кислотой, снижая защиту, а следом вторая уже наносит урон - как по мне, перебор с первым WoG Team сделала

Согласен - и анимаций куча, и звуков - ещё и в лог идёт не пойми что

выпили в сборке

(01.11.2019 15:29)PerryR Wrote:  Damage Type Return Address:

Code:

Fireball damage 0043F960
Normal shooting 0043FA63 (4455011)‬
Range cloud damage 0043FD42
Ring damage 004400E4 (Strikes all Enemies around)
Fire Shield Damage 0044085D
Death gaze damage 00440E75
Lightning strike 0044104D
Acid attack damage 00441251
Normal melee damage 0044173E (4462398)
Dragon damage 0044178F
Arrow Tower Damage 00465964
Moat damage 00469A98
Death ripple damage? 005A106A

Сделал для этих данных в справочнике комментарии, если что не так или надо иначе сформулировать, то скажите...

Quote:Комментарии:
- если монстр может атаковать сразу несколько целей одновременно, то у него урон всегда имеет тип "круговая атака" (даже при атаке одной цели);
- тип повреждения "урон дракона" срабатывает лишь для стека, находящегося за основной целью (вторая клетка атаки);
- заклинание "Волна смерти" можно считать исключением среди прочих из магической книги, т.к. обрабатывается сначала в триггерах !?MR, и уже потом в !?MF1 (зачем? остаётся загадкой).

В справочнике команда GetGameState указана как
   !!SN:F^GetGameState^/?y1;

Но результат y1 всегда будет Карте приключений.

корректно просто !!SN:F^GetGameState^; - результат в v1;
Разве что задуманный способ с /?y1; неверно реализован

нет, ты не внимательно прочитал...
в y1 - это родительский экран
а в y2 уже будет дочерний экран (конечный результат) - там ф-ция получает 8 байт... первые 4 байта отдаются y1, а остальные 4е уже попадают в y2
т.е. если ты будешь получать в y5, то тебе для идентификатора текущего диалога надо смотреть y6

ERM-Help Wrote:

Работает это так: SN:F вызывает внешнюю функцию GetGameState.
?y1 означает передачу в качестве параметра адрес y1 в памяти (y1 занимает 4 байта, y2 тоже четыре). А функция на самом деле работает с адресом структуры в 8 байт из двух полей:
- родительский диалог (ID); приходится на y1
- дочерний диалог (ID); приходится на y2

если этот момент после прочтения комментария по ф-ции в справочнике всё равно не понятен, скажи, может стоит иначе написать... хотя как по мне, там всё вполне логично и доходчиво изложено

Bes, про v1 вообще не сказано.

Вижу команду - смотрю пример, а там "!!SN:F^GetGameState^/?y1;".
К тому же в приоритете всегда текущий диалог

в родительском диалоге всегда будет КП
в дочернем - тот что активный на момент вызова ф-ции
что до v1, не знаю что туда идёт, Berserker про неё не говорил, к тому же, весь этот код я на базе ERA2 описывал... если что-то изменилось под ERA3, я этого не знаю.

если я в примере напишу !!SN:F^GetGameState^/?v1; тебе будет понятнее, что id текущего диалога надо брать из v2 ?

(08.11.2021 20:11)Bes Wrote:  если я в примере напишу !!SN:F^GetGameState^/?v1; тебе будет понятнее, что id текущего диалога надо брать из v2 ?

Теоретически, должно быть что-то вроде "!!SN:F^GetGameState^/?v1/?v2;", чтобы скриптёры не гадали по поводу скрытой передачи данных в переменные (особенно, когда в v2 будут храниться стратегически важные данные, а скриптёр просто не заметит их порчу после !!SN:F ).

Bes, я за то, чтобы было только !!SN:F^GetGameState^;

"всегда будет КП"? Берём текущий диалог в v1 через !!SN:F^GetGameState^; - всё

XEPOMAHT, так скриптер прежде чем использовать команду явно увидет в справке последствия для переменных, и потому не должен быть застигнут врасплох