L0v3craft, as far as i know you need to unpack the archive with the key, compress it's content and then re-import the files back.

I can extract it with quickbms, but you mean re import with quickbms ? Is possible to implement it with inno in the way that inno can shows the installation with a progress bar ?

Yes.
Maybe, haven't tried yet.

Update available (.. or rather update was available, I forgot to post this)

Changes

- added mk11 lzna support

Status

Project is halted, and to be replaced with this

Thanks for this. Did you fixed the big input bug yet? Or is this on your to-do list? :)

to do list, I have chosen to rewrite the project from scratch, surely that will fix many if not all issues but who knows :)

inflation test of mk11 successful i am now repacking it and will do a test unpacking

Don't expect good ratio, LZNA is the best compression algo in Oodle family.

@everyone
I'm now focusing on the main code of XTool 2019, so now it's a good time to mention all the bugs the current xtool has so I can try to avoid as I write the new code from scratch and what new features would you like to be added in the upcoming release.

^^
For oodle codec on AC:Origins and Odyssey: XTool only unpack a small amount of forge files in the beginning, then it just copy the rest of the files (ratio is somewhat by ~102% overall if I remember right).

I think there was something with lz4hc on Far Cry too (I just don't remember what it was exactly, I'm sorry).

Would be good if you can add lzo for unreal engine games (borderlands, ME1+2, etc) and for the older forge engine games aswell.

Btw, what about oodle3 codec? Destiny 2 is using this and I can't get it with xtool nor your oodle tools released previously (oo2recx).

I think it is also best if you provide samples and the required resources to make precompression possible, like dlls. You could start with oodle... I just hope the headers are still the same

Here are a few samples

Destiny 2 (oodle 3)

Borderlands 2 Remastered (unreal engine lzo)

Borderlands PreSequel Remastered (unreal engine lzo)

Mass Effect (unreal engine lzo)

Mass Effect 2 (unreal engine lzo)

AC Odyssey (forge engine oodle 4)



Maybe more to come...

if it's an unreal engine game compressed with lzo then for precompression, you must provide lzopro, standard lzo cannot restore any of the streams. If you use ztool/xtool but skip verification, you'll notice that the precompressor does see the streams but just for the fact that it cannot restore them with perfect crc, it just skips all of them. The reason I added skip verification was the fact that if it ever came to a point where one cannot really precompress a game with perfect crc, it should then at least allow you to try to pack a game with different crc but then also allow you to repack it, example of this was DmC: Devil May Cry, also unreal engine game compressed with lzo, I couldn't use xtool to precompress game but used skip verification, the game files were different but the game played from start to finish without crashing plus I managed to save space after repacking it.

as for Odyssey, probably some internal issue but the scanner does see all the streams in the samples
DataPC_ACD_Greece_DX11.forge:
for Destiny, I think lzna was used on this game just like mk11 (I see a lot of 0x058c headers everywhere), support for lzna is not added at the moment, but I obviously need to confirm this.

thanks so much

Yeah I used oo2recm for Odyssey and it worked fine (AFR works too but has no stdin support for compression, means temp files are over 250GB in size before srep even starts). With XTool:oodle it was just game size + ~2gb temp file (in task manager xtool just stop working after a certain point just in the beginning, no cpu or ram load, only hdd load for copying).

We already can use uelr for the unreal engine lzo games listed above, but the main problem is, that it has no stdin too and only specific files can be unpacked with it (unlike xtool, you can't just pack the whole game with uelr if files are present which don't have lzo streams, for example binaries or text files. You have to use masking or a seperate archive if you use diskspan for example. With xtool we can just pack the whole game without seperate it by files or streams).

Thanks I'll look into it :)
I guess those are all the issues

can someone bless me with a sample of Dragon Age Inquisition, it's required for development of XTool 2019

Lemme download it. I will send you some samples later (if no one else do it).

Did you need any libraries or just archives?

The game should be Zlib compressed, I guess only archives. I just need one cas archive, you can run a scanner or something like that to confirm on whether the sample you are uploading does indeed contain zlib streams. If you want to quickly upload the cas file since most definitely they are 1GB, you can really slice the file and give the first 100MB or something like that, I only need it to see the header structure to improve speed for games that use frostbite engine.

Ok. Download is on 70% right now.

I have one question: According to the Bethesda BSA extractor, Skyrim Special Edition use lz4 compression, but the game file scanner didn't find anything and I can't find any usefull information about it on the usual sites like xentax etc.

