Репутация: 229 
(весьма и весьма положительная личность)
Изучение и моддинг Prince of Persia: Revelations/Rival Swords (WW/T2T)
Данная тема посвящена изучению ресурсов и небольшому моддингу для игр Prince of Persia: Revelations/Rival Swords (Warrior Within/The Two Thrones).
Прежде всего, хотелось бы поблагодарить тех, кто сделал этот моддинг возможным:
ErikPshat - за реверсинг, помощь и модифицированную версию Persian Rug с разблокированными скрытыми фичами.
riku.kh3 - за реверсинг, помощь и полезную утилиту, которая упаковывает ресурсы обратно в .bin
Turfster - автора Persian Rug.
Re-Education - за появление в нужном месте и в нужное время
Итак, начнём
Мод 1 - отключение эффекта свечения при попадании по песочным монстрам в Prince of Persia: Rival Swords/The Two Thrones
Достаточно простой мод, его суть заключается в замене текстур, отвечающими за эффекты на прозрачные. Побочные эффекты - свечение кинжала при QTE и эффект свечения при превращения в тёмного принца тоже отключаются.
Текстуры, отвечающие за это находятся в Prince_Weapons_wow_ff05c7fe.bin
- Prince_Weapons_wow_ff05c7fe_130071D1
- Prince_Weapons_wow_ff05c7fe_1300278D
Достаём их оттуда через Persian Rug -> Bin анализатор -> Извлечь данные.
Структура текстур для PSP - первые 144 байта, и последние 4 байта в конце файла - служебная информация, её не трогаем. С помощью hex-редактора заменяем код текстуры 0x65 байтами для Prince_Weapons_wow_ff05c7fe_130071D1 и 0x00 байтами для Prince_Weapons_wow_ff05c7fe_1300278D.
Структура текстур для PS2 - первые 192 байта, и последние 36 байт в конце файла - служебная информация, её не трогаем. С помощью hex-редактора заменяем код текстуры 0x65 байтами для Prince_Weapons_wow_ff05c7fe_130071D1 и 0x00 байтами для Prince_Weapons_wow_ff05c7fe_1300278D.
Структура текстур для PS3 - первые 68 байт - служебная информация, её не трогаем. С помощью hex-редактора заменяем код текстуры 0x00 байтами.
Структура текстур для GC - первые 76 байт - служебная информация, её не трогаем. С помощью hex-редактора заменяем код текстуры 0x30 байтами. Отдельно ещё хочется упомянуть, что структура образа нестандартная, и придётся доставать бинарник вручную. В моём случае он занимает 188412 байт, и лежит в области 766767600-766956012 (US версия, GKME41).
Структура текстур для Xbox - первые 68 байт - служебная информация, её не трогаем. С помощью hex-редактора заменяем код текстуры 0xFFFFFF00 байтами для Prince_Weapons_wow_ff05c7fe_130071D1 и 0x00 байтами для Prince_Weapons_wow_ff05c7fe_1300278D.
Структура текстур для PC - первые 68 байт - служебная информация, её не трогаем. С помощью hex-редактора заменяем код текстуры 0xFFFFFF00 байтами для Prince_Weapons_wow_ff05c7fe_130071D1 и 0x00 байтами для Prince_Weapons_wow_ff05c7fe_1300278D.
Мод 2 - модифицирование оружия в Prince of Persia: Revelations/Warrior Within
Учитывая, что ранее у меня уже были некоторые заготовки по оружию в виде редактора сэйвов для Revelations/Rival Swords (вот ссылка, если интересует) я решил копнуть это дело глубже. В данном случае - all_weapons_wow_ff0610da.bin, советую распаковать его полностью.
Прежде, чем приступить к разбору конкретных файлов, отвечающих за оружия и их свойства ознакомьтесь со следующим списком:
В списке все коды оружия написаны как есть, когда я писал редактор сэйвов - в обратном порядке, как они отображаются в сэйвах и ресурсах игры, т.е. 41E6 0033 в памяти и названии файлов будет отображаться как 3300 E641. Головную боль ещё добавляет момент, что у разных категорий оружия файлы, отвечающие за их параметры тоже с разным размером, что усложняет разбор их структуры. Поэтому для начала я возьму наиболее похожие по параметрам оружия для изучения.
Этап 1 - перенос специального эффекта с одного оружия на другое
Для этих целей нам подойдут "секретные оружия" - мишка [3EE6 0033] secret (Teddy Bear) и фламинго [42E6 0033] secret (Pink Flamingo). У мишки есть специальный эффект вампиризма, который лечит принца за удары по монстрам, вот мы его и перенесём на фламинго.
Отвечающие за это файлы объектов:
- all_weapons_wow_ff0610da_3300E63E
- all_weapons_wow_ff0610da_3300E642
Сравниваем содержание файлов (например, с пом. Total Commander)
Итак, в начале идёт блок с ID нашего оружия (выделен синим), далее идут указатели:
- 0xF4E50033 и 0xF8E50033 отвечают за 3D модель оружия (выделены серым)
- 0x17E50033 и 0x18E50033 отвечают за ссылку на текстуру оружия (выделены оранжевым)
- 0xC5E60033 и 0xC7E6033 отвечают за ссылку на файл с параметрами оружия (выделены красным), чтобы лишний раз не открывать файл-ссылку уменьшаем значение на 1, т.е. наши файлы с параметрами - all_weapons_wow_ff0610da_3300E6C4 и all_weapons_wow_ff0610da_3300E6C6.
- значение указателя, выделенного чёрным цветом я пока что не знаю.
***Можно заменить все 4 указателя с одного оружия на другое, и в этом случае оно станет аналогом "донора". Заменять указатели частично нельзя, игра не загрузится.***
Теперь, идём сравнивать файлы, отвечающие за свойства оружия:
Опять мы видим вначале блок, теперь он отвечает за ID параметров оружия (выделен синим), далее идёт ID оружия (выделен серым) и наш искомый блок, который отвечает за специальный эффект (выделен красным). Заменяем в файле параметров фламинго 0x01 на 0x03 и получаем фламинго с эффектом вампиризма.
Этап 2 - перенос эффекта неразрушимости (для оружия со специальным эффектом)
Возьмём для этих целей топоры [7BE5 0033] axe (Bahram) и [92E5 0033] axe (Spentas). Первый имеет специальный эффект повышенного урона, но быстро ломается, а второй неразрушимый, но в добавку имеет негативный эффект высасывания здоровья при ударе по монстрам. Файлы, отвечающие за параметры этих топоров:
- all_weapons_wow_ff0610da_3300E59B
- all_weapons_wow_ff0610da_3300E5AF
И смотрим их содержимое:
Нас интересует блок 0x3C9D955B - это специальное значение, которое отвечает за то, что оружие неразрушимо (выделен красным) и блок, 0x00, который отвечает за то, сколько урона получит оружие за каждый удар по монстру (выделен синим). Заменять надо оба, в противном случае оружие будет ломаться.
Этап 3 - перенос эффекта неразрушимости и специального эффекта на обычное оружие (WIP)
Усложняем задачу, и пробуем замоддить обычное оружие. В данном случае я взял [46E6 0033] mace (Vata) и [33E6 0033] sword (Shadee's Sword). В первом случае обычная булава, во втором - неразрушимый меч с негативным специальным эффектом высасывания здоровья при ударе по монстрам. Файлы, отвечающие за параметры для этого оружия:
- all_weapons_wow_ff0610da_3300E657
- all_weapons_wow_ff0610da_3300E6D9
Результаты первого и грубого сравнения:
Блок со специальным значением 0xCFB67969 отвечает за то, что на оружии есть специальный эффект (выделен синим). Далее идёт блок со специальным значением 0x3C9D955B, отвечающим за то, что на оружии есть эффект неразрушимости (выделен красным). Выяснилось, что за специальный эффект отвечает блок в 4 байта - 0x04000000 (выделен серым). Ну и блок 0x00, который активирует неразрушимый эффект (выделен чёрным).
Вроде всё работает, но если приглядеться к блокам в области 184-216, то можно заметить, что блок 0x9A3B0771 присутствует в другом оружии, но он чуть смещен. Как показала практика, блок 0xCFB67969 должен находиться на строго заданной позиции, в противном случае специальный эффект не будет работать. Попробовал подогнать расположение блоков, и методом тыка определил, что следует выбросить блок 0x070A54D6:
Сравнение после подгонки:
Этап 4 - перенос модели и текстуры c одного оружия на другое
Возвращаемся к объектам мишки и фламинго, а конкретнее к указателям на 3d модель оружия - блокам 0xF4E50033 и 0xF8E5033, в данном случае это файлы:
- all_weapons_wow_ff0610da_3300E5F4
- all_weapons_wow_ff0610da_3300E5F8
Открываем и сравниваем:
Первый блок отвечает за [(размер файла) - 12 байт] (выделен синим), далее идёт блок с ID 3d модели оружия (выделен серым). Всё, что после уже отвечает за модель оружия, это мы и будем переносить. Учитывая, что файл с моделью мишки занимает больше фламинго, мы будем переносить модель фламинго на мишку. Разницу в 452 байта заполняем нулями в конце файла.
Проверяем результат (слева то, что получилось, справа оригинал):
Модель мы заменили, а вот текстура осталась старая. Как оказалось, на файл с текстурой ведёт указатель на файл с ссылкой в блоках 0x17E50033 и 0x18E50033 (скриншот сравнения объектов оружия в первом этапе обновлён). Файлы, отвечающие за эти ссылки:
- all_weapons_wow_ff0610da_3300E517
- all_weapons_wow_ff0610da_3300E518
Смотрим, куда же ведут ссылки:
В конце файлов находятся искомые блоки 0x6CE40033 и 0x6DE40033, нам туда. Открываем соответствующие файлы:
- all_weapons_wow_ff0610da_3300E46C
- all_weapons_wow_ff0610da_3300E46D
Смотрим, что у нас внутри:
Вот и наконец-то добрались до текстуры. В первом блоке дважды дублируется ID текстуры (выделен серым), далее идёт блок, отвечающий за правильное наложение текстуры на модель (выделен красным). На 144-м байте начинается текстура, размером 8192 байта. Последние 4 байта в конце файла - служебная информация. Сначала надо заменить блок с параметрами, иначе текстура будет наложена неправильно, идём туда:
Первые 16 байт - размер файла, header magic и ID файла. Их не трогаем, а заменяем всё, что идёт дальше. Далее заменяем содержимое текстуры и проверяем результат (слева то, что получилось, справа оригинал):
архив
Текстура заменилась, но цвет оружия какой-то странный. На данный момент известно, что корни проблемы растут где-то в районе ссылки на текстуру, если в ней заменить ID на текстуру оригинального оружия (0x6CE40033 на 0x6DE40033) то проблема с цветом пропадает.
Первые попытки перенести 3d модель топора из Rival Swords (The Two Thrones) в Revelations (Warrior Within):
Перенести топор оказалось непросто, т.к. у него очень большой размер модели - 3970 байт. По размеру модели подошёл
[31E6 0033] sword (Kaileena's Sword), но у него файл текстуры 4244 байта, а у топора 8340. Пришлось пойти на хитрость, и в ссылке на текстуру заменить ID на текстуру от мишки. Забавно, но после этого топор тоже стал "цветным". Текстуру одного оружия пришлось забить нулями, т.к. итоговый размер стал больше, чем исходный .bin файл
Попробовал использовать ID текстуры фламинго и топор стал розовым
Пробуем ID текстуры от меча Kerena:
Это уже ближе к желаемому результату. Начинают закрадываться подозрения, что где-то ещё есть текстуры поверхности, которые рисуются при определённом ID текстуры.
Rival Swords (The Two Thrones) тоже удалось замоддить:
Попробовал перенести оружие из GameCube версии Warrior Within на The Two Thrones, но увы, текстура из WW ни в какую не хочет нормально вставать на T2T - оружие отображается прозрачным с белой рябью. Видимо, формат текстур изменили.
PS2 версия The Two Thrones пропатчилась нормально:
Сделал небольшое видео и добавил его в заголовок 4-го этапа
Изучение структуры файлов монстров в Prince of Persia: Revelations/Warrior Within (WIP)
После небольшого опыта с моддингом оружия мне захотелось посмотреть, как устроена структуру файлов у монстров. Для начала наведём справки, какой .bin файл за какого монстра отвечает (для этого я посмотрел текстуры PC версии)
Вытягиваем оттуда основной файл-объект:
- ACT_Enemy_Disciple_wow_ff033775_3207CC33 (ACT_Enemies_Disciple.gao)
- ACT_Enemy_Initiate_wow_ff033811_3207CC9B (ACT_Enemies_Initiate.gao)
Теперь посмотрим, чем отличаются файлы:
Итого у нас имеется 6 блоков для рассмотрения:
- 0x07380113 и 0x6CBA0031 отвечают за таблицу, в которой содержится количество объектов "скелета" модели монстра (голова, руки, ноги, и т.д...) (выделены фиолетовым):
Внутри мы видим блок, который отвечает за общее количество объектов "скелета" модели монстра (выделены синим), далее идёт индекс объекта (выделены красным), и какие-то параметры\данные (выделены серым).
- 0xC402001F и 0x66BA0031 отвечают за ссылку на 0xC502001F и 0x67BA0031, таблица, которая содержит ID объектов "скелета" модели монстра (выделены синим):
Объекты в таблице идут в строго-определённом порядке:
4CBA0031 - 3100BA4C >B_Disciple_Yezidi.gao
4DBA0031 - 3100BA4D >B_Disciple_Yezidi Pelvis.gao
4EBA0031 - 3100BA4E >B_Disciple_Yezidi Spine.gao
4FBA0031 - 3100BA4F >B_Disciple_Yezidi Spine1.gao
50BA0031 - 3100BA50 >B_Disciple_Yezidi Neck.gao
51BA0031 - 3100BA51 >B_Disciple_Yezidi Head.gao
53BA0031 - 3100BA53 >B_Disciple_Yezidi L Clavicle.gao
54BA0031 - 3100BA54 >B_Disciple_Yezidi L UpperArm.gao
55BA0031 - 3100BA55 >B_Disciple_Yezidi L Forearm.gao
56BA0031 - 3100BA56 >B_Disciple_Yezidi L Hand.gao
57BA0031 - 3100BA57 >B_Disciple_Yezidi R Clavicle.gao
58BA0031 - 3100BA58 >B_Disciple_Yezidi R UpperArm.gao
59BA0031 - 3100BA59 >B_Disciple_Yezidi R Forearm.gao
5ABA0031 - 3100BA5A >B_Disciple_Yezidi R Hand.gao
5CBA0031 - 3100BA5C >B_Disciple_Yezidi L Thigh.gao
5DBA0031 - 3100BA5D >B_Disciple_Yezidi L Calf.gao
5EBA0031 - 3100BA5E >B_Disciple_Yezidi L Foot.gao
5FBA0031 - 3100BA5F >B_Disciple_Yezidi L Toe0.gao
60BA0031 - 3100BA60 >B_Disciple_Yezidi R Thigh.gao
61BA0031 - 3100BA61 >B_Disciple_Yezidi R Calf.gao
62BA0031 - 3100BA62 >B_Disciple_Yezidi R Foot.gao
63BA0031 - 3100BA63 >B_Disciple_Yezidi R Toe0.gao
5BBA0031 - 3100BA5B >B_Prince_Sword02.gao
28560130 - 30015628 >B_MOD_B_Loincloth_Root.gao
64BA0031 - 3100BA64 >B_MOD_B_Loincloth.gao
27560130 - 30015627 >B_MOD_F_Loincloth_Root.gao
65BA0031 - 3100BA65 >B_MOD_F_Loincloth.gao
26560130 - 30015626 >B_MOD_Head_Flap_Root.gao
52BA0031 - 3100BA52 >B_MOD_Head_Flap.gao
- 0x39СС0732 и 0xA8760113 отвечают за огромную таблицу с ссылками на данные (около 190 ссылок), назначение неизвестно (выделены чёрным). В большинстве случаев данные полностью совпадают, или различаются на несколько байт.
- 0x35CC0732 и 0x98CC0732 отвечают за две ссылки - одинаковый для обоих монстров файл с данными (таблица?) 0x10CC0732, а также 0x34CC0732 и 0x97CC0732, которые отвечают за свойства монстров (выделены красным).
Структура напоминает файл с параметрами меча. Блок 0xFE340113 и 0xFD340113 отвечают за объекты ACT_Enemies_Disciple_Death.gao и ACT_Enemies_Initiate_Death.gao (выделены синим). Блок 0xB3400113 отвечает за объект ACT_SFX_Weapon_Slash.gao (выделен красным). Блок 0xF0720113 отвечает за объект ACT_Enemies_Death_FX.gao (выделен серым). Блок 0x51330113 отвечает за объект ACT_Weapon_Feet.gao (выделен оранжевым). Блоки выделенные фиолетовым предположительно отвечают за AI монстра. На такие мысли меня наводят дебаг сообщения в конце файлов:
AI_strings
ACT_Enemy_Disciple_wow_ff033775_3207CC1A
DISCIPLE:: Unknown Slice Method To Used
ACT_Enemy_Disciple_wow_ff033775_3207CC1C
AI Error: Actor is NOT online
AI Error: Not Done
DISCIPLE:: C_State_Disciple_Move_GoTo ; No Spot to go to
DISCIPLE:: PathFinding {ObstructionLaterOn} - Check if it's worth the trouble to reposition ourselve base on the new path
ACT_Enemy_Disciple_wow_ff033775_3207CC1D
DISCIPLE:: Cinematic is NO Longer Playing
DISCIPLE:: Cinematic InGame Playing
DISCIPLE:: Cinematic InGame Playing
DISCIPLE:: Cinematic Interruption
DISCIPLE:: Cinematic InGame Playing
ACT_Enemy_Disciple_wow_ff033775_3207CC19
AI Error: Not Done
- 0x31CC0732 и 0x99CC0732 отвечают за ссылку на 0x4C230032, одинаковый файл для обоих монстров (выделены чёрным). Назначение неизвестно.
- 0x32CC0732 и 0x9ACC0732 отвечают за ссылку на 0x4E230032, одинаковый файл для обоих монстров (выделены чёрным). Назначение неизвестно.
Не найдя модель и текстуру я решил искать в обратном направлении - зная код текстуры я нашёл второй объект, который отвечает за "тушку" монстра:
- ACT_Enemy_Disciple_wow_ff033775_1F0002C1 (M_Disciple_Body.gao)
- ACT_Enemy_Initiate_wow_ff033811_3100BA4B (M_Initie.gao)
Открываем и сравниваем:
- 0x7F02001F и 0x24BA0031 отвечают за 3d модель монстра (выделены синим).
- 0xEB02001F и 0x1C570130 содержит 7 ссылок, первые 6 из них ведут на основную текстуру, и ещё одна ведёт на одинаковую текстуру для обоих монстров, предположительно отвечающую за эффекты крови (выделены красным). Открываем 0xEF02001F и 0x15570130, достаём оттуда основную текстуру - 0x8703001F и 0x9BB90031.
Далее идёт похожая таблица с объектами "скелета" модели монстра:
Как и в прошлый раз объекты расположены в строгом порядке:
18000000
4DBA0031 - 3100BA4D >B_Disciple_Yezidi Pelvis.gao
01000000
4EBA0031 - 3100BA4E >B_Disciple_Yezidi Spine.gao
02000000
4FBA0031 - 3100BA4F >B_Disciple_Yezidi Spine1.gao
03000000
50BA0031 - 3100BA50 >B_Disciple_Yezidi Neck.gao
04000000
51BA0031 - 3100BA51 >B_Disciple_Yezidi Head.gao
05000000
53BA0031 - 3100BA53 >B_Disciple_Yezidi L Clavicle.gao
06000000
54BA0031 - 3100BA54 >B_Disciple_Yezidi L UpperArm.gao
07000000
55BA0031 - 3100BA55 >B_Disciple_Yezidi L Forearm.gao
08000000
56BA0031 - 3100BA56 >B_Disciple_Yezidi L Hand.gao
09000000
57BA0031 - 3100BA57 >B_Disciple_Yezidi R Clavicle.gao
0A000000
58BA0031 - 3100BA58 >B_Disciple_Yezidi R UpperArm.gao
0B000000
59BA0031 - 3100BA59 >B_Disciple_Yezidi R Forearm.gao
0C000000
5ABA0031 - 3100BA5A >B_Disciple_Yezidi R Hand.gao
0D000000
5CBA0031 - 3100BA5C >B_Disciple_Yezidi L Thigh.gao
0E000000
5DBA0031 - 3100BA5D >B_Disciple_Yezidi L Calf.gao
0F000000
5EBA0031 - 3100BA5E >B_Disciple_Yezidi L Foot.gao
10000000
5FBA0031 - 3100BA5F >B_Disciple_Yezidi L Toe0.gao
11000000
60BA0031 - 3100BA60 >B_Disciple_Yezidi R Thigh.gao
12000000
61BA0031 - 3100BA61 >B_Disciple_Yezidi R Calf.gao
13000000
62BA0031 - 3100BA62 >B_Disciple_Yezidi R Foot.gao
14000000
63BA0031 - 3100BA63 >B_Disciple_Yezidi R Toe0.gao
15000000
64BA0031 - 3100BA64 >B_MOD_B_Loincloth.gao
18000000
65BA0031 - 3100BA65 >B_MOD_B_Loincloth_Root.gao
1A000000
52BA0031 - 3100BA52 >B_MOD_Head_Flap.gao
1C000000
FFFFFFFF
И последняя таблица, которая отвечает за объекты со спец. эффектами (кровь при попадании, дезинтеграция монстра после сметри, и т.д..)
Для обоих монстров таблица одинаковая (байты были перевёрнуты обратно для удобства поиска объектов через Persian Rug).
Мои первые попытки перенести модель и текстуру монстра Initiate (Executor) на Disciple (Raider) напоминают историю с мишкой и зелёным топором (слева то, что получилось, справа оригинал):
Upd: разобрался с текстурой, оказалось что я проворонил блок с параметрами, который отвечает за правильное наложение текстуры. Обновил скриншот в этапе переноса модели с текстурой оружия, и добавил описание. Также обновил описание блоков с объектами - это оказались объекты "скелета" модели монстра, последние сомнения по поводу их назначения развеяли попытки перенести модель монстра из Rival Swords (The Two Thrones) в Revelations (Warrior Within) и наоборот:
Мод 3 - модифицирование монстров в Prince of Persia: Revelations/Warrior Within (WIP)
Продолжение следует...
Буду наполнять тему по мере нахождения новой инфы
Последний раз редактировалось ErikPshat; 12.08.2024 в 22:27.
Репутация: 229 
(весьма и весьма положительная личность)
SILENT-Pavel, я надеюсь, что в данном случае ресурсы других версий Prince of Persia: Warrior Within (Revelations) и Prince of Persia: The Two Thrones (Rival Swords) должны быть похожи, что даст возможность моддить их тоже PSP версию я взял из-за удобства, т.к. есть возможность редактировать сэйвы и быстро проверить необходимое оружие
Последний раз редактировалось BlackDaemon; 13.08.2015 в 02:33.
Репутация: 229 
(весьма и весьма положительная личность)
Такс, пришло время для релиза обновленного редактора сэйвов Исходники выложу немного позже, т.к. их надо немного привести в надлежащий вид.
Новое в редакторе сэйвов для Warrior Within/Revelations:
- поддерживает сэйвы от версий PSP, PC и PS2 (частично, экспериментальная поддержка);
- изменение локации (включая сэйвпоинты, чекпоинты и сторигейты; также дополнительные уровни для PSP версии);
- изменение сюжетной линии.
Новое в редакторе сэйвов для The Two Thrones/Rival Swords:
- поддерживает сэйвы от версий PSP, PC и PS2 (частично, экспериментальная поддержка);
- изменение локации (включая сэйвпоинты и чекпоинты; также дополнительные уровни для PSP версии, в т.ч. скрытые тестовые/незавершённые уровни).
Возможности Timeline Patcher:
- отключение защиты проверки целостности сэйвов, PC (для исполняемого файла без защиты и сжатия);
- частичное отключение защиты проверки целостности сэйвов, PS2;
- изменение локации при запуске "New Game", PC (GOG версия WW - для исполняемого файла без сжатия, 5,533,696 bytes и для T2T NoCD от Reloaded);
- изменение локации при запуске "New Game", Xbox (бета-версия T2T, для возможности полностью "разблокировать" игру).
Для РС версии T2T также можно воспользоваться патчем от RhymeKidder, в нём включена расчлелёнка, добавлена поддержка 16:9 разрешений а также убрана проверка целостности сэйвов (см. вложение, перезалил оригинальные архивы).
пароль
LegendsWorld
Последний раз редактировалось BlackDaemon; 10.05.2018 в 19:09.
Причина: обновил ссылки :P
Репутация: 229 
(весьма и весьма положительная личность)
Глянул я на днях инфу по BF контейнеру и решил попробовать накалякать свой распаковщик/упаковщик. Увы, но желаемого результата достичь не получилось, тем не менее небольшой эффект такая замена дала. Засунул в РС версию T2T all_weapons_wow_ff0610da.bin (предпоследний файл в контейнере) большего размера (на 30720 байт), чем оригинальный, пропатчил в заголовке оффсеты по размеру и позиции. Частично игра даже стала загружаться, но часть данных при этом побилась (вылеты с определённым оружием при попытке загрузить сейв), т.е. нужно ещё что-то менять в этом шайтан-формате Выкладываю тулзу "как есть", на случай, если кто-то заинтересуется в её доработке
Последний раз редактировалось BlackDaemon; 12.05.2018 в 12:07.
Репутация: 229 
(весьма и весьма положительная личность)
В списке подозреваемых:
- таблица с позициями файлов вначале заголовка
- таблица с размером и названием файлов
- подозрительный файл size.grs, который в самом конце BF файла
Для удобства немного выровнял первую таблицу, наблюдается некоторая "шаблонность" значений
Upd:
Хорошая новость - "неизвестный блок" в первой таблице разгадан. Плохая - просматривается явная зависимость от блока с позицией файла
Upd2:
Можно откидывать неизвестный блок во второй таблице, пробовал обнулять значения, в том числе затирать названия файлов - на работоспособность игры это не влияет
Обнаружил связь "неизвестного блока" из первой таблицы с size.grs
На скорую руку написал парсер size.grs и сделал сортировку по блоку с хэшем
Upd3:
Пролистывая список с крупными файлами заметил некоторое сходство "неизвестного блока" в size.grs с размером .bin файлов, но во всех случаях значение в нём меньше, чем размер файла...почему?
Upd4:
Разобрался с "неизвестным блоком" в size.grs - это размер данных внутри файла, без учёта нулей в конце.
Последний раз редактировалось BlackDaemon; 17.05.2018 в 05:27.
Репутация: 229 
(весьма и весьма положительная личность)
Начал изучать запакованные файлы внутри BF. Вооружившись кодом PofP.bin.repacker отdodther и обнаружил, что на файлах локаций код падает на аномальных блоках. Сравнивая распакованный файл через PersianRug обнаружилось следующее (на примере 310_Depths_wow_ff0e1efa.bin)
так выглядят обычные блоки (размер распакованного блока, размер запакованного блока, его данные)
а вот так выглядят аномальные
Когда PersianRug находит такой блок (распакованный размер и размер запакованного блока одинаковые) - считывает следующие 2 байта, отнимает оттуда 17 байт, и копирует оставшиеся (в данном случае 253 - 17 = 236 байт) данных, остальное содержимое блока выкидывается. Разумеется, в таком запакованном файле обратно этого блока нет, что ставит крест на моддинге файлов локаций.
3,080,188 байт - оригинал
4,240,047 байт - распакованный
2,949,116 байт - запакованный обратно (с пом. psp_comp от RikuKH3)
Upd:
Залил примеры блоков во вложения.
Последний раз редактировалось BlackDaemon; 22.05.2018 в 17:16.
Репутация: 229 
(весьма и весьма положительная личность)
Сегодня это наконец-то свершилось! После замены на all_weapons_wow_ff0610da.bin большего размера игра завелась как надо, без вылетов
Залил новый билд утилиты, проблема с правильной распаковкой файлов локаций пока что не решена.
Upd:
Есть подозрение, что в этих аномальных блоках какая-то специфическая "plain data", пробовал эти блоки прогонять через lzo1x - на выходе выходит размер больше оригинального блока Немного обновил в этом плане код, добавил пару проверок и копирование блока в его оригинальном виде туда и обратно.
По каким-то причинам 620_Courtyard_GFX_wow_ff0f3fd4.bin и 740_Well_TopWell_2_wow_ff0c1183.bin сжимаются сильнее оригинальных, хотя расжатые данные побайтно совпадают. Утилита RikuKH3 сжимает аналогично.
Последний раз редактировалось BlackDaemon; 23.05.2018 в 14:23.
Причина: пофиксил найденный в утилите баг
Репутация: 229 
(весьма и весьма положительная личность)
Yoti, да, md5 сжатых обратно файлов (моей утилитой и утилитой RikuKH3) совпадают. Самое забавное в этой ситуации то, что у сжатых файлов обратно данные в последнем блоке вписываются байт-в-байт (+4 байта зарезервировано для размера файла), потому отпадает необходимость выравнивать/забивать следующий блок до 2048 байт нулями.
Репутация: 229 
(весьма и весьма положительная личность)
Первые наброски по .bin формату
Функционал пока что очень примитивный, и утилита по-большей части годится в качестве вспомогательной для изучения формата.
-чтение .bin файла в (сжатом виде и без сжатия);
-распаковка содержимого .bin на отдельные файлы;
-обратная сборка распакованных файлов в .bin (примитивное копирование);
-чтение и распаковка текстур (PC версия);
-частичная запаковка текстур обратно (PC версия, кроме формата 8bit + палитра);
-поиск на наличие ID других файлов, и ID текущего файла в других.
-внешний файл (override.txt) для добавления доп. описания, и при необходимости, типа файла.
Из очевидных вещей пока в todo-списке задача разобраться с конвертацией текстур обратно в формат 8bit + палитра, что из себя представляет формат 3D-объектов, каким образом PersianRug с ним работает, и разобраться с этим.
Последний раз редактировалось BlackDaemon; 29.05.2018 в 08:12.
Репутация: 229 
(весьма и весьма положительная личность)
Пообщался я немного с автором IrisTool (утилиты для просмотра ресурсов Beyond Good and Evil), он дал пищу для размышлений:
Parsing bin files are a very complex task. You can only parse those files correctly, if you read exactly the same as game does. Every chunk in bin files have a key, but game simply not uses them, because of binarized format. I can tell, how BGE works, but I have no idea, if it is true for POP games. (I believe, more or less true). Every map related bin file (ff00xxxx.bin, POP games have more meaningful filename, eg map name) starts with world list keys. (You can find same in the wol file with same name as bin). After game collected world keys, it starts read the first world chunk (starts with .wow chars). It can contain more keys, game stores them for further read. After first wow read, it reads second, then third, then etc. After last wow chunk it will read, the first key, what found in first wow chunk. You can not detect, what is the next chunk type, and how should be read (eg ints, bytes, structs, etc), if you are not following game logic. You have to reverse engineer every chunk type, if you want to parse bin files from the beginning to end. There are differences BGE and POP games, BGE only load only one bin file at a time, and loads another one on level change, POP games load several bin files same time. BGE stores textures in separate bin files (ff80xxxx.bin), every POP ff00xxxx bin file contain map data (geometry, bones, scripts, etc) and the second part of the a file contains textures. If you are parsing bin files, you should store how many textures should be read, otherwise there are no way to extract textures correctly. For BGE most of it's textures are paletted textures. It's very difficoult to read, because palettes are stored at different place, than index information. Can you extract every textures from the game?
I hope, you understand, why I don't want to do these things for POP games too. They changed file formats in every game, and POP games lives different life after the beginning.
(tl;dr как найти адерс значения сторигейта через чит энжин для Prince of Persia: Revelations?) BlackDaemon, привет, зашел сюда по ссылке с твоего твич канала, почитав твой пост и посмотрев данное видео я понял что возможно ты сможешь мне чем то помочь. Где-то год назад я начал спидранить PoP:WW (ПК-версию) и узнав про некоторые механики загорелся идеей построить маршрут для спидрана PSP версии. Но все оказалось не так просто ( иначе я бы не написал сюда), изначально я решил протестировать старый маршрут и вот что из этого вышло (видео), на 9:38 я активирую тригер в проходе, который (в пк версии) должен загрузить комнату с порталом, но вместо этого он выгрузил тронный зал. Я также пытался пройти в комнату с порталом без активации тригера в проходе, но закономерно ничего из этого не вышло(вместо комнаты была пустота). После череды неудачных попыток загрузить комнату с порталом у меня возникла мысль что возможно во время того как я пробрался в тронный зал с помощью глитчей я задел какой либо из сторигейтов. Скорее всего ты знаешь, но на всякий случай напишу, что в игре есть специальные тригеры (сторигейты), которые помогают игре отследить на каком моменте сюжета в данный момент находится игрок. Так вот, вернувшись в локацию, где происходит бой принца с Шади, я получил вот это, эта кнопка должна появляться на момент когда принц возвращается сюда в облике песчаного духа -пример. К сожалению этот баг получилось вызвать лишь единожды, после того как я несколько раз возвращался из тронного зала в эту локацию, кнопка больше не появлялась. Оставив надежды найти решение проблемы для этого маршрута, я решил попробовать актуальный маршрут, где вместо того чтобы идти в тронный зал, мы с помощью глитча пробираемся в локацию с чекпоинтом и загружаем энд-гейм область. На этот раз у меня не возникло проблем с подгрузкой нужной мне локации и у меня получилось пройти дальше как показано здесь(к сожалению у меня нет видео, где я делаю тоже самое с эмулятора), но зато возникла новая проблема. Краткая справка чтобы суть проблемы была ясна, на этом фрагменте спидранер добегает до чекпоинта который находится в дверном проеме и убивается в яме с шипами, чтобы сторигейт переключился со 2-ого(2 ой сторигейт соответствует началу игры) на 58-ой( 58 это почти самый конец игры). Так вот, после повторений тех же манипуляций( а именно, я добежал до чекпоинта и убился) игра крашится когда я пытаюсь пойти либо дальше, либо вернуться назад (видео). Я опробовал еще довольно много способов, но все это не дало никакого прогресса и напоминало скорее танцы с бубном из-за отсутствия какого либо способа проверить на каком сторигейте я нахожусь. После этого я решил обратится к такой замечательной вещи как чит-энжин в которой я полный ноль(мой максимум найти значения хп/координат и поинтеры для него) и попытаться найти значение сторигейта. Впоследствии я узнал, что даже если я найду значение сторигейта, найти поинтеры на эмуляторе это крайне сложная задача( не для такого ламера как я) и я решил оставить это дело. И вот как раз по поводу проблемы нахождения этого значения я и хочу к тебе обратиться, я видел что ты сделал сейв эдитор для псп(!) версии на эмуляторе и возможно у тебя есть адрес значения сторигейтов. Если же такого не имеется, то буду премного благодарен любым гайдам по нахождению адреса значения на эмуляторе.
Последний раз редактировалось rl_evader; 28.08.2019 в 19:12.
Репутация: 229 
(весьма и весьма положительная личность)
rl_evader, привет. К сожалению, с поиском и редактированием значений в памяти у меня тоже опыт на уровне начинающего, могу разве что скинуть список чекпоинтов и сторигейтов
По данным - название, тип (WW или Revelations для PSP), checkpointID, locationID. Значения здесь записаны в обратном порядке, т.е. для их поиска в памяти на примере
BlackDaemon, спасибо за ответ. Вчера протестировал timeline2 на пк версии принца и составил гугл-табличку со скринами местоположения всех сторигейтов, не знал что прога работает и с сейвами от псп-шного принца. Надо будет сделать аналогичную таблицу с местоположением сторигейтов в псп-версии, хотя судя потому что ты написал их положение одинаково для пк и псп версии. Скорее всего манипуляции со сторигейтами, которые применяются в спидране пк-версии принца, не работают на псп-версии или работают но не стабильно (получилось же каким то образом заспаунить эту кнопку).
BlackDaemon, после нескольких часов танцев с бубном в тронном зале получилось снова вызвать этот баг, но на этот раз у меня даже остались сохранения (один сейв в мейнхолле, второй сейв прямо возле кнопки). Кнопка заспаунена в воздухе, поэтому чтобы нажать на нее надо свеситься с уступа и залезть обратно. К сожалению я так и не смог выцепить значение сторигейта в чит энжине, но я предполагаю что после манипуляций в тронном зале в этом месте спаунится один из сторигейтов, который является причиной того что локация загружается вместе с кнопкой.
BlackDaemon поддерживают ли твои утилиты, PS2 версию? А то пытался достать модельки из PS2 версии (SOT), с помощью твоих утилит и persian rug, BF Repacker вроде как достает файлы без каких либо проблем, persian rug при попытке извлечь 3Д меш, ругается на "Range check error", плагин для blender (io_scene_pop) так же падает с ошибкой при попытке открыть bin файлы, там тоже ошибка касательно кол-ва байтов либо не возможность разобрать формат текстуры, но текстуры это последнее что мне интересно, больше всего хотелось бы достать 3Д меш из версии PS2.
Репутация: 229 
(весьма и весьма положительная личность)
JakeMiles, в текущей публичной версии - нет. В PS2 заголовок текстур длиннее - 180 байт (192, если учитывать с +12 служебными), к тому же там применяется свиззлинг текстур. Насчёт мешей не знаю, ибо до их разбора пока дело не дошло.
ЗЫ: я писал Sphere (автору io_scene_pop) насчёт PS2/PSP текстур, но у него желания допиливать скрипт нет, только если кто-то допилит и сделает pull-request