Спасибо за информацию )
Возможно у меня нет проблем, т.к. по определённым причинам у меня каждый ход срабатывают !?BG0 и !?BG1.


Какие последствия будут, если обменять смещение ? Не вызовет ли это смещение много чего ещё ? ) Мне почему то кажеться что это слегка может отразиться на битах существ в последующих боях )

Если всё с умом провернуть, то может и прокатит.
Сергрой, не напомнишь ещё раз структуру лода?
В принципе для сей операции хватит и примитивных возможностей !!UN:N

Не забываем писать о багах. Сегодня очередное обновление. На первой странице добавлены описания багов:

!!BM:G - баг при снятии заклинаний (установка длительности 0). Заклинание пропадает. Но картинка заклинания продолжает висеть у существа вечно.

!!FU:E - нет сообщения об ошибке, если не поставить в конце ';' . А вот кучу глюков, которые трудно поймать получить вполне реально.

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

Второе относится не только к функции, у других ресиверов тоже бывает.

Если при 0 заклинание не приложено, то и картинки его не должно быть. Или должен быть какой-нибудь другой способ убрать картинку.

Будешь находить - пиши.

Если при 0 заклинание не приложено, то и картинки его не должно быть.

А за это спец функция отвечает. Это как разница между переменной и property в Делфи.

Смысл такой, имеется переменная Spell. Имеется функция SetSpell (_spell). Так вот, мы можем брутально изменить значение переменной Spell, причём все алгоритмы это поймут, только графику сие не затронет. А можем юзать интернальную функцию, которая ещё и о прорисовке заботится, кроме изменения переменной. Вот толь второй способ сложнее, проще найти адрес и изменять саму переменную, что и сделал Слава.

Это и ежу понятно, что изменить переменную проще, чем вызвать функцию RemoveSpell. Я говорю о том, что метод RemoveSpell должен быть доступен через ERM.

Извините, уважаемые, я встряну в ваш разговор с др. описаниями багов...

Раз уж затронули тему с графикой, то ... Если через UN:I на карте поствить монстра в ту область где имется событие (синий кружок), а потом убрать через UN:O, то хоть монстр и убирётся, но его образ останется на месте
По аналогии, можно вспомнить и существ в битве, когда нулевой отряд при попытке пошевелится замирает на первой же анимации, и так и остаётся (пока др. анимация его не перекроет)..

Кстати, тут в соседней теме я указал на имеющийся факт выскакивания казуса при использовании UN:L ... Вот вам ещё один касяк кода

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


Уважаемый Bes, просьба поподробнее изложить суть бага. Формат описания бага:
1) Команда(ы) при которых возникает
2) Когда возникает (Какая последовательность событий может привести к возникновению)
3) Частота возникновения (Всегда/Регулярно/Никогда)
4) Варианты обхода бага (если есть)

>Не является багом... т.к. не предусмотрено возможностями игры.
Так ведь обсуждаем не саму игру, а ЕРМ!
Но, согласен с вами!


То, что мне известно по поводу UN:L ...
- Описание: "Появляется окно обмена между героями, причём и с той и с др. стороны один и тот же герой"
- Появляется, если при посещении !?OB героем этой командой переместить взгляд на заскриптованный объект (на этот или др.)
- Появляется не всегда, я бы сказал, редко...
- Обходных путей не искал
- Вот примеры его появления: Как его словил Serco
А вот, как я его словил:Здесь я посещал декоративный объект(ZDec0012.def) (в редакторе для него сделал точку входа)

(Повторение бага не обищаю, т.к. возможно имеется и привязка к особенностям карты)

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

Проверил.
Я сделал следующим образом.
Поставил на карту в позиции 12/8/0 рынок времени и написал код:


Этого было достаточно для возникновения бага. Сначала появлялась менюшка рынка времени. После закрытия ее любым способом перемещался обзор последовательно на 3 указанные точки. Потом появлялось окно с двумя моими героями.

Возникновение бага в триггере !?OBx/y/l; не зависит от используемого объекта, координат взгляда и его длительности.

Есть предположение, что баг возникает именно при использовании команды !!UN:L внутри триггера !?OBx/y/l; Например в триггере !?OB<type>/subtype>; или триггере !?CM5; баг уже не возникает. У кого будет время можно проверить эту гипотезу.

Баг лечится отключением свойств обьекта... Но это не всегда приемлимо...

Отключил...юзаешь...включил

!!BMx:C....
Если у монстра оспротивление или иммунитет может нагло прописать мусорную информацию в v1. Точнее прописывает, а если в v1 у вас был номер монстра, то следующая команда с ним вызовет ошибку( монстр 56007780 не найден )

