What about decompression for FarCry 3?

Since when COD WWII was 38.4 GB SP Only ? I thought it was around 42 GB after removing MP/ZM files, am I missing something here ? Have you kept xpakfile*.pak ?

xtool seems to work on Wolfenstein The New Order resources files like doom...
but files with .pages file nothing there...

also on The Evil Within tangoresource files work

Edit xtool.ini, add all the dat files in there

something like this then use lzo codec in arc.ini

Same applies to Far Cry 4 and Far Cry 5, except with Far Cry 5, use lz4

I heard Far Cry Primal uses modified lz4 and as for Watch Dogs, I have no idea how to use xcompress library in Delphi otherwise detecting its streams is easy.

If I like that idea, here I leave the game for tests thanks Razor12911

MGSV Ground Zeroes

Hi Razor12911
Unreal Engine 3 LZO may be added in the future?
XCOM 2, Outlast 2, Get Even

to doofoo24: what liblz4 did you use for cod aw?

I already tried this one, it doesn't expand anything (Only tried imagefile1.pak). Did you use xtool.ini?
I used this:
packcmd = xtool.exe e:precomp:t4:v:c32:lz4 - - <stdin> <stdout>

By the way, note that you can find some of my repacks - Quantum Break (23.3 Gb) and outlast 2 (10.2Gb) on ygg if you are interested. You can erase this, I'm sure it's against the rules of the forum.

@everyone

Please make sure the command line is correct first.

"e:precomp:t4:v:c32:lz4" is heavily incorrect

Well, it seems it works with e:precomp:t100p:lz4 with .ff files. For pak files it's ok too. (except for soundfiles which can't be expanded).

imagefile59.pak

bik reencoded at 70% indeed. Do you think you could get sth much better? probably not. I did nothing special just used srep and lolz.

As razor sayd, options are incorrect.

This one is correct
{options} must be seperated by a comma (,), not a colon (:).

And you forgot a "m" for chunk size.

Lol I know alright, same trap happened to me with my rawinjector ^_^.

Now this is nice step forward, to support files like this that are perhaps not easy to detect. I would love to see this going even further in the future, where user could script offsets and data reading with few commands. Example:
Above example would mean: find first/next header with "0f3b4c5b" bytes, then skip 125 bytes, then read 64bit integer that is compressed size, then same for decompressed size, then read and precomp next CMPSZ bytes with above info, repeat until EOF.

Idea is that most engines have similar structures, there are some headers, some data to skip, there is CMP and DECMP sizes info in between and then actual compressed data chunks. So instead of keeping maintenance for every new game/engine which rely on Razor to be here for us and kind enough to work on updates, this would make xtool more forward compatible for the future games without needing to constantly updating it. At least until codecs API's change. I know it will not be enough for every future game but it should cover plenty of them.

I apologize for stupid question but was there specific reason for using extra "precomp" word, aka e:precomp... instead of just e:... d:... as was in ztool? To me it seems redundant as e: and d: already imply default behavior(encode vs decode) and precomp seem'd to me at first confused with precomp tool by schnaader. Also using different separators, aka ',' and ':' for specific areas of cmd make it prone to type error, as happened to me before and I seem to be not the only person. Pure ':'s in ztool were fine and easier for inclussion with other utilities IMO. BTW I am not complaining, this tool is fantastic and ultimate, just being curious about new design.

Don't ask me, ask razor why :D

Only explanation i find is that xtool won't be limited to pre-compression only. I might be talking gibberish here and it's just a redundant word as you say. ;)

Razor certainly has plans to implement already exisiting compressors into xtool like razor,lolz etc... with stdio support to make it a universal tool but I might be also talking gibberish here, only Razor knows :confused:

