Threaded Mode | Linear Mode

XEPOMAHT · 13.12.2020 00:03

(12.12.2020 18:27)Berserker Wrote: не поделишься патчем на исправление телепортов?

Из MoP (для ERA некоторые адреса могут быть другими, ну и формат сохранений тоже поменяется, т.к. туда запишется инфа о 16 порталов вместо 8):

Code:

; map_portals 1 side

    mov esi, <адрес базовой структуры, куда переносятся данные>

    mov byte [4BD672h], кол_во_порталов - 5

    mov dword [4BD6D5h], esi

    mov byte [4BEA26h], кол_во_порталов

    mov byte [4BEA4Eh], кол_во_порталов

    mov dword [4BEA2Eh], esi

    mov byte [4BF092h], кол_во_порталов

    mov dword [4BF0DEh], esi

    mov dword [4C131Dh], esi

    mov dword [4CDA84h], esi

    mov byte [4CDF51h], кол_во_порталов

    mov byte [4CDF6Fh], кол_во_порталов

    mov dword [4CDF72h], esi

    mov byte [4CE398h], кол_во_порталов

    mov byte [4CE3AEh], кол_во_порталов

    mov dword [4CE388h], esi

    mov dword [56B10Ch], esi

    mov byte [62CA45h], кол_во_порталов

    mov byte [62CA5Dh], кол_во_порталов

    mov dword [62CA64h], esi

    mov byte [62CBE1h], кол_во_порталов

    mov byte [62CBF9h], кол_во_порталов

    mov dword [62CC00h], esi

    mov dword [713EB9h], esi

    add esi, 4

    mov dword [4BF0D7h], esi

    mov dword [4C1324h], esi

    mov dword [713EB2h], esi

    add esi, 4

    mov dword [4BF0E5h], esi

; map_portals 2 side

    mov esi, <адрес базовой структуры, куда переносятся данные>

    mov dword [4BD682h], esi

    mov dword [4BEA06h], esi

    mov dword [4BF0A4h], esi

    mov dword [4C141Dh], esi

    mov dword [4CDAC6h], esi

    mov dword [4CDF54h], esi

    mov dword [4CE3B1h], esi

    mov dword [56B154h], esi

    mov dword [62CA4Ch], esi

    mov dword [62CBE8h], esi

    mov dword [70895Fh], esi

    mov dword [713E94h], esi

    add esi, 4

    mov dword [4C1416h], esi

    mov dword [713E8Dh], esi

    add esi, 4

    mov dword [4BF09Dh], esi

    mov dword [4C2811h], esi

Berserker · 13.12.2020 01:26

XEPOMAHT, спасибо 132

Раз уж для расширения числа монолитов нужно патчить код и менять формат сохранений, почему бы не встроить в Эру сразу все 26, как ты сделал в МоР? С идентичной графикой и подтипами. Будет 100%-ая преемственность. Патч я сделаю через патчер бараторча. Нужны будут дефы и записи для добавления в txt-файлы.

XEPOMAHT · 13.12.2020 02:06

(13.12.2020 01:26)Berserker Wrote: Раз уж для расширения числа монолитов нужно патчить код и менять формат сохранений, почему бы не встроить в Эру сразу все 26, как ты сделал в МоР?

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

(13.12.2020 01:26)Berserker Wrote: Патч я сделаю через патчер бараторча. Нужны будут дефы и записи для добавления в txt-файлы.

