XTool (2020) 0.9.4

Changes
- older zstd versions such as 1.0 can now work alongside new versions of the library

Changes
- improved encoding speed when deduplication is used under certain conditions
- removed deduplication decode memory calculations (takes too long to compute)

Changes
- additional mathematics functions added (ceil and floor)
- fixed issue with zstd recompression
- fixed issues with decode/extract functions

Notes
Not much to say but special thanks to Panker1992 and KaktoR for discovering bugs and for offering support especially over the holidays, and for everyone else, happy new year and I hope you keep compressing

Changes
- added stream count terminator for library checker
- fixed issues related to upgrade from RAD Studio 11.3 to 12
- database structure changes have been reverted

Notes
RAD Studio updates from 11.3 to 12 brought a lot of changes which greatly affected xtool, for one the source needed to be corrected in certain places while some parts of the code needed to be rewritten which I guess is why 0.8.0 seemed to have a lot of hotfixes because I can confirm that not even those fixed everything however with this release, things should be greatly improved.

I've also added stream count terminator when using library checker in UI mode, this is added for large inputs that have really long precompression times and by default, first 10 streams are considered for checking and from those the user should decide which library to use for precompression.

Database structures have been reverted to the way they were before and this is due to the amount of work needed to support the new unreal engine utoc/ucas format because of recent updates to the engine that make precompression using xtool/oo2rec seem unfeasible especially for the newly released games.

- fixed issue with zstd recompression
- fixed issue with deduplication memory setting
- significantly improved deduplication performance when decoding

Update available

Changes

- added recompress streams feature
- added reassign streams feature
- added dummy codec
- added data transfer buffer for srep when dd# is used
- added memory checks to ensure memory usage does not run wild
- exectuable plugins (via xtool.ini) are no longer required when decoding if they were never used
- internal stream deduplication now reports speed and memory usage benefits
- configuration based plugins can now have multiple names (if multiple games use the same configuration)
- fixed xtool crash if an incorect path for plugins was provided
- fixed lz4/lz4hc codec bug when used directly without any plugin
- fixed an issue where using fast-lzma2 compression would crash when decoding
- fixed an issue in DirectStorage gdeflate codec
- fixed an issue with execute command in stdio mode
- deduplication memory requirements improved
- memory optimisations
- reduced memory requirements for large streams that require patching
- removed ability to inject libraries to exe (buggy)
- removed patch command (uses too much memory)
- removed archive command (no one uses it)
- updated oodle scanner
- updated lz4/lz4hc universal scanner
- updated lz4/lz4hc/lz4f codecs
- updated zlib codec
- updated zstd codec
- replaced gpu caching feature with normal system memory cache (it doesn't work well on AMD gpus), use -p#
- replaced xdelta3 with zstd patching engine
- srep64 executable considered in x64 build of xtool


This update was supposed to be released a long time ago, but he would find more bugs hence the long list of changes.

I won't say much other than notable changes, xdelta was replaced by zstd patching engine (yes... zstd can make patches too, shocking I know...), reason for replacement xdelta gives me less options coding wise to work with in terms of memory management.

Injecting libraries feature also removed as some libraries when injected completely stop working or worse, cause xtool to crash.

I've quietly added cls plugin in the previous update and did not tell anyone about it simply because it was never tested, for this update It was tested and it works so long as you never used fast-lzma2 in any of the archives when using it with installations created with inno setup as it would simply cause a crash.

I've left 0.7.8 on the main post in case there are issues with this update even after extensive testing.

Update available

Changes
- fixed an issue where xtool would crash on Windows XP and other systems upon closure
- memory optimisations
- improvements with database "based" plugins

Update available

Changes
- added universal scanner for DirectStorage gdeflate streams
- added the use of gpu for caching and virtual memory purposes
- updated depthing feature to improve stream detection when used by plugins

Notes
With the release of the game ratchet & clank: rift apart which used direct storage's gdeflate compression within its game files, I thought... hm, why not just add a scanner for these streams and so I did after investigating the stream structure (was easy to figure out actually). Use via -mgdeflate.

Will games use direct storage? I don't know but if they do then at least xtool has support for the streams used in the games, I just added it so that repackers don't flood me with DMs when they have troubles repacking games, maybe Starfield might use this...

After several tests, the gpu feature can now be used by the general public, use via -g#

Update available

Changes
- Minor bug fixes

Notes
This release contains recompiled zlibwapi.dll, preflate_dll.dll, lzo2.dll (to remove Visual C++ 2010 requirement) and xdelta3_dll.dll simply because there are people who are using Windows XP in this day and age, shocking I know...

Спойлер: image

Update available

Changes
- user can specify srep parameters to use via -sp#
- updated zlib codec

Notes
the -sm# parameter is removed, now if you want to control the memory srep is bound to use, you use refer to the list of srep's parameters and use it as such -spmem75p or whatever it is you prefer, -sp is also available when encoding in order to specify additional srep parameters like the user Gehrman has requested. -spa0:l512.

The executable got bigger because I've been busy trying to add some features to the program that have not come into fruition but if you're a nosy person, you can check the source code to see what caused the exe to get big.