XEPOMAHT, таблицы нельзя переносить сами в себя, ты это знаешь. Иначе никакой код работать нормально не будет. Всегда в отдельную, непересекающуюся память.

RedirectMemoryBlock запоминает конкретную физическую область памяти с абсолютным начальным адресом и абсолютной длиной.
Пример: с адреса 6000 длиной 550 байт. Запомнили диапазон [6000..6549]. Это реальные старые адреса.
А новые, например, [100000..100549]. Их преобразование — элементарная задача двоичного поиска и замены.

Херомант, тут смешались в кучу кони, люди.

1) Код игры ты патчишь так, как нужно, чтобы он работал с новыми адресами структур.
2) Ты всегда можешь определить старый абсолютный адрес [под]структуры и новый. С ними и вызывай RedirectMemoryBlock.
2) Код lua/erm скриптов будет использовать UN:C и GetRealAddr. Если есть опасение, что подструктуры перенесены в разные области памяти, то GetRealAddr вызывается для каждой подструктуры. Сперва определяем новый адрес подструктуры, потом к нему прибавляем уже смещение. То, что в коде игры нас не интересует.

(22.04.2020 17:29)Berserker Wrote:  таблицы нельзя переносить сами в себя, ты это знаешь. Иначе никакой код работать нормально не будет. Всегда в отдельную, непересекающуюся память.

Вообще-то так и делаю, т.к. чтобы изменить значение базового адреса таблицы - не хватит всей жизни (базовый адрес может передаваться от функции к функции через сотни, если не тысячи, функций, он постоянно где-нибудь да хранится (в стеке, переменных, до которых простым бинарным патчем не доберёшься), данные, зависящие от базового адреса, используются повсеместно, поэтому потребуется изменить ВЕСЬ КОД ИГРЫ только ради одной таблицы).

А вот перенесение данных внутри одной структуры в одной единой области памяти с сохранением базового адреса неизменным - то, что реально работает (и не только в MoP/ERA PLUS, но и ещё в одном очень известном глобальном моде). Быстро и эффективно, прошло проверку временем, но увы, не дружит с RedirectMemoryBlock (а может быть и дружит, только до сих пор непонятно как можно оформить вызов RedirectMemoryBlock с правильными адресами).

Скажете, что будут утечки памяти из-за использования стандартной области памяти Третьих Героев без выделения отдельной непересекающейся памяти через dll? А вот нет, утечек не происходит, герои бегают по карте и строят Причалы с Форджами , значит, считаю, что в плане кода, добавляющего новые игровые фракции, всё сделано правильно (только противоречит нормам профессиональных программистов, но главное не нормы, а результат). Минус естественно в совместимости с большинством модов для ERA, которые с помощью GetRealAddr не смогут получить правильные адреса, тут я тоже ничего придумать не могу

В общем, то, что кажется немыслимым для одних людей, - норма для других. ERA PLUS всегда будет модом-изгоем - это плата за быстрое добавление в ERA новых игровых фракций. С MoP вот всё гораздо проще - никто не делает моды под MoP.

XEPOMAHT, присутствует путаница в рассуждениях.
Повторюсь:
Можно сохранить базовый указатель на большую структура а-ля ИГРА.

ИГРА {
    мусор
    мусор
    таблица портретов
    мусор
    таблица запрещённых приёмов
    мусор
    таблица внебрачных связей
}

