http://zalil.ru/31565523
Включил снова модуль лодов, добавил обнуление их стартовых количеств по типам, два главных лода игры получают самый низкий приоритет загрузки, но не являются обязательными (на страх и риск), имёна приводятся к нижнему регистру в сортированном списке, а значит B.lod будет загружен после a.lod.
Нет. Все равно отсутствие видимой загрузки.
Если занопить загрузку cmpmusic.txt - дойдет до выбора карты, где и рухнет с вышеупомянутыми симптомами.
Berserker Wrote:Сав, грузить h3sprite/bitmap нужно первыми, чтобы остальные лоды имели больший приоритет и потому, что в воге есть места, где вещи ищутся именно в этих лодах.
Ну, я в плагине так и делаю (если они существуют). Или это к чему-то друому относится?
Berserker Wrote:Поправка, новые лоды не во все типы заносятся, wav нет. Не знаю, ошибка в коде или ещё какая-то причина.
Вроде как специально. По крайней мере в ассемблерном виде сделанные для этого приспособления выглядит слишком громозкими, чтобы быть ошибкой.
С dll из поста 215 такая фигня: если в Data есть H3bitmap.lod и/или H3sprite.lod, то игра будет ругаться на отсутствие различных ресурсов (каких - зависит от наличия других lod`ов). Если их оба переименовать и оставить в Data, всё работает.
P. S. Вроде как залил плагин на вогархив, слабо понял, куда и как ставить пометку, вставил в описание, в общем, сами отредактируете (там же премодерация?)
В общем, тестирую на версии dll без автоподгрузки lod`ов.
Так вот, второй красный - почему-то чёрный. Закономерность установить не удалось: с некоторыми цветами всё нормально, некоторые изменяются (по-разному).
По поводу автозаполнения имён в хотсите:
В H3 всегда можно было сохранить имя первого игрока (чтобы оно вставлялось автоматически). Для этого надо: Новая игра - Одиночная игра - Показать дополнительные опции - щёлкнуть по имени игрока рядом с флагом и изменить его. Изменённый вариант будет заменять "Player 1" или "Игрок 1".
Изменил таким образом имя на Sav. Автозаполнение после этого выдало: "Sav 1" и "Sav 2".
В справочнике:
Получить адрес машинной функции из библиотеки ↑
!!SN:[описатель загруженной библиотеки]/[название функции]/?[адрес функции];
Подразумевается !!SN:A же?
Выполнить машинную функцию ↑
!!SN:E[адрес функции]/[соглашение о вызове]/аргументы...
Пример:
!!SN:L^kernel32.dll^/?y1 Ay1/^lstrcpyA^/?y2;
Соглашение о вызове:
- 0 (PASCAL)
- 1 (CDECL или STDCALL)
- 2 (THISCALL)
- 3 (FASTCALL)
По умолчанию от функции ожидается целочисленный результат, который будет помещён в переменную v1. Если же функция возвращает вещественный результат, то к номеру соглашения нужно прибавить 4. Все системные библиотеки используют соглашение STDCALL.
Пример:
!!SN:L^kernel32.dll^/?y1;
!!SN:Ay1/^lstrcpyA^/?y2;
!!SN:Ey2/1/z1/z2; Скопировать содержимое z2 в z1. Аналог !!VRz1:Sz2;
Первый пример как-то не в тему.
Quote:Соглашение о вызове:
- 0 (PASCAL)
- 1 (CDECL или STDCALL)
Ну вот, а меня всё убеждают, что cdecl и stdcall - разные вещи.
разные, просто в Эре сделано вместе (зачем - Берс его знает
)
Quote:Ну вот, а меня всё убеждают, что cdecl и stdcall - разные вещи.
Они и есть разные. Эра запоминает указатель стёка до и восстанавливает после вызова.
Ну, в общем-то я и сам знаю, что это разные соглашения.
Но сколько ни компилировал, cdecl и stdcall в коде ведут себя взаимозаменяемо. Возможно, это особенность майкрософтского компилятора (в настройках по умолчанию или постоянно), возможно ещё что-то.
взаимозаменяемы только thiscall и stdcall, остальные все разные. наверно ты вызывал их из той же программы, поэтому ничего и не заметил.
Quote:взаимозаменяемы только thiscall и stdcall
только в одном направлении же: вызов stdcall'ой функции как thiscall'овской запишет ненужный this в ecx, а наоборот - не передаст уже нужный this в ecx.
Аналогично, можно thiscall'овскую функцию можно вызывать как fastcall'овскую, ручками передав this и зaписав фигню во второй параметр, но не наоборот.
Если пишу фигню - скажите, я, походу, траванулся
Ошибка оказалось гораздо банальнее - в числовой переменной.