XTool 2020 (Main Project)

[Razor12911]

Update available

Changes

- fixed issue with storing correct recompression information when stream patching is performed

Notes

This issue was brought up by Masquerade and L0v3craft when they were trying to precompress WRC 10 and upon decoding xtool would produce an error so thanks to them, it has been resolved however I'd like to add more useful information regarding this game and why even with xtool helping you with deltas will not allow you to process all streams based on how xtool was designed.

We all know that xtool patches streams if they cannot be restored correctly however it sets its own boundaries, by default the patch file cannot be 5% larger than the original size else the patch fails as highlighted here with some streams being missed. https://fileforums.com/showpost.php?...&postcount=248

This 5% can be changed by user via the command --diff=5p, with 5p being 5%, so to capture all these other streams, you'll have to increase this percentage.

CHUNK_57.PKG
using -mwrc10

Compressed 1 file, 99,435,664 => 189,185,421 bytes. Ratio 190.26%
Compression time: cpu 0.14 sec/real 3.71 sec = 4%. Speed 26.82 mB/s

using -mwrc10 --diff=20p

Compressed 1 file, 99,435,664 => 263,029,277 bytes. Ratio 264.52%
Compression time: cpu 0.09 sec/real 3.61 sec = 3%. Speed 27.53 mB/s

Verbose information displays

[0] Processing lz4f stream at 0000000000005476 (514 >> 893 >> 514) using l9:b4:d0 has failed
[0] - Patching stream at 0000000000005476 (514 >> 514) [26] has failed

Patching this 514 byte stream produced a 26 byte patch file, which is 5.1% and that is larger than the 5% limit so increasing this means you are allowing xtool to accept this stream.

--diff=20p

[0] Processing lz4f stream at 0000000000005476 (514 >> 893 >> 514) using l9:b4:d0 has failed
[0] - Patched stream at 0000000000005476 (514 >> 514) [26] successfully