Legend of heroes - Sora no kiseki BMS script

Extraction and unpacking of game archives and compression, encryption, obfuscation, decoding of unknown files
sigroon365
Posts: 330
Joined: Fri Nov 21, 2014 4:03 am

Legend of heroes - Sora no kiseki BMS script

Post by sigroon365 »

Actually, it was discussed on other thread.
http://zenhax.com/viewtopic.php?f=9&t=60&hilit=Trails
But Ekey's bms script didn't support uncompress, so I wrote it.
It works on all *.dir files but reimporting is not work.

Script Samples https://www.sendspace.com/file/dhcb7h
Result.
Image

Reimport Error.
Image

Code: Select all

#Select *.dir or *.dat files to unpack.
comtype falcom
open FDDE DIR 0
open FDDE DAT 1

idstring "LB DIR"
goto 0x10

Do
    savepos tmp
    getdstring name 0x10
    get ZSIZE long
    get UNK long     #This is NOT SIZE
    get ZSIZE2 long
    get CRC32 long
    get OFFSET long
    savepos tmp2

    get packname filename
    string packname += _unpacked/
    string packname += name

    if ZSIZE == 0

    xmath tmp "tmp + 0x24"
    goto tmp
   
    elif tmp2 = EOF       #For ED6_DT09.dat
    cleanexit

    elif ZSIZE = UNK   #For *._X2, *.wave and *._DS(dds file).

    log packname OFFSET ZSIZE 1

    elif ZSIZE = ZSIZE2
    clog packname OFFSET ZSIZE 0x1000000 1
    endif

While name != "/_______.___"


I read document and it seems that quickbms support falcom_compress.
What did I do wrong?
Image
aluigi
Site Admin
Posts: 12984
Joined: Wed Jul 30, 2014 9:32 pm

Re: Legend of heroes - Sora no kiseki BMS script

Post by aluigi »

The falcom_compress works perfectly.
In this case the problem is simply that your file when recompressed (even if untouched) occupies 1 byte more than the original (2023 against the 2022 of the original one).

The algorithm has not been written by me and I have no idea of how to improve it (maybe by modifying some constants like the back value).
sigroon365
Posts: 330
Joined: Fri Nov 21, 2014 4:03 am

Re: Legend of heroes - Sora no kiseki BMS script

Post by sigroon365 »

aluigi wrote:The falcom_compress works perfectly.
In this case the problem is simply that your file when recompressed (even if untouched) occupies 1 byte more than the original (2023 against the 2022 of the original one).

The algorithm has not been written by me and I have no idea of how to improve it (maybe by modifying some constants like the back value).


Hmm.. Ok. :roll: