Исправил (вроде бы) проблему лодов, ужесточил контроль над двумя основными, добавил правильную их регистрацию (h3bitmap и h3sprite.lod имеют конкретные типы, так что нечего их дёргать по каждому файлу). Проверил у себя - больше ошибка ненайденных файлов не появляется.
Исправил ошибку, указанную Савом, с цветным текстом.
http://zalil.ru/31568900
А со звуковыми файлами в lod`ах всё-таки не вышло?
С новой dll не запускается, если есть какие-либо lod`ы, кроме H3bitmap.lod и H3sprite.lod. Если только они - всё нормально.
С цветами стало нормально.
Там своя таблица по ходу, и не лодов, а snd. Индексы назначить можно, но будет страшно ругаться постоянно, ибо реально только один snd загружен - Heroes3.snd.
http://zalil.ru/31569012
Хм, задумал переделать некоторых существ из польской Рощи.
Если я весь установочный пакет Рощи переделаю и создам H3GroveO.lod (O - Original), а потом переделанных существ упакую в H3GroveM.lod (M - my). То какие файлы будут читаться из этих лодов и в каком порядке, а какие не будут читаться вообще (например, скрипты), чтобы их туда и не ложить? Нужно создавать не H3GroveM.lod, а H3GroveR.lod, чтобы грузился сначала H3GroveO.lod, а потом мой лод, если следовать алфавиту?
Скрипты будут грузиться из Data\s по-любому. Имена лодов будут приведены в нижний регистр и загружены в алфавитном порядке. Поэтому рекомендую:
Groove.lod, GrooveExt.lod или что-то в этом духе. Ну и любой новый лод имеет приоритет перед стандартными.
etoprostoya Wrote:То какие файлы будут читаться из этих лодов и в каком порядке, а какие не будут читаться вообще (например, скрипты), чтобы их туда и не ложить?
Будут читаться все файлы, которые по-умолчанию присутствуют в H3bitmap.lod и H3sprite.lod. Т. е. : fnt, h3c, ifr, pal, pcx, txt, xmi, def, msg, msk.
etoprostoya Wrote:Нужно создавать не H3GroveM.lod, а H3GroveR.lod, чтобы грузился сначала H3GroveO.lod, а потом мой лод, если следовать алфавиту?
Я бы в подобной ситуации назвал lod`ы 0H3GroveO.lod и 1H3GroveM.lod.
Кстати, Берс, а ты убрал подгрузку H3wog.lod и H3custom.lod? А то двойная их подрузка может привести к багам.
Quote:Кстати, Берс, а ты убрал подгрузку H3wog.lod и H3custom.lod? А то двойная их подрузка может привести к багам.
Конечно. Попробуй последнюю ссылку.
Quote:Скрипты будут грузиться из Data\s по-любому.
Поскольку лоды начинают грузиться раньше скриптов (я так полагаю, могу и ошибаться), то можно ведь сделать так, чтобы и скрипты грузились из лодов? Насколько трудно будет сделать такое? Ведь так можно было бы для модмейкеров во многих случаях обойтись распространением одного лишь лода, а не вог-файла, который заменяет уже имеющиеся скрипты. А так, удалил или сменил расширение того же Grove.lod и продолжай себе играть в оригинальный вог-эру с Крепостью, а потом опять сменил расширение на lod и играй в Рощу.
(17.08.2011 22:07)Sav Wrote: [ -> ]etoprostoya Wrote:То какие файлы будут читаться из этих лодов и в каком порядке, а какие не будут читаться вообще (например, скрипты), чтобы их туда и не ложить?
Будут читаться все файлы, которые по-умолчанию присутствуют в H3bitmap.lod и H3sprite.lod. Т. е. : fnt, h3c, ifr, pal, pcx, txt, xmi, def, msg, msk.
Расширить этот список на ert и erm, например, будет сложно?
Не выйдет. Например, сейчас пишу прогу для установки новых объектов в z[e]objects.txt. Решили с Валерием, что только в дате место подобным текстовикам. snd тоже никто не расширил (если Саву интересно, дам наводку). Поэтому всё ещё есть вещи, которые устанавливаются не простым копированием. Если я не ошибаюсь, скрипты можно хранить в лоде, но те, что в файлах, пока имеют приоритет.
Berserker Wrote:Конечно. Попробуй последнюю ссылку.
Да, увидел. Только если в Data есть lod`ы кроме основных - вылет по адресу 61846Eh. Кстати, интересное замечание: я посмотрел, длины всех 4-х таблиц звукового типа в этот момент равны нулю. Ты случайно не обнуляешь их там?
Berserker Wrote:если Саву интересно, дам наводку
Интересно.
(17.08.2011 19:13)feanor Wrote: [ -> ]только в одном направлении же: вызов stdcall'ой функции как thiscall'овской запишет ненужный this в ecx, а наоборот - не передаст уже нужный this в ecx.
Аналогично, можно thiscall'овскую функцию можно вызывать как fastcall'овскую, ручками передав this и зaписав фигню во второй параметр, но не наоборот.
что-то я запутался окончательно
Berserker Wrote:Обнулял. Сейчас скомпилирую без обнуления.
То же самое, только нулю они не равны. Значит дело не в этом.
Единственное место, где идёт поиск snd-архивов, это:
{0x55C438+3,DS(&LodTypes::Table[0][2]),4}.
Адрес уже перенаправлен на ЗВС-ову таблицу типов архивов. А вот ниже по коду поиск индексов лодов идёт не в таблице лодов, а в своей. Туда же грузятся и snd-файлы, опять-таки в статическую область. Поставь хук на чтение heroes3.snd, найдёшь. Очевидно, нужно проделать ту же операцию, что и с оригинальной таблицей: расширить и поменять ссылки + вызвать загрузку snd-файлов. Что-то помнится, что там вручную файл считывался, но не уверен.
Sav, можешь скачать hfs и расшарить свою папку с игрой?
Насчёт snd спасибо, попробую.
Berserker Wrote:Sav, можешь скачать hfs и расшарить свою папку с игрой?
Да, сейчас.