Можно при этом перенести любые подструктуры/таблицы на любые адреса.
В коде игры к таким подструктурам обращения будут следующие: [ИГРА] + Смещение.
Можно изменить Смещение так, что конечный адрес будет указывать на любое место в оперативной памяти (могут потребоваться хуки, если размер смещения не 4 байта.

Далее.
Можно сообщить плагинам/Эре/скриптам соответствие старых адресов подструктур новым.

Где я не прав?

Quote:Можно изменить Смещение так, что конечный адрес будет указывать на любое место в оперативной памяти (могут потребоваться хуки, если размер смещения не 4 байта.

Собственно, в хоте с героями так и сделано

(22.04.2020 20:00)Berserker Wrote:  Можно при этом перенести любые подструктуры/таблицы на любые адреса.

У меня примерно так:

Было:

ИГРА {
0 - мусор
100 - стартовая структура героев
200 - мусор
300 - таблица портретов
330 - мусор
400 - таблица самих героев
600 - мусор
1000 - конец таблицы
}

Стало:

ИГРА {
0 - мусор
100 - таблица портретов
160 - пусто
200 - мусор
300 - пусто
330 - мусор
400 - стартовая структура героев
600 - мусор
1000 - таблица самих героев
1400 - конец таблицы
}

И как такие изменения сообщить плагинам/Эре/скриптам?

(22.04.2020 20:02)feanor Wrote:  Собственно, в хоте с героями так и сделано

В WoG 3.59 тоже. Как будто один человек всё делал.

В твоём примере
RedirectMemoryBlock([ИГРА] + 100, размер = 100, [ИГРА] + 400)
RedirectMemoryBlock([ИГРА] + 300, размер = 30, [ИГРА] + 100)
RedirectMemoryBlock([ИГРА] + 400, размер = 200, [ИГРА] + 1000)

(22.04.2020 20:43)Berserker Wrote:  В твоём примере
RedirectMemoryBlock([ИГРА] + 100, размер = 100, [ИГРА] + 400)
RedirectMemoryBlock([ИГРА] + 300, размер = 30, [ИГРА] + 100)
RedirectMemoryBlock([ИГРА] + 400, размер = 200, [ИГРА] + 1000)

Спасибо, теперь понятно. Теперь осталось узнать список всех таблиц, для получения адресов которых в era.dll применяется GetRealAddr.

Т.к. патч на игровые фракции переносит 77 таблиц, думаю, что 90% из них скрипты/плагины не используют (т.к. мало кто о них что-нибудь знает).

Я пока только частично использую, там, где нужно:

вопрос, можно ли добавлять/изменять флаги существам без тифона? по типу летает/стрелок/нежить и т. п.

Элементалист, можно через erm, например ресивер !!МА. Если нужно что-то конкретное, спрашивайте здесь:

http://wforum.heroes35.net/showthread.ph...92&page=47

there is a way to add heroes and other monoliths?

(29.04.2020 21:26)ElfbI Wrote:  Элементалист, можно через erm, например ресивер !!МА. Если нужно что-то конкретное, спрашивайте здесь:

http://wforum.heroes35.net/showthread.ph...92&page=47

Про ерм знаю, хочется без скриптов обойтись, чисто правкой текстовиков . Мучает лишь незнание того, какой текстовик править: crtraits, crtrait0 или zcrtrait?

(22.04.2020 20:59)Berserker Wrote:  Я пока только частично использую, там, где нужно:

Code:

...
HeroSpecsTable             := GameExt.GetRealAddr(HeroSpecsTable);
HeroSpecsTableBack         := GameExt.GetRealAddr(HeroSpecsTableBack);
HeroSpecSettingsTable      := GameExt.GetRealAddr(HeroSpecSettingsTable);
...

По новым героям совместимость с ERA потребуется по этим таблицам. А именно:

*) HeroSpecsTable успешно переносится, но: игра всегда узнаёт её адрес из переменной по адресу 679C80, поэтому необходимости в GetRealAddr(HeroSpecsTable) абсолютно никакой не вижу.
*) HeroSpecsTableBack не используется вовсе (если ERA что-то делает с этой таблицей, то как-то эти действия нужно будет как-то отменять).
*) HeroSpecSettingsTable не перенесена, а данные в ней оптимизированы (т.е. длинна строки уменьшена с 40 до 16 байт). Если ERA что-то читает от туда, то чтение будет проходить не верно (и опять все манипуляции ERA с этой таблицей придётся как-то отменять). Если не менять формат (т.е. оставить вог-копирование вместо отдельного загрузчика), то эту таблицу всё равно переносить не нужно, т.к. прямо за ней расположены пустые данные (когда-то там была ещё одна таблица).

(30.04.2020 11:25)XEPOMAHT Wrote:  *) HeroSpecSettingsTable не перенесена, а данные в ней оптимизированы (т.е. длинна строки уменьшена с 40 до 16 байт). Если ERA что-то читает от туда, то чтение будет проходить не верно (и опять все манипуляции ERA с этой таблицей придётся как-то отменять). Если не менять формат (т.е. оставить вог-копирование вместо отдельного загрузчика), то эту таблицу всё равно переносить не нужно, т.к. прямо за ней расположены пустые данные (когда-то там была ещё одна таблица).

Эта не та таблица, которая сжата в campaign heroes as start heroes.bin?

(30.04.2020 13:43)igrik Wrote:  Эта не та таблица, которая сжата в campaign heroes as start heroes.bin?

Нет. Под HeroSpecSettingsTable подразумеваю таблицу по адресу 278420h из exe, в которой находятся настройки специализаций героев (изначально, она использовалась кодом игры напрямую, но какой-то великий умник в WoG Team вместо 1й единой таблицы специализаций сделал ЧЕТЫРЕ . В MoP/ERA+ это дело уменьшено до двух: одна собственно игровая и вторая сжатая исходная, из которой данные загружаются в игровую, включая моменты восстановления а-ля бэкапа).

Если скляроз не изменяет, campaign heroes as start heroes.bin ужимает данные в стеке от диалога настроек карты (которые тоже можно было перенести, но... бинарный патч не позволяет выделять память, да и HD-мод всё равно не увидит её и будет продолжать вылетать при попытке вывода улучшенного окна стартового героя, которое... HD-мод для ERA не выводит и не должен выводить , зачем так сделано? Скорее всего просто от лени и нежеланием заниматься поддержкой воговщины, к примеру, мне тоже воговский код не нравится, но постепенно всё-таки переписываю его в рамках MoP, правда под ERA уже сложно что-то переписать опять из-за совместимости).