Did you know the trick? Are these archives crypted somehow? Most of the files aren't compressable in the usual way (ratio is always at 99.9%).

give sample and the extractor, and I'll take a look at it.

Dragon Age Inquisition


Skyrim SE
Skyrim SE BSA extractor

@Razor12911 what about encrypted game files like fifa/project car/crysis :D:D:D

https://fileforums.com/showthread.php?t=102524
https://fileforums.com/showthread.php?t=102461

as for Crysis, if I had an idea as to how it was encrypted, I would have made a tool for it

i know the tools for fifa/project car...
i thought the new xtool will work on encrypted files like QuickBMS :o

it could, but as of right now I am busy optimising the code and getting rid of old bugs, main focus is more speed and less cpu/mem usage

yes i know this but some compression is better than no compression at all the way i see it

Perhaps 2 thing's left are lzss and nintendo's yaz0. Very important for some Jap games and especially console roms.
EDIT: also xcompress and endian versatility.

EDIT: Also codecs help is missing, for instance xtool can utilize same :m2, :high, etc. parameters for zlib like ztool does, but I wouldn't know if I was not familiar with ztool from the past.

Why ZTOOL needs "Visual C++ MSVC**.dll" files for unpacking archives ? is there any workaround for this limitation ?

But XTOOL is standalone & stable.

Xtool needs VC++ 2010.

no it doesn't, it's the libraries that come with precompressor that do

This clarification is true , i have tested both XTOOL & ZTOOL on clean fresh operating systems & only ZTOOL needs Visual C++ 2010 & 2013 libs while compressing & decompressing

But can I somehow do this to put the folder to check xtool and the files in which the zlib... streams were hoped for example were displayed in a separate list?

Hi Razor, I apologize for not having enough time recently to participate despite my promises, but now I have something to share since I am repacking FFXIII series. Looks like ztool is still more reliable choice for now, at least when it comes to zlib. xtool is not detecting/inflating zlib-compressed file from FFXIII at all, it does inflate at deflate :m2 option but even then slightly less than ztool. Ztool on the other hand both zlib(:m1) and deflate(:m2) reliably inflate file, with :m2 even slightly more(but even :m1 inflate 5mb more than xtool :m2). Anyway, here goes screenshots:
Attachment 25148
Attachment 25149
Attachment 25150

This is with v0.12, I don't know if it was fixed already or not. Anyway hope it help & best regards, if I find more during repacks I will post.

EDIT: Noticed yet another xtool thread. Not sure why there are so many for same tool but whatever, so I tried that version with zlib and rzlib options and it does seem to be working. Although cmd command piping is broken in that version and so doesn't work with lzscan's stdio (aka: "cmd | xtool | cmd").

Hi, so does it work now? the New xtool I mean.

As for stdio, well I didn't change anything there so pipes should work because if that was the case then xtool should also not work for Freearc

I can confirm the issue:
Attachment 25157
Attachment 25158
On second pic you can see commented(green) line - that was for xtool 0.12 and it would work. This is script from lz_scan which if you need as whole tool to check you can download on this site. On top of it, I can also confirm that unlike v0.12, v1908 will inflate if used on files directly. About 1mb less than ztool, but that's not a big deal now.

So yes, v1908 will inflate unlike v0.12 without needing deflate, but also broke pipes.

you have to specify - - for stdio

I only see "xtool.exe precomp:zlib", should be "xtool.exe precomp:zlib - -"

Those " '|' (xtool) '|' " characters are pipes, that's how you pass data between programs and its is well known standard. Normally, you wouldn't never use '-'-' additionally in such case but I will try something like "cmd | xtool - - | cmd" later and let you know. Again v0.12 and ztool work fine like this.

Ok I can confirm that if I use "cmd | xtool precomp:zlib - - | cmd" then it work. Although '- -' should normally not be necessary in this type of syntax, at least it works. Thank you for a great tool.

Dude, I know that "|" is for pipe, but - - is for stdio in terms of xtool

The usage for xtool goes like this

xtool command input output
"-" denotes stdin/stdout depending where you put it.

This is how I have written it

The reason I have added it as "-"

is because what if you can accept input as stdin then the next program requires an existing file
it then becomes something like this

xtool command - output

or if input is a file and output is required as stdout
it becomes
xtool command input -

if pipes are involved it means stdin and stdout takes place which is why it is
xtool command - -