(20.04.2020 18:10)XEPOMAHT Wrote:  Плохо тем, что нужен хотя бы 1 человек, который будет заниматься систематизацией, обновлением и добавлением новых erm-функций. Который послезавтра не положит болт с резьбой на это дело.

Git с доступом для нескольких проверенных модеров. + Тема с предложением/обсуждением нововведений или корректировок.

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

В ERA Plus нужно просто вызывать RedirectMemoryBlock, как я делаю в нескольких местах Typhon 2.72. В результате !!UN:C будет работать с адресами перенесённых структур. Там таблица поиска в памяти вида [старый адрес, новый адрес, размер старой структуры].

Во всём остальном Zur13 прав. Библиотеки решают массу проблем, обеспечивают совместимость через сокрытие деталей реализации и разгружают «базу». Например, в языке СИ почти всё, что можно, вынесено на уровень библиотек, а не средств языка.

(21.04.2020 06:02)Berserker Wrote:  В ERA Plus нужно просто вызывать RedirectMemoryBlock, как я делаю в нескольких местах Typhon 2.72. В результате !!UN:C будет работать с адресами перенесённых структур. Там таблица поиска в памяти вида [старый адрес, новый адрес, размер старой структуры].

Пока что страшусь использовать RedirectMemoryBlock, т.к. она довольно не простая (с тем, чтобы просто указать ЭРЕ на расширенную таблицу монстров, мне пришлось дожидаться твоей версии Typhon и потом ещё искать место в коде, из которого RedirectMemoryBlock срабатывала корректно). И в ERA Plus RedirectMemoryBlock можно использовать только для структуры монстров, к которой часто обращаются через ERM и плагинами, остальные структуры, которые были перенесены, моддерами почти не используются (попадаются такие ERMэшники-экстрималы, но они обычно за километр обходят ERA Plus ), поэтому жду того времени, когда ERM в era.dll больше не будет изменяться и тогда можно будет менять ERM уже в ERA Plus с поддержкой всех перенесённых структур.

XEPOMAHT, функция элементарная. Приведи пример старого адреса, названия переменной с новым и размера старой области. Я напишу код вызова (там одна строка). Через UN:C сам увидишь, что всё верно работает.

Пример: таблица запрета артефактов (та самая, из-за которой до сих пор ругается ERM при загрузке карты в ERA PLUS)

Старый адрес: [699538h]+4E2B4h
Название переменной: Таблица_запрета_артефактов
Новый адрес: [699538h]+4E2B4h+321488
Размер старой области: 90h

XEPOMAHT, сразу после патча на подмену адреса.

В ЕРМ

(21.04.2020 17:57)Berserker Wrote:  В ЕРМ

Теоретически, должно быть так:


К у2 точно прибавится 321488, чтобы получить новый адрес??? Ведь на твой RedirectMemoryBlock посылаются реальные адреса памяти, а скрипт оперирует сложением с базовым.

И что будет, если где-нибудь в другом месте встретится число 3282056 (или случайно произойдёт совпадение реального адреса с каким-нибудь числом в скрипте, мне не известно, как срабатывают проверки при обработке данных из RedirectMemoryBlock), не имеющее никакое отношение к таблице запрета артефактов???

Точно, неверно смещение скопировал. У тебя верный код.
Ничего нигде не совпадёт. Игра запускается, адрес [699538h]+4E2B4h становится фиксированным и известным. Назовём его X.
Тогда таблица занимает память [X..X + 0x90 - 1].
Новая таблица у тебя перенесена в память [Y..Y + очень много - 1]
У Эры есть запись, что [X..X + 0x90 - 1] нужно транслировать в [Y..Y + 0x90 - 1]

Мы в ЕРМ в любом месте получаем старый адрес X

Затем находим его новый адрес:

После чего имеем "Y". Можно смело прибавлять индекс артефакта * размер записи для артефакта, чтобы сослаться на запрет конкретного артефакта. Всё. Никаких багов, ошибок, двусмысленностей.

Пример, перенос с адреса 1000 структуры на 200 байт на адрес 2000.
Было 1000..1199, стало 2000..2499 (структура расширена).

Для безопасной работы с расширенными структурами нужно не по 1000 + номер арта * 4 проводить работу, а сперва получить реальный базовый адрес структуры.
GetRealAddr(1000) = 2000.
Всё, теперь прибавляй, что хочешь.

В Era 2.9.13 есть команда !!UN:C[базовый адрес]/[смещение]/[размер]/[значение].
Вот она работает в точности так, как описано выше. Сперва получает реальный адрес для базового, только потом прибавляет смещение.