Там считай порт всех хотовских монолитов + из WoG-фикса. Ничего нового. Если делать патчером Бараторча, то придётся ставить кучу хуков на все адреса и делать отвязку от базовой структуры (как это сделать так, чтобы игра при этом не глючила - придётся разбирать сами функции, в пример плагин на loop sounds, где сделана отвязка от менеджера карты приключений, в итоге моды с loop sounds подглючивают неизвестно от чего на нестандпртных сборках. Это нужно для ERA? Думаю, порт всех объектов HoA->MoP->ERA+ лучше оставить мне (нужно просто подождать, когда вся работа будет доделана).

V_Maiko · 13.12.2020 02:19

XEPOMAHT, after having played with the new version of Assembly and with the distinctive features that wog native dialogs includes with XXL and HD mod, I'm fully accepting your idea of adapting XXL to ERA as HotA has done, the reason is simple, I don't feel comfortable playing other players' maps with XXL enabled because they don't work properly, I want to have the option to choose S to G in map size. You should present your MOP code to Berserker and see if he can implement it. I don't care about the problem that it will carry with HD mod, Bara could do something with that since it would be the same work that it carried with HotA.

Berserker · 13.12.2020 04:25

XEPOMAHT, game manager структура никому не будет нужна после применения патча и переноса монолитов. Это обычные массивы. Если можешь поделиться сборкой готовых def-ов/txt — поделись. Нет — возьму из WoG Fix 16 штук. Стандартных 8-и действительно мало.

Ещё раз по поводу базовой структуры. В коде обращение всегда идёт к массивам по адресу БАЗА + СМЕЩЕНИЕ до начала массива + СМЕЩЕНИЕ в массиве. Переносятся такие подструктуры в полпинка. Патч пишет НОВЫЙ АДРЕС МАССИВА - Старое смещение от начала GameManager до массива монолитов. Всё. Так переместить можно любую изолированную подструктуру. А ты всё время думаешь, что кто-то один должен кромсать весь GameManager

igrik · 13.12.2020 12:01

Berserker, моё предложение, если ты будешь менять адреса массивов:
Увеличивай пожалуйста саму структуру GameMgr, и пиши свои данные в конец. Это можно сделать по адресу 0x4EE2F3 push 4E7D0h (4E7D0h это нынешний размер).
Плюсы такого подхода:
- ты будешь править намного меньше самих указателей, т.е. для монолитов ты всего лишь изменишь смещение, но не основной указатель на GameMgr

Code:

// * +4E678

// * H3Position

H3Vector<UINT32> monolithTwoWay[8];

// * +4E6F8

// * H3Position

H3Vector<UINT32> monolithOneWay[8];

- таким же образом максимально безболезненно можно увеличить массив кол-ва героев и массив хозяевов героев, и банки, и гарнизоны и замки и т.п.
- не нужно слишком много париться об удалении этого массива - игра это сделает сама
- другим модам очень и очень легко получить доступ к твоему массиву
- также можно, и нужно расширить массив артефактов и массив доступности артефактов под WoG: randomArtifacts[170] и artifactsAllowed[170]

Code:

// * +4E224

INT8 randomArtifacts[144];

// * +4E2B4

INT8 artifactsAllowed[144];

- да и вообще, в возможном будущем, это даст тебе ряд преимуществ и упрощения работы.

Code:

template<typename _Elem>

struct H3Vector : H3Allocator

{

    BOOL _init; // useless

    // * the first item, also start of list

    _Elem *m_first;

    // * the end of last item

    _Elem *m_end;

    // * end of allocated memory

    _Elem *m_capacity;

}

struct H3Allocator

{

    PVOID operator new(const size_t sz);

    VOID  operator delete(const PVOID block);

    PVOID operator new[](const size_t sz);

    VOID  operator delete[](const PVOID block);

};

Это моё личное ИМХО. Но если бы я занялся этим процессом, я бы далал именно так.

XEPOMAHT · 13.12.2020 14:28

(13.12.2020 04:25)Berserker Wrote: В коде обращение всегда идёт к массивам по адресу БАЗА + СМЕЩЕНИЕ до начала массива + СМЕЩЕНИЕ в массиве. Переносятся такие подструктуры в полпинка. Патч пишет НОВЫЙ АДРЕС МАССИВА - Старое смещение от начала GameManager до массива монолитов. Всё. Так переместить можно любую изолированную подструктуру.

А ничего что код игры может задать ОДИН базовый адрес и использовать его на протяжении сотни функций, не меняя его? Т.е. если изменишь этот НОВЫЙ АДРЕС МАССИВА, то он измениться в куче функций и игра полетит к майкрософту. Если что, я не понимаю твоих предложений по переносу данных базовой структуры (я переношу по-старике).

(13.12.2020 12:01)igrik Wrote: Увеличивай пожалуйста саму структуру GameMgr, и пиши свои данные в конец. Это можно сделать по адресу 0x4EE2F3 push 4E7D0h (4E7D0h это нынешний размер).

Не стоит, т.к. в ERA+ уже так сделано и если Берсеркер сделает так же в ЭРЕ, то данные базовой структуры будут испорчены (например я пишу туда структуры героев + все данные, которые идут после них).

igrik · 13.12.2020 15:06

(13.12.2020 14:28)XEPOMAHT Wrote: Не стоит, т.к. в ERA+ уже так сделано ...

Разве? Я проверил на текущейм моде ERA+, перед тем как написал, и вот что я увидел:

Image: image.jpg

XEPOMAHT · 13.12.2020 16:33

(13.12.2020 15:06)igrik Wrote: Я проверил на текущейм моде ERA+, перед тем как написал, и вот что я увидел

Версия ERA+ с поддержкой новых героев не выкладывалась ещё, т.к. не готова к релизу. Чтобы не было как в басне "Лебедь Рак и Щука" и чтобы потом не думать о том, как в era.dll отключить мешающие ERA+ патчи и хуки, необходимо сразу распределись области памяти, которые патчат те или иные dll, т.е. делать это централизовано, а не как придётся.

Например ERA+ забирает себе _GameMgr_, _AdvMgr_, а так же все таблицы городов/героев/монстров/артефактов/двеллингов. Т.е. если нужна совместимость с ERA+, то переносить всё это нельзя (т.к. уже перенесено) и обращение к данным из этих таблиц - по базовым адресам, кроме структуры героев (её адрес не изменяется в рамках совместимости с кучей эровских плагинов и HD-модом).

Давайте уже работать в команде, а не порознь. Даёшь ERA Team.

igrik · 13.12.2020 23:55

(13.12.2020 16:33)XEPOMAHT Wrote: Давайте уже работать в команде, а не порознь. Даёшь ERA Team.

Да я и не против

Berserker, кстати, почему до сих пор для генерации случаного монстра мы пользуемся Содовской функцией, которая вообще не генерирует Воговских существ? Почему не переписать её, чтобы учитывались все существа.

Например как то так, чтобы не заморачиваться с компактным массивом и установкой битов как в СоДе (благо на нынешних компах памяти тьма) (Click to View)

Code:

_int_ __stdcall GameMgr_GetRandMonster_ByLevel(HiHook* hook, _GameMgr_* gm, int mon_lvl_Lo, int mon_lvl_Hi)

{

    // проверка на дурака 1

    if ( mon_lvl_Lo < 0 || mon_lvl_Lo > 6) {

        b_MsgBox("Please use the monster level 0-6", 1);

        return 0;

    }

    // проверка на дурака 2

    if ( mon_lvl_Hi < 0 || mon_lvl_Hi > 6) {

        b_MsgBox("Please use the monster level 0-6", 1);

        return 0;

    }

    // проверка на дурака 3

    if ( mon_lvl_Lo > mon_lvl_Hi ) {

        b_MsgBox("Are you kidding?!", 1);

        return 0;

    }

    // количество монстров в игре 

    // тут нужно учесть и Тифон, и Аметист, 

    // но и не гонять циклы в пустую (поэтому откуда бы считать?)

    int count = 196;

    // инициализируем массив (в Аметисте 1024)

    char monArray[1024];

    // заполняем массив нулями

    for(int i = 0; i < 1024; i++)

        monArray[i] = 0;

    // собираем массив монстров нужного уровня 

    for(int i = 0; i <= count; i++) {

        int lvl = o_CreatureInfo[i].level;

        if (lvl >= mon_lvl_Lo && lvl <= mon_lvl_Hi)

            monArray[i] = 1; // монстр нужного уровня

    }

    // исключаем несуществующих монстров

    monArray[122] = 0;

    monArray[124] = 0;

    monArray[126] = 0;

    monArray[128] = 0;

    // исключаем Драколича

    monArray[196] = 0;

    // исключаем Супер Драконов (так делает SOD)

    for(int i = 132; i <= 135; i++)

        monArray[i] = 0; 

    // исключаем Боевые Машины

    for(int i = 145; i <= 149; i++)

        monArray[i] = 0;

    // исключаем Богов

    for(int i = 160; i <= 163; i++)

        monArray[i] = 0;

    // исключаем Командиров

    for(int i = 174; i <= 191; i++)

        monArray[i] = 0;

    // инициализация переменной

    int result;

    do { // ищем доступного монстра

        result = Randint(0, count);        

    } while ( !monArray[result] ); 

    // возвращаем id найденного монстра

    return result;

}

void StartPlugin()

{

    _PI->WriteHiHook(0x4C8F80, SPLICE_, EXTENDED_, THISCALL_, GameMgr_GetRandMonster_ByLevel);

    return;

}

XEPOMAHT · 14.12.2020 00:16

(13.12.2020 23:55)igrik Wrote:      // исключаем несуществующих монстров
    monArray[122] = 0;
    monArray[124] = 0;
    monArray[126] = 0;
    monArray[128] = 0;

    // исключаем Драколича
    monArray[196] = 0;

    // исключаем Супер Драконов (так делает SOD)
    for(int i = 132; i <= 135; i++)
    monArray[i] = 0;

    // исключаем Боевые Машины
    for(int i = 145; i <= 149; i++)
    monArray[i] = 0;

    // исключаем Богов
    for(int i = 160; i <= 163; i++)
    monArray[i] = 0;

    // исключаем Командиров
    for(int i = 174; i <= 191; i++)
    monArray[i] = 0;

В ERA+ монстры 122, 124, 126, 128 используются, и... генерируются содовским кодом на карте. Их принудительно запрещать не нужно.

Запрет Тифон ставит двумя хуками:

Code:

Hook 5410FDh, MonsterRandomGeneration,    TJump; запрет из таблицы запрета

      Hook 54110Fh, MonsterRandomGeneration2,    TJump; запрет при отсутствии дефа в текстовике

В Тифоне 3.XX поддержка генерации из всех 1000 слотов - надо будет подтягивать соответствующий код из MoP (т.к. Мастер его почему-то пропустил).

Raistlin · 14.12.2020 01:49

igrik, а Вы не будете против, если я приведённый Вами код использую у себя в проекте?

Berserker · 14.12.2020 03:33

Quote:Например ERA+ забирает себе _GameMgr_, _AdvMgr_, а так же все таблицы городов/героев/монстров/артефактов/двеллингов.

Мне видится правильным такой подход к разработке платформ, при котором обеспечивается максимально широкий доступ к модификациям, богатый формат описания объектов и отсутствие привязки к фиксированным значениям. То есть правильный плагин на новых монстров — это плагин, парсящий json из VCMI и предоставляющий API для получения адреса таблицы с монстрами, размера одной записи, максимального числа монстров, актуального числа монстров. Завязывать же всю игровую структуру, а то и все структуры на конкретном разработчике нельзя.

Вероятно, разумным будет предложить библиотеку с методами получения/установки адресов и пределов для всех основных игровых структур.
ПолучитьМаксимальныйИДМонстра, ПолучитьЧислоМонстров, ПолучитьТаблицуМонстров. Установить первое, втрое и третье.

Поскольку правильное расширение структур, на мой взгляд, должно иметь динамическую природу (монолитов 8, 50 или 100 зависит от содержимого json-конфигов), то и переносить подструктуры по методу Хероманта или Игрика не вариант. Исходный код gameManager->twoWayTeleports всё время генерирует команду доступа от базового адреса, который можно пропатчить смело, не боясь нарушить остальной код, поскольку далее будет всё тот же gameManager->другоеПоле, который компилятор не имел права оптимизировать. Доступ по указателю — это такая штука, которая предполагает, что значение указателя может измениться даже из соседнего потока. Потому чаще всего можно подструктуру перенести на массив динамического размера без последствий. Если найдёте в патче Хероманта доказательство обратного, сообщите, пожалуйста.

После переноса остаётся несколько вопросов:
-) Какой теперь новый адрес подструктуры?
-) Размер её элемента?
-) Количество элементов?