Thamks but fc3_main.dat (3.2gb) not decompressing(((

I'll check

Update available

Changes

- added partial unreal engine lzo support (thanks to Edison007 for lzo1x_99 args)

Notes

This is might as well be a useless update at the moment because I'm pretty sure either old or few UE games use the method that is precompressed by 0.10, I'm still trying to figure out how to precompress the rest of the streams which are common.

With 0.10 update - also not decompressing

Razor but for the decompression of the archive the folder can only contain the file xtool.exe, without any *.dll right?

Couldn't understand your question but you need to have the dll for the codec you used, in the same folder as xtool.exe. Suppose you used lz4, you just need liblz4.dll not the others.

No, for decompression u r going to need same dlls which u used for xompression. that means if u used plz4 during compression u r going to need xtool + liblz4 for decompression.

Strange for the decompression seems to work without any DLL, only xtool.exe, tried on a data folder of generic files, that's why I was curious to understand ...:confused:

If it had zlib streams then it works without dll as well because xtool has internal zlib/deflate libraries but dont know if razor did that for other codecs too maybe yes he did considering how stupid people can actually get :D

But its always recommended to use latest external libraries for faster processing.

wow how many masters and experts in compression lately here in the forum, it's been a while that I'm not here in the forum, it's not about ease of use for people, it's about knowing whether or not to insert the DLL for decompression, "Faster Processing" explain to me what it means because the decompression speed is the same, since we are talking about decompression and not compression.

If I remember correctly, razor once said that internal processing can be actually slower at certain stages when compared to its usage with external libraries. I might be wrong but thats what I remember. Plus I am not even sure what internal libraries are present in xtool, only razor knows, maybe reflate libraries are not present. With ZTool, I noticed size was better with external libraries in some cases and faster too, but its XTool so who knows, maybe Razor improved it. But one thing I can tell, its always better with the external libraries so I don't see the problem in using them.

But really the main reason for internal libraries is for the ease of people. Razor implemented the internal libraries so that processing will still work in case people don't even put the dlls at the correct places, that was the main reason I think.

This is what I do not understand, I wanted a concrete motivation, in my concept of coder, a file if needed I use it, if I do not need I do not use it, I do not insert files because I like the dll extension or others, as many they do, without really understanding their use and necessity.
I wait Razor look for a response aimed at my curiosity, thanks anyway for your intervention.

excuse me for post this. i googled before but not good results. is there a link to a tutorial on how to use x-tool i wanna test it to sve some data in my hdd and im totally noob in this .

i ve used the bat file but didnt compress or i really didnt see the difference with the actual file. (a ps2 iso files, even unrared)

It all depends what actual "internal processing" is. Does it mean just dll's included inside exe, does it mean official source code translated to Pascal and included/compiled with project, or does it mean having your own self-written routines?

For 1. case there should be no difference, for case 2. and 3. my guess is that since Razor code in Borland's Delphi, that could be one reason for slower internal routines vs external dll's. Because I used to code in Borland's C++ back then and I remember it was not that fast. Also B. Pascal, just like B. C++ use own libraries, own compiler and both are object based languages. Which will be slower than standard direct C routines, say through MinGW. In most cases that is, few exceptions like STL aside.

Since dll's of codecs like lz4, zstd and most others are written in C and already optimized by its devs, they should be quicker as Delphi is then only used as a bridge for io calling. Yes normally internal routines should be always faster than calling external dll's, but only if under same environment and optimizations. Here we are basically talking B. Pascal vs C overhead and thats assuming routines are perfectly written or translated/optimized to Pascal which they may not be, so you get a speed difference based from both factors.

Dll's also give you ability to switch between different versions as long as they use same API which is another plus.

And?:)

i think pascal compiler's abi is compatible with maybe gcc(if gcc not, i think its borland(embarcadero) c++ itself which sucks at optimizations) so they used compiled objects and directly links with the pascal code see https://github.com/madler/zlib/blob/...al/zlibpas.pas
Another trickery can be, represents your dll as hexadecmial literals in your code and using some library like, to directly load from memory, quickbms uses it

For what I have tested the borland compiler is based on clang(msvc edition), as far as minGW posix is not compatible, I just do not know if it is possible with minGW win32. Since you use msys2 then it's posix!

2011 clang which has shitty windows support and they somehow glued it with shitty code, change its core abi to make it work , it's just not right, it can't even compile c++11 correctly even their vector and share_ptr has bugs that why i was using my own implementation in designer and these compiler bugs made me left designers

error with decompression too. Only 1 file, 1.3Gb. Included xtool+liblz4.dll. The installer is stuck at the end, and the file is different: 1,405,353,984 byte vs (1,405,386,216 bytes for the original.

I'm using this...
unpackcmd = xtool.exe d:precomp:t4 - - <stdin> <stdout>
Since others have similar problems, there is probably sth wrong with xtool.

except that I can obtain a better size than doofoo: 22.5Gb. You can select some bik files, even if some are giving an error.

what is ur packing command?