How to use verbose mode

Drag&Drop a file on batch

ELDEN RING - XTool Update Test (Data3.bdt)

Old XTool - xtool:kraken,l6
New XTool- xtool:kraken,l6
New XTool - xtool:kraken,l6,n1
New XTool - xtool:kraken,l6,n2
Library Used : oo2core_4_win64.dll

Check previous page and download the library from there.

External executable!!!
 

resident evil 4 HD project "*.lfs" Precompressor
https://github.com/emoose/re4-research

Arc.ini
https://upload.cc/i1/2022/02/28/aWcFp5.jpg


--------------------------------------------------------
But it does not work with XTool
XTool.ini
https://upload.cc/i1/2022/02/28/BdNR6z.jpg



Is there a way to solve it?

can you send sample and the exe?

Razor12911
Is it possible to make lz2k-plugin for XTool?

There's no recompression code for this algorithm, not even QuickBMS can compress LZ2K.

How to decompress unity files? What dlls are needed? And if possible examples?

Some use 1.8.0 version of liblz4.dll

SMBBHD works like XTool v12
Cris Tales, has some LZMA doesn't work due to use of LZ4, use UBT
SMBBM, similar to Cris Tales
Trollhunters, not much, use UBT
Tin & Kuna, not much, use UBT
NSLT, possibly that much unlike XTool v12

I understand the Leviathan codec isn't to be used directly and instead by plugins, so I am attempting to create a database for Wolfenstein Youngblood using a modified BMS script.

The script dumps the leviathan streams to disk and that should be enough to generate a DB, however I recieve an error that the filename of the database I made is not a valid method if I attempt to precompress.

I have attached below a sample file + BMS script if anyone would like to have a look.

The leviathan stream is signified by the 0x8C0C header.

https://www43.zippyshare.com/v/fCNMmXpB/file.html

Thank you for last update, it solved zstd crash for me.
Would it be possible for xtool to additionally print its version when run without parameters? So that it does not rely on file name.

Also, additionally to direct dll loading, I would suggest automatic multi lib query like this:
1_zstd.dll, 2_zstd.dll...
1_lz4.dll, 2_lz4.dll...
1_oodle.dll, 2_oodle.dll...

With those files in xtool directory, *all* of them would be loaded and then sequentially tried up to certain point.
For example at the beginning all compression variation on all dll's would be tried until at least 1 valid chunk is found. Then dll's without result would be discarded and if multiple exist with different size then those with lower size also discarded. Those with same size could still be used up to certain number of chunks in parallel unless either different size is produced or simply all but 1 are discarded in case all kept producing same size.

This way user can just put all different versions of libraries and forget about manual "query and try".

In case different versions use different API, another naming alternative would be agreed naming convention, for example zstd_v1.2.dll, lz4_v1.2.dll or any other, where xtool would be aware of that version(or version range) and which names of API functions specific dll use.

Update available

Changes

- fixed issue of lz4 codec loading incorrect library
- fixed issue with handling endianess via configuration based plugins
- updated framework of library based plugins

@elit
For example at the beginning all compression variation on all dll's would be tried until at least 1 valid chunk is found.
- This cannot be done because versions closer to each other tend to produce the same result and in some streams especially on a small number of them, they produce different results.
- Example, version 1.4.3 and 1.4.4 of zstd, these two libraries can produce same result and would be considered valid chunk using either one of these libraries however this may not be the same for the rest of the input.

Those with same size could still be used up to certain number of chunks in parallel unless either different size is produced or simply all but 1 are discarded in case all kept producing same size.
- The issue with this is considering xtool processes data by chunks, if it processes version by version, it would need to store all results somewhere, most probably in memory and every single library would need its own memory set, coding this would be problematic at least from my end.

@Gehrman

Sorry for late reply, I checked out the sample and the only way this would work is by generating a database using generate function in xtool (which is currently broken), but it will probably be fixed in the next release.
I'll possibly upload the re4lfs configuration example. :)

Thank for update..
But..Metro Exodus lz4 streams still not being searched for((

Metro Exodus lz4 support was never added to xtool, remember you cannot use lz4 codec directly in this program, only via plugins and a plugin for that game was never made.
https://fileforums.com/showthread.php?t=103563

Update available

Changes

- removed leviathan codec restriction

Notes

Xtool can "actually" detect leviathan streams however the only way it can process them is if they are divisible by the block size used by the new oodle compressors which is 262144, if a stream decompressed size cannot be divided by this value leaving no remainder then no way of predicting the stream size (at least that I know of) is possible hence why plugins are the only ones that were allowed to use the leviathan codec.

If you are not satisfied with the results produced then find a way to make a plugin for proper support for that particular game.