Вопрос, схожий с обсуждением RedirectMemoryBlock/GetAddr и решаемый на уровне АПИ и соглашений, а не на уровне «никто не имеет права расширять ни одну структуру кроме автора мода ХХХ». Стоит ещё раз подумать, какого АПИ хватило бы всем.

Для начала можно попробовать сделать 26 монолитов отдельным модом. Можно не вносить пока изменений в движок.

igrik, у меня в моде Mixed Neutrals всё есть: регистрация монстров, автоматическое их индексирование, функция генерации монстров по фракциям, включая союзные фракции, учёт ограничений по уровням и т.д. На текущий момент не вижу проблемы в том, чтобы используя мощь мода в пять строк написать скрипт, который пройдётся и заменит всех монстров на карте на случайные. Непринуждённо так и с сохранением уровня существ. В будущем плагин на новых монстров должен предоставлять схожее АПИ и да, подменять указанную функцию.

Была идея вычленить из Mixed Neutrals по сути подмод Monsters Framework, который и нужен всем скриптам для генерации монстров.

XEPOMAHT · 14.12.2020 11:45

(14.12.2020 03:33)Berserker Wrote: То есть правильный плагин на новых монстров — это плагин, парсящий json из VCMI и предоставляющий API для получения адреса таблицы с монстрами, размера одной записи, максимального числа монстров, актуального числа монстров.

