Threaded Mode | Linear Mode

Zur13 · 19.04.2020 04:00

Может кто-то помочь, мне нужно в бою динамически изменять описание юнита в окне по ПКМ на нем, само открытие окна ПКМ я думаю смогу поймать через триггер ММ0, но если в нем менять дескрипшн юнита например через

!!FU7701:P1/2/2/192514; или через МА

то в окне всё-равно остается старый дескрипшн. Я попробовал способ отсюда https://forum.df2.ru/index.php?showtopic...t&p=193891 , но что-то функция для получения адресов Z переменных из следующего сообщения в той ветке не работает, я вот про эту функцию

Code:

!?FU12925; Получение адреса z переменной номер x1 (возврат в x2)

Поддерживаются версии: 3.58, ТЕ

!!UN:V?y1/?y2;

!!VRy3&y1=358:S40225400;

!!VRy3&y1=359:S9597416;

!!VRx2&y3=0:S0;

!!FU&y3=0:E;

!!VRx2:Sx1*512+y3;

daemon_n · 19.04.2020 04:03

Zur13, а если "обновить" экран?

Zur13 · 19.04.2020 10:48

(19.04.2020 04:03)daemon_n Wrote: Zur13, а если "обновить" экран?

Я попробовал BU:R, но явно проблема не в нем, новый текст появляется только в следующей битве, а до конца текущей так и остается изначальное описание, так что похоже что эти строки где-то кешируются до начала битвы. Я вот про этот текст:

Правка: в общем частично удалось сделать, просто адрес новой строки получил с помощью куска кода из FUN.erm как-то так:

!!SN:E7824928/1/192517; !!VRy31:Sv1;

Но этот код не обрабатывает строку, в том смысле что нельзя подставлять туда значения переменных типа %Y1, может есть другой способ? Пока у меня в ММ0 триггере вот такой код:

Code:

!!SN:E7824928/1/192517; !!VRy31:Sv1;    [y31, mem address of z192517]

!!BMy1:G-66/?y30/d;                     [y30, mem address of stack's y1 description text]

!!FU12926:Py31/y30;                     [copy mem bytes from y31 to y30]

!?FU12926; Копирование строки по адресу. x1 - источник, x2 - приемник.

!!DO12927/0/511/1:Px1/x2;

!?FU12927;

!!VRy1:Sx1+x16;

!!VRy2:Sx2+x16;

!!UN:Cy1/1/?y3Cy2/1/y3;

!!VRx16&y3=0:S511;

Правка 2: оно похоже еще и что-то портит в памяти потому что иногда игра вылетает с таким кодом. Нужны другие варианты...

igrik · 19.04.2020 14:57

(19.04.2020 04:00)Zur13 Wrote: Может кто-то помочь, мне нужно в бою динамически изменять описание юнита в окне по ПКМ на нем

1. Конечно будут утечки памяти.
2. Обрати внимание! Тут есть новый синтаксис рессиверов BM0 и UN:C (мне куда удобнее новый синтаксис. Но он не будет работать на старых версиях ЭРЫ)
Можно сделать и через старый синтаксис - как? Читай тут (под спойлером я показал разницу кодов ERM, которые делают одно и то же)

Berserker · 19.04.2020 16:49

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

Zur13 · 19.04.2020 17:34

(19.04.2020 14:57)igrik Wrote:
(19.04.2020 04:00)Zur13 Wrote: Может кто-то помочь, мне нужно в бою динамически изменять описание юнита в окне по ПКМ на нем

1. Конечно будут утечки памяти, ни у хрен с ними. Это уже более сложна... Не такие уж и большие утечки будут))
2. Обрати внимание! Тут есть новый синтаксис рессиверов BM0 и UN:C (мне куда удобнее новый синтаксис. Но он не будет работать на старых версиях ЭРЫ)
Можно сделать и через старый синтаксис - как? Читай тут (под спойлером я показал разницу кодов ERM, которые делают одно и то же)

Спасибо, работает супер! Вот код, работает и для старой ЭРЫ если кому надо, с подчисткой памяти (заточено на один стек, перед показом окна сменили текст FU(имя вашей функции для смены описания), сразу после показа окна вернули как было FU(имя вашей функции чтобы вернуть как было)):