На 3.58f нормально выдает ошибку

Не работает вызов FUy1.

а что, должно?

Странно...должно работать. Без инструкции работает 100%.

Не работает с y-переменными. С v работает, а с y ну никак.

В триггере тоже не работало. Хотя у меня там одна из функций была локальной. (в TE есть локальные функции?)

Нет. Только глобальные.

Если на карте стоят несколько объектов одинакового типа и подтипа, но они измененны с помощью Advanced Properties, то команда установки объектов (UN:I) берет за эталон последнего из них (а вовсе не того, что прописаны в zobjcts.txt).
Пример: У Black Dracon'а на карте стоял декоративный гоблин на горе. У него была удалена точка входа. В результате, при установке гоблинов через ERM, ставились такие же пустышки вместо нормальных гоблинов.

Однако, это наталкивает на мысль:
Несколько раз возникали вопросы про установку объектов типа/подтипа, у которого есть несколько вариантов с разными def'ами.
Это можно сделать:
1) На своей карте. Для этого надо поставить куда-нибудь на карту объект одного из неиспользуемых типов с каким-нибудь уникальным подтипом и нужным дефом. Затем использовать эти тип/подтип в качестве внешнего вида в UN:I (параметры #6 и #7 в версии с 9 параметрами)
2) В общем скрипте. Для этого придется модифицировать zobjcts.txt. Точно также, надо добавить объект незанятого типа/подтипа с нужным дефом и использовать в качестве внешнего вида в UN:I.

У меня странная, как может показаться, просьба: "Что можно ввести через инструкцию, чтобы игра, прочитав это вылетела???"
Т.е. если написать !#GH:HFGST - то игра это не сможет переварить, просто выскочит окошко с шеснадцатиричными кодами ошибок и всё, дальше по нажатии "ок" она вылетает


(это мне для защиты надо, вирусы я не пишу
ответ можно в ПМ заслать)

У меня это бывало при вызове IF:Q с несуществующей картинкой. Правда, это было давно.

!!UN:C0/4/0;

А я знаю для чего тебе это надо
Ты хочешь, чтобы если версия игры устарела, чтобы выкидывало в виндовс. Угадал?

Если да, то предлагаю следующий вариант:
!#IF:Q1/-1/0/0^Версия устарела. Нажмите Alt+F4^;

Выдает окно без кнопок. Выход один

спасибо, всем...
ShadowTheAge, не угадали... это защита карты (у которой будет ввод пароля, а сама карта будет через SD.ехе обработана...)

Люди приколитесь. Работаю я щас над одной картой. Silver карту рисует а я на нее скрипты пишу.
Решил я вчера посидеть, скриптов пописать. Испытать разные ситуации какие будут на карте встречаться.
Ну и с первой же попытки обнаружил какой-то неизвестный досели баг.

No Comments No Comments

MegaBug

No Comments No Comments

Кто знает ЕРМ опишите тут этот баг ибо у меня нет слов(да и времени).

На карте, присланной easy-to-kill происходит следующий баг.
Он ставит в инструкциях несколько новых сундуков (101, 1) в виде фанатиков (54, 9). Если брать сундуки в неправильном порядке, то возможно открытие диалога присоединения/битвы. В случае присоединения присоединяется 0 фанатиков. В случае битвы нападает порядка 2000.
Под правильным подразумевается порядок:
1 4 6
2 Г 7
3 5 8
Г - герой. Чем меньше номер клетки, тем раньше нужно брать в ней сундук. При правильном порядке все работает корректно. При неправильном ошибка возникает на 2oй- 3ий раз.
Глубже эту проблему не исследовал.
Итог: Извращаясь с ERM можно обнаружить "Мегабаги".

Это не извращение. Просто нужен такой обьект который при определенных обстоятельствах исчезает, но не "втупую" а как бы плавно. Что б можно было потом ставить этот обьект под разными "личинами". Этим обьектом я и взял сундук. А расставил я их вокруг героя для наглядности. И поочередность их взятия тут в принципе не при чем. Просто при подборе такого сундука у всех обьектов созданных через UN:Ix/y/l/тип/подтип/тип внешности/подтип внешности и стоящих сверху, слева, и сверху-слева от подбираемого сундука тип и подтип стают такими же как тип внешности и подтип внешности.

Тогда понятно при чем тут очередность. Она действительно не является первопричиной.
Скорее баг связан именно с монстрами. Похожий баг наблюдается при убиении охраны рядом с Refugee Camp. Возможно, если использовать не монстров, а другие объекты, бага не будет.

