Closed Viz-Allati closed 3 years ago
Вы правы. У вас нормальный blk с именами внутри, в виде, каким он предполагался. Он должен начинаться с байта 0x1
, так же как blk с именами снаружи начинается с 0x0
, но его код формата не 0. Неточность во vromfs_unpacker.py
.
В War Thunder все blk нового формата содержатся в директориях "нового формата", в которых присутствуют blk c именами снаружи либо версия файла выше заданной 0x02_07_00_3a
для War Thunder.
Некоторые ветки для packed_type
, фактически, оставались не протестированными к моменту написания парсера blk, поэтому, ко мне сначала попали файлы с 0x0
вначале, но не с 0x1
.
Позже датамайнер обнаружил файл типа 2 внутри архива сигнатуры VRFs
с таблицей имен, и я добавил в условие "нового формата", что там должны быть файлы типа упаковки 2, 4 или 5. Все они сжаты zstd, раньше такого не было. Распакованная часть файла типа 2 начиналась с 0x1
, и, чтобы не переписывать парсер blk, я этот первый байт пропускал, как и в случае с файлами типа 1. Архив с таким файлом regional.vromfs.bin
, в массе был не нужен.
Как решение, в файле vromfs_unpacker.py
я не буду учитывать версию из расширения заголовка, а буду смотреть только по содержимому архива: есть ли среди них общий список строк/имен, словарь для декомпрессора или .blk файлы, у которых первый байт из 0x1 .. 0x5
Действительно, теперь .blk распаковываются без ошибок, благодарю. Есть проблема с одним из .vromfs.bin файлов, но к blk это не относится, заведу issue в соответствующем репозитории. Спасибо.
Упс, не заведу, в kotiq/wt-tools это запрещено. В общем, проблема следующая:
D:\Soft\DataMining\wt-tools>vromfs_unpacker.exe ../aircraft.vromfs.bin Traceback (most recent call last): File "C:\hostedtoolcache\windows\Python\3.8.10\x64\lib\site-packages\cxFreeze\initscripts\__startup_\.py", line 74, in run File "C:\hostedtoolcache\windows\Python\3.8.10\x64\lib\site-packages\cx_Freeze\initscripts\Console.py", line 36, in run File "src/wt_tools/vromfsunpacker.py", line 208, in \<module> File "C:\hostedtoolcache\windows\Python\3.8.10\x64\lib\site-packages\click\core.py", line 829, in __call_\ File "C:\hostedtoolcache\windows\Python\3.8.10\x64\lib\site-packages\click\core.py", line 782, in main File "C:\hostedtoolcache\windows\Python\3.8.10\x64\lib\site-packages\click\core.py", line 1066, in invoke File "C:\hostedtoolcache\windows\Python\3.8.10\x64\lib\site-packages\click\core.py", line 610, in invoke File "src/wt_tools/vromfs_unpacker.py", line 204, in main File "src/wt_tools/vromfs_unpacker.py", line 60, in unpack File "src/wt_tools/vromfs_unpacker.py", line 60, in \<genexpr> File "src/wt_tools/vromfs_unpacker.py", line 58, in \<genexpr> IndexError: index out of range
Vromfs_unpacker собран так, aircraft.vromfs.bin из Enlisted, прикладываю. aircraft.vromfs.zip С остальными .vromfs.bin файлами проблем нет (по крайней мере с теми, которые меня интересуют).
Добавил значение для генератора в случае пустого файла.
Ещё раз спасибо, всё работает.
Enlisted и CRSED это две другие игры под издательством Gaijin, так же на движке Dagor Engine. Соответственно формат blk там используется примерно тот же, что и в War Thunder. Однако при распаковке возникают ошибки, например следующего рода:
Версия Python 3.8.10, под Windows. Версия blk_unpack_demo.py (и остального) от 16 августа. Проверил на относительно свежем aces.vromfs.bin из WT - blk распаковались нормально, так что пока что предполагаю, что причина не в том, что я накосячил при установке инструментария. До всей этой заварухи со сменой формата WT Tools работал нормально с файлами из этих игр. Прикладываю примеры сбоящих blk и исходного vromfs.bin из Enlisted. sample files.zip