Chrono Cross Toolsets

[utunnels]

Speaking of relzss, can the 4 bytes of unknown data be removed?

4. LZSS File Header

Chrono Cross presents LZSS files with a twelve-byte header, which can be divided into 4-byte sections.

The first four bytes are always 73 73 7A 6C—"sszl".

The next four bytes are the expected length in bytes of the decoded file, presented as a little-endian value. Experimentation suggests that this number may not be 100% accurate.

The purpose of the next four bytes is currently unknown.

[Schala Zeal]

I think the unknown 4 bytes may be a CRC32 sum

[utunnels]

It doesn't match any checksum or crc generated by hexworkshop.
But if so it is a good thing because none of the known mods have encountered a problem, means the game ignores the number.

[prizvel]

It doesn't match any checksum or crc generated by hexworkshop.
But if so it is a good thing because none of the known mods have encountered a problem, means the game ignores the number.

About lzss. For example this file after delzss - relzss stops working

[utunnels]

About lzss. For example this file after delzss - relzss stops working

What if you add the original 4 bytes back?

[prizvel]

What if you add the original 4 bytes back?

The header of both files are the same, but the new file is 4 bytes longer than the original.

[utunnels]

Well if the length is changed, the cpt file and the cd need to be rebuild. A simple ppf may not work. Perhaps it is not just this file, when you edit a script, you can't grant it is smaller than original.

[prizvel]

Well if the length is changed, the cpt file and the cd need to be rebuild. A simple ppf may not work. Perhaps it is not just this file, when you edit a script, you can't grant it is smaller than original.

I'm doing a full rebild iso, then prolblem in something else.

[utunnels]

That is strange. What relzss tool did you use?
Terminus Traduction should have their version. Mine were based on some generic lzss code found on internet.

[Danetta]

I saw tons of lzss variants and still have no idea how engine can unpack different lzss files even if they contain the same files inside. Sometimes it works, sometimes no, but seems to be okay with excuses for terrible design, lol.

[alfadorredux]

...

• Known problems: the README was only partly updated, filebuilder.pl was never actually written, relzss.pl never worked properly (it's okay for short files, IIRC, but I screwed up on "what you do when you hit the end of the buffer"), some scripts don't work properly on Windows even though they're okay on Linux. I have a set of corrections someone on Triple-Tech gave me that I never got around to incorporating.

One of the reasons this: the Windows version of Python in the output file adds extra bytes "0D" before each byte "0A"

The problem here isn't the difference in line endings between *NIX and Windows (Perl redefines the bytewise representation of "\n", the end-of-line marker, according to the system it's running on)--it's file mode. Perl under Windows differentiates between opening files in "text mode" and opening them in "binary mode". Because I was working in Linux, I neglected to invoke the binmode command at any point.

[alfadorredux]

That is strange. What relzss tool did you use?
Terminus Traduction should have their version. Mine were based on some generic lzss code found on internet.

If he's using the one in Purple Cat Tools, it's likely to result in larger-than-original files even if the source file was small enough not to invoke the broken part of the script. I think it had to do with the script failing to backtrack into parts of the buffer that hadn't been written to yet. The resulting compression is still valid, it's just that it outputs literals rather than buffer pointers in that one particular case, making for a slightly bigger file.

[prizvel]

That is strange. What relzss tool did you use?
Terminus Traduction should have their version. Mine were based on some generic lzss code found on internet.

Mostly I'll use your utility lzss and 95% of the cases it works without problems, although after repacking the files are noticeably different. A few files I failed to Repack any of the listed programs

[utunnels]

The header of both files are the same, but the new file is 4 bytes longer than the original.

You can test this if you like, which one of them works (if any)?

z1.sszl - result after I changed the compress code slightly
z12.sszl  - remove last 4 bytes from z1.sszl
z13.sszl - remove last 4 bytes from old result

[prizvel]

You can test this if you like, which one of them works (if any)?

z1.sszl - result after I changed the compress code slightly
z12.sszl  - remove last 4 bytes from z1.sszl
z13.sszl - remove last 4 bytes from old result

z1.sszl - work
z12.sszl  - work
z13.sszl - not work