1. Мне json из VCMI не нравится, там сложно разобраться человеку, не знакомому с программированием. Куда удобнее готовый редактор монстров из Тифона (аналог которого на каком-то ведре сделали и для Аметиста, т.к. ковыряние в *.cfg - не удобно), предоставляющий готовый набор бланковых монстров в рамках одного мода.
2. Готовых средств для работы с json ЭРА не предоставляет плагинописателям на ассемблере. Изобретать велосипед как-то не хочется (мне ещё предстоит осваивать обработку текстовиков для загрузки из них всех данных городов для моддеров, желающих добавлять свои города в ERA).
3. Сложность, сложность, сложность. API на новых монстров должно быть встроено в саму ЭРУ тогда уж. Но вот практическая польза от этого какая? Исходных кодов самой игры у нас нет. Тонна работы, когда всё это и так есть на VCMI? Смысл? Для кого? API нужно профессионалам. Ту же VCMI используют небольшое количество народу, она в России популярна намного намного намного меньше, чем ЭРА.

(14.12.2020 03:33)Berserker Wrote: Завязывать же всю игровую структуру, а то и все структуры на конкретном разработчике нельзя.

Другого пути нет. Например, сейчас есть 2 плагина на новых монстров, ну и наверняка приходится не просто поддерживать совместимость с обоими, а потом и кровью, хотя реально нужен какой-то только 1 из них.

(14.12.2020 03:33)Berserker Wrote: Вероятно, разумным будет предложить библиотеку с методами получения/установки адресов и пределов для всех основных игровых структур.
ПолучитьМаксимальныйИДМонстра, ПолучитьЧислоМонстров, ПолучитьТаблицуМонстров. Установить первое, втрое и третье.

Думаю, что установленных 1000 бланковых монстров, артефактов, жилищ и т.д. моддерам хватит заглаза. Зачем лишние сложности? Памяти хватает на всё это, экономить-то зачем?

(14.12.2020 03:33)Berserker Wrote: Поскольку правильное расширение структур, на мой взгляд, должно иметь динамическую природу (монолитов 8, 50 или 100 зависит от содержимого json-конфигов), то и переносить подструктуры по методу Хероманта или Игрика не вариант.

Мой способ добавления новых героев - как раз динамический, т.к. Тифон пересобирает базовую структуру вместо переноса её частей. И значение количества будет вынесено в конфиг в будущих версиях ERA+.

(14.12.2020 03:33)Berserker Wrote: После переноса остаётся несколько вопросов:
-) Какой теперь новый адрес подструктуры?
-) Размер её элемента?
-) Количество элементов?

Систему базовых адресов, которую я предлагал несколько раз, которая используется в HD-моде для совместимости с HoA. Т.е. функции ничего никому не передают, а берут эти данные напрямую из кода SoD.

(14.12.2020 03:33)Berserker Wrote: Вопрос, схожий с обсуждением RedirectMemoryBlock/GetAddr и решаемый на уровне АПИ и соглашений, а не на уровне «никто не имеет права расширять ни одну структуру кроме автора мода ХХХ». Стоит ещё раз подумать, какого АПИ хватило бы всем.

Проблемы совместимости модов, расширяющие одинаковые структуры, - серьёзные проблемы. Подавляющее число моддеров не является профессиональными программистами, как реализовывать "соглашения", они не знают. Я уже обжегся с этим в Тифоне, сразу скажу, что это сложно реализовать, тем более во всех плагинах (очень много подводных камней).

(14.12.2020 03:33)Berserker Wrote: Для начала можно попробовать сделать 26 монолитов отдельным модом. Можно не вносить пока изменений в движок.

Лучше не надо. Тот патч, который я выложил, вызовет несместимость с ERA+. Одним несовместимым модом больше - я не хочу. Только если будет полная отвязка от базовой структуры (и сделать это в разы сложнее и геморойнее).

feanor · 14.12.2020 12:33

Фатальный недостаток json - отсутствие комментариев.
Я очень люблю этот формат, конечно, хоть и в плюсах он не так удобен, как в ЯП, хранящих метаинформацию, но все-таки этот факт сильно ограничивает его применимость именно для конфигов.

Я вообще считаю, что мы стали забывать ~~румынского диктатора~~ геройские тхт-таблицы.

Quote:То есть правильный плагин на новых монстров — это плагин, парсящий json из VCMI и предоставляющий API для получения адреса таблицы с монстрами, размера одной записи, максимального числа монстров, актуального числа монстров.

Эээ.. и как это будет осуществляться в реальности?
Ну т.е. для того, чтобы это апи использовать, нужно _знать_ о существовании такого плагина.
Причем ладно с монстрами, там хотелка давняя и предсказуемая, можно договориться, особенно если он в поставке будет (впрочем, мне не нравится эта идея).
А вот представьте себе плагин, который увеличивает число препятствий на поле боя?

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

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

Threaded Mode \| Linear Mode ERA III
Author	Message