Изложу свои эксперименты по поводу этого...
Так вот...
,
где $/$ означает:
[зелёный] - истинный номер стэка
[красный] - дефектный номер стэка

С левой стороны я получил только 11 стэков, а с правой 12... дальше влом было, может попозже полный список могу получить (если удасться съэмитировать такую многостэковую битву)

Получаемве номера стэков постоянны, посему можно предположить о неправильной схеме подсчёта стэка в самом ехе=шнике.
Результаты были получены благодаря мониторингу через !!IF:L^^;

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

PS: если у кого из этих "номеров" получится вывести анти формулу (обратную той, что работает в ехе-шнике), то было бы здорово...

Хотел, что-то себе доказать. Доказал на половину. Если кому-то интересно.
Это скрипт вмемто !!MR:N, сыроватый, но рабочий. Второй его минус (пока) действует только для атакующей стороны.

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


Добавлено ([mergetime]1190921800[/mergetime]):
Да, работает только для магии, которая наносит урон.

Выложил документацию по триггеру MR2. Надеюсь кому-то будет полезна.
http://forum.df2.ru/index.php?showtopic=24...id=191121&st=32

2 Demiurg
Откуда взято это MR2?
Допустим при !?MR2 вместо !?MR1 скрипт работает гараздо коректнее. И выдает стэк монстра для любой магии.
При массовой магии выдает больший стэк (это у тебя написано).

Ну вот скрипт, определяющий номер стека, на который кастуют спэл.
Единственный минус - работает только для левой стороны (т.е. для атакующего героя). Кому интересно, думаю подправят сами.

Вот.
!!IF:M^%V2^; - данная строка для наглядности.

Добавлено ([mergetime]1190928177[/mergetime]):
Для правой стороны делать в лом.

Как данный скрипт работает для массовых заклинаний?
Что находится по адресу 61810740?

Показывает, больший стэк. Т.е. если кастуют на 23 и 24 стэк, то покажет 24.
По адресам 61810740 - 61810760, как я понял, флаги для стэков 21-41 соответственно, показывает кастуют ли на стэк.

Примечание по "Цепная Молния и MR2":
Когда Молния "перепрыгивает" с вражеских юнитов на ваши (наоборот не проверял), то номер стэка считается как следующий вражеской стороны.
Т.е., к примеру, если у врага было только два стэка с монстрами (21 и 22 соответственно), то номер стэка вашего поражённого отряда будет не 6 (к примеру), а 23! И так далее, если молния продолжает бить по вашей армии.

[sergroj] Перенес сюда. Номер отряда Бес вычислял по изложенному выше способу через числа, возвращеемые MR:N.

Есть такой баг у команды !!UN:O - этой командой нельзя удалить с карты лодку (пустую), тип 8.
Однако этот баг можно обойти - для этого всего лишь нужно предварительно сменить тип объекта (лодки) на, скажем, 83-ий - хижину провидца (она совпадает с лодкой по "клеточности"). А уже потом эту "лодку-хижину" можно смело удалять с карты путём !!UN:O. Проверено.

!!BM:U4, похоже, не действует.

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


Не срабатывает с массовой магией.

!!DL очень сырой ресивер. Очень часто вылетает без видимой причины - иногда просто достаточно поменять местами два никак не связаных друг с другом оператора, чтобы прекратило вылетать.

Или например !!DL:H - это нечто... У меня !!DL:H4/z900 прекрасно работает, а !!DL:H4/z920 вылетает при попытке отобразить диалог. Причина науке неизвестна.

!!OB:M
если использовать !!OB998:M-1/1/1; то курсор мыши становится невидимым, и возвращается тоько после завершения работы с открывшимся диалогом объекта. Хотя мышь юлозит и курсор какбы имеется (только без графики)

!!CM:F
При щелчке по кнопкам в !?CM5; возвращает всегда 0. Возможно, не только по кнопкам или не только в !?CM5;. Я не проверял. Про этот баг уже писали, но неясно:

2Миханик
Уточни плз, на какие именно кнопки нельзя нажимать. Можешь привести простенький код, демонстрирующий глюк.

Кнопки - это !!CM:I 3..12. я словил глюк на 8. вот код, должно заглючить:
с какими кнопками не нажимай, всегда покажет 0.

У меня ошибку выдает.
"GetNum" - Cannot get flag
Кнопки, когда они не активны, не вызывают при нажатии триггер ERM. Когда активны - вызывают. Но клавиши Alt, Ctrl, Shift не оказывают влияния. Кроме того выдается ошибка.