---

Чёрт. Понял, что написал полный бред. Херомант, ну ты и затейник. Если ты расширил таблицу путём изменения указателя в структуре данных, то не нужны RedirectMemoryBlock и GetRealAddr вообще. У тебя по

!!UN:C6919480/4/?y1;
!!VRy1:+320180; y1 - всегда актуальный адрес

Вот если ты расширяешь статичную область памяти (например, строго по 0x500000 размером 1000 байт), на которую нет единого указателя, вот тогда и нужен RedirectMemoryBlock.

(21.04.2020 18:56)Berserker Wrote:  У тебя по

!!UN:C6919480/4/?y1;
!!VRy1:+320180; y1 - всегда актуальный адрес

Ага, если конечно ХЕРОМАНТ будет в 6919480 заносить адрес смещенной таблицы))

igrik, если не будет, то это ахтунг )))

(21.04.2020 19:18)igrik Wrote:  если конечно ХЕРОМАНТ будет в 6919480 заносить адрес смещенной таблицы))

Не, точно не будет, т.к. расширению базовой структуры ничего не мешает (в чём её огромный плюс). Главное, чтобы этим занимался только 1 плагин в ERA, иначе будет истинный ахтунг.

XEPOMAHT, вот как это понимать? Весь геройский код работает со старой таблицей? Если с новой и ты патчишь код для новых смещений, то это в корне неверно. Нужно просто подменить адрес.

(21.04.2020 22:32)Berserker Wrote:  Весь геройский код работает со старой таблицей?

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

(21.04.2020 22:32)Berserker Wrote:  Если с новой и ты патчишь код для новых смещений, то это в корне неверно. Нужно просто подменить адрес.

Если бы было всё так просто, новые города в WoG появились бы ещё в 2005 году. Замена адреса на всю таблицу работает только для небольших и простых изолированных таблиц, типа таблицы монстров (что в WoG было реализовано ещё в 2001 году). Крупные массивы данных типа базовой структуры - только через непосредственное перераспределение данных в памяти бинарным патчем. А вот данные стека уже переносятся только заменой кода (т.к. менять адресацию в стеке так, чтобы работа функций при этом не нарушилась - полный хардкор).

Не соглашусь. Пусть есть большая структура, которая состоит из трёх других структур, разделённых мусором.
Пусть есть указатель на эту большую структуру, например [699538h].

Тогда патчим все смещения от этой большой структуры до трёх подструктур так, чтобы итогово смещение = новый адрес подструктуры - адрес начала большой старой структуры.
Вызываем RedirectMemoryBlock, как в зачёркнутом посте выше для каждой подструктуры.

В результате получаем совместимость с плагинами и lua/erm-скриптами, который будут использовать UN:C или GetRealAddr.

!!UN:C6919480/4/?y1;
!!VRy1:+320180; y1 - адрес старой подструктуры запрещённых артефактов

!!UN:Cy1/смещение/4/?y2; прочли данные уже из новой

mov eax, [699538h]
add eax, 4E2B4h; eax - старый адрес
lea ecx, [eax + 641668]; ecx - новый адрес. Смещение вроде бы верно расчитал
stdcall [RedirectMemoryBlock], eax, 90h, ecx

(22.04.2020 04:48)Berserker Wrote:  Тогда патчим все смещения от этой большой структуры до трёх подструктур так, чтобы итогово смещение = новый адрес подструктуры - адрес начала большой старой структуры.
Вызываем RedirectMemoryBlock, как в зачёркнутом посте выше для каждой подструктуры.

Хорошо, к примеру была таблица по адресу 6666, с помощью RedirectMemoryBlock указываем, что она переместилась на 6667. Какой-нибудь левый скрипт использует следующий код:

!!VRy1:S1;
!!VRy1:+6665;

Что получится в итоге? 6666 или 6667?

И если честно, мне плохо понятен принцип работы RedirectMemoryBlock. Она проверяет значения при каждой математической операции? Смещения могут быть очень маленькими, что в итоге может превратить любой ERM-код в тыкву. Технического описания по RedirectMemoryBlock по-прежнему нету (соответственно, когда не знаешь последствий от использования данного вызова, сложно с ней работать, принцип чёрного ящика здесь не работает).

Так же могут быть одинаковые смещения, но по разным базовым адресам для совершенно разных данных - с этим что делать?

Так же может использоваться прямая адресация от базового значения, без использования адреса субтаблиц (т.к. адрес сразу вычисляется для определённой ячейки первой строки таблицы, а не её начала, чтобы использовать, например, в цикле).