ZenHAX

Hello,

We are working on the French translation of the game Tokyo Xanadu eX+ and we encounter a problem with quickbms (we tried with version 0.10.1 and version 0.11)

The game is composed of pkg files which are compressed with the NISLZS algorithm
The extraction goes smoothly and we get the files that are contained in the pkg files and they are perfectly readable

However, there is a problem with the import
Quickbms does not seem to compress the files when they are reinjected into the pkg file: the size of the "compressed" files is greater than the size of the uncompressed files

Example:
- open input file E:\xanadu_working\I_TITLEMENU.pkg
- open script E:\xanadu_working\tokyo_xanadu_ex+.bms
- set output folder E:\xanadu_working\files

offset filesize filename
--------------------------------------

Error: file "asset_D3D11.xml"
the reimport option acts as a reinjector, thereforey you cannot insert a
file if it's larger than the original for not overwriting the rest of
the archive which cannot be loaded correctly:

new size: 192 (188 uncompressed)
old size: 173 (188 uncompressed)

Error: file "titlemenu.dds.phyre"
the reimport option acts as a reinjector, thereforey you cannot insert a
file if it's larger than the original for not overwriting the rest of
the archive which cannot be loaded correctly:

new size: 4710923 (4196830 uncompressed)
old size: 548552 (4196830 uncompressed)

Is it a bug or is there something we didn't understand?
You will find attached the files used for this example

Thank you in advance for your help

I work with Schneitizel on translation.

We forgot to specify that for the example above, the files were not modified between extraction and the insertion attempt.

It's normal when using reimport.bat (basic reinjector).

Use reimport2.bat and it will work

Hello, thanks for your reply!
We tried, and the result was... Quite predictable :p

(When the game should load the modified file ; The .xml is next to a phyre, but if the .xml is not readable, the phyre is unlikely to be readable :/)
And for the .dds.phyre


The .pkg goes from ~400Kb to ~5000Kb with the reimport2 :/

Ok, the problem is the double location of the compressed and uncompressed size values.
In reimport mode we can only change the location where the values used in the Clog command have been taken (in this case the entry).
The following script takes the SIZE/ZSIZE values from the referenced file itself, I don't know if the game will work but you can try using it in reimport mode:

comtype NISLZS

get TSTAMP long
get FILES long
for i = 0 < FILES
    getdstring NAME 0x40
    get SIZE long
    get ZSIZE long
    get OFFSET long
    get ZIP long

    if ZIP == 0
        log NAME OFFSET SIZE
    else
        math OFFSET + 8 # skip the repeated SIZE/ZSIZE
        get SIZE long  # fix
        get ZSIZE long # fix
        clog NAME OFFSET ZSIZE SIZE
    endif
next i

The NISLZS compression uses a fake recompressor that takes double the size since I don't have the original compression code.
In reimport mode the files are appended at the end of the archive if the reimported file is bigger than the original once "stored" back (so compressed or as-is depending by the format).

If even with the new script the game refuses to run, you can use a special feature of the new quickbms beta.
Use the original script (not the new one) and create a copy of reimport2.bat adding the -e option in it, then use it again for reimporting.
The -e option tries to disable the compression used in archives so in this case it will set the ZIP field to zero and store the file as-is.

quickbms beta is available here:
https://aluigi.org/beta/quickbms_exe.zip

This is the content of the new reimport2.bat:

quickbms.exe -G -w -r -r -e

Please let us know what method works.

Hi aluigi! Thanks for your reply, and sorry for the late answer, we tried a lot of things

The "fix" script for reimport2 does not give interesting results: the generated pkg is 1.8 GB

Test with the beta version of quickbms :

The generated I_TITLEMENU.pkg file is 4 635 Kb, the size is correct (base size + addition of the 2 uncompressed files)
On the other hand, the offsets are wrong because they start 8 bytes before the start of the data
So I manually corrected the offsets to make it right, but it doesn't work ingame

The game doesn't crash but is not able to display the image


Here is the normal result, in case


When we set the ZIP at 02 instead of 00


In attachment, you will find the pkg generated with the beta version, as well as the pkg whose offsets I modified

Ok so the 8 bytes difference is definitely a bug in quickbms... I will fix it

The other error is a bit strange because the first hash listed there is the beginning of the xml file ("<?xm").
I suppose also this problem is related to a bug in the reimport feature but I don't understand where it gets the second hash since the archive doesn't have any.
I will check.