Code:

********************************************************************************​

**  Function to change stack description to new one

********************************************************************************​

** x1 == stack ID

!?FU(имя вашей функции для смены описания);

!!VRz9:S^New stack description text^;

!!VRy2:S9 *512 +9597416;                 [y2, new z9 mem addr]

*!BM0:Z?y1; [получаем структуру первого стека атакующей стороны (стек 0) в y1]

!!UN:C6919200/4/?y10;                    [y10, BattleManager struct addr]

!!VRy1:Sx1 *1352 +21708 +y10;            [y1, desired stack struct]

!!VRy1:+144;                             [y1, add shift for monster stack description text reference]

!!UN:Cy1/4/?y3;                          [y3, initial monster desc reference]

!!UN:Cy1/4/y2;                           [change initial monster desc reference to new one]

!!SN:W^имя вашей переменной^/?y4;     [y4, get initial monster desc reference]

!!SN&y4=0:W^имя вашей переменной^/y3; [store initial monster desc reference]

********************************************************************************​

**  Function to restore original stack description

********************************************************************************​

** x1 == stack ID

!?FU(имя вашей функции чтобы вернуть как было);

!!VRy2:S9 *512 +9597416;                 [y2, new z9 mem addr]

*!BM0:Z?y1; [получаем структуру первого стека атакующей стороны (стек 0) в y1]

!!UN:C6919200/4/?y10;                    [y10, BattleManager struct addr]

!!VRy1:Sx1 *1352 +21708 +y10;            [y1, desired stack struct]

!!VRy1:+144;                             [y1, add shift for monster stack description text reference]

!!SN:W^имя вашей переменной^/?y3; [get initial monster desc reference]

!!UN&y3<>0:Cy1/4/y3;                     [restore initial monster desc reference]

!!SN:W^имя вашей переменной^/0;   [reset storage]

Algor · 19.04.2020 19:41

... вот и еще одна полезная функция для общей библиотеки. Да, Берс?

Berserker · 19.04.2020 20:31

Algor, конечно. Но каждый продукт выпускается отдельно (мод ли, пакет из репозитория ли), имеет своих maintainers (команда поддержки), семантические версии, возможность зависимости модов от них (как в последнем менеджере модов от SyDr) и обновляются с частотой, не связанной с частотой обновления условного движка.

Я отпустил моды в свободное плавание и рад этому. Сейчас огромная сборка держится на том, что daemon_n тратит 90% своего времени на неё. Изменятся жизненные обстоятельства и никто её в текущем виде не обновит. Модульность и разделение ответственное — наше всё. А потом появляются люди, готовые объединить ряд модов в один установщик.

Bes · 19.04.2020 20:48

Berserker, он тебя троллит.. 103

Quote:Модульность и разделение ответственное — наше всё.

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

Berserker · 19.04.2020 23:32

Bes, десяток моддеров пишет удобные для установки моды, 1 человека объединяет их в сборку для масс. Противоречий нет.

Bes · 19.04.2020 23:57

а когда не станет такого "сборщика вкуснятины"? всё опять в застой провалится?
печально будет Sorry

Algor · 20.04.2020 02:00

Berserker, ок, пусть FUN остается в рамках ES и каждый по мере необходимости вытаскивает себе нужные куски. Или всё целиком, как посчитает нужным.

~~А потом я психану, поправлю пару имен и куча подсаженных на FUN модов перестанет работать~~ Spiteful

Bes · 20.04.2020 02:40

Algor, ну хоть оправдаешь тогда название этой "весёлой" солянки... ты всех предупредил задолго до часа икс 148

igrik · 20.04.2020 02:53

(20.04.2020 02:00)Algor Wrote: Berserker, ок, пусть FUN остается в рамках ES и каждый по мере необходимости вытаскивает себе нужные куски. Или всё целиком, как посчитает нужным.

~~А потом я психану, поправлю пару имен и куча подсаженных на FUN модов перестанет работать~~

Давай я создам такую библиотеку в Wog Scripts

Berserker · 20.04.2020 03:31

igrik, не лучше ли отдельный мод?

Threaded Mode \| Linear Mode Вопросы по моддингу » (обсуждаем моддинг здесь)
Author	Message