XTool - Successor of ZTool

[ZakirAhmad]

Tried it on a file from mass effect 3, precomp042 precompresses better than xtool on it.

[Simorq]

Originally Posted by Webster17

Cons:
Installer freezes if aborted, just like pzlib3. You have to close the xtool process from task manager.

Use TaskKill

Exec(ExpandConstant('{sys}\taskkill.exe'), ' /F /IM XTool.exe', '', SW_HIDE, ewNoWait, ResultCode);

[Sergey3695]

When packed file more 4 gb

[Razor12911]

Originally Posted by doofoo24

seems not to work with zlibwapi only like ztool ?
* and srep and lolz does not show data size ???

works with zlibwapi.dll, zlib1.dll or zlib.dll, whichever is found

Originally Posted by Sergey3695

When packed file more 4 gb

Probably some bug, will look at it, found more bugs while working on the Naruto series

Originally Posted by ZakirAhmad

Tried it on a file from mass effect 3, precomp042 precompresses better than xtool on it.

Great, this is only news. Upload file if you want something done about it.

[ZakirAhmad]

ofcourse i will send u the file.

[darkwolves]

i repacked sonic forces to 7.94 gb by extracting the cpk... files and packed the files back up after installing.... and it takes alot of time but now i will use this and see how well i can compress it .

[-NORO-]

x64 xtool shows DiskFull
x86 is working

[Gupta]

X32:

FreeArc 0.67 (March 15 2014) Creating archive: Data\xtooltest.arc using xprecomp
Memory for compression 0b, decompression 0b, cache 32mb
Compressed 2 files, 1,164,384,256 => 2,249,898,011 bytes. Ratio 193.23%    
Compression time: cpu 0.66 sec/real 42.90 sec = 2%. Speed 27.14 mB/s
All OK

FreeArc 0.67 (March 15 2014) Extracting archive: Data\xtooltest.arc
Extracted 2 files, 2,249,898,011 => 1,164,384,256 bytes. Ratio 193.23%     
Extraction time: cpu 0.30 sec/real 37.40 sec = 1%. Speed 31.14 mB/s
All OK

X64:

FreeArc 0.67 (March 15 2014) Creating archive: Data\xtooltest.arc using xprecomp
Memory for compression 0b, decompression 0b, cache 32mb
ERROR: write error (disk full?) in compression algorithm xprecomp*

FreeArc 0.67 (March 15 2014) Extracting archive: Data\xtooltest.arc
Extracted 2 files, 2,249,898,011 => 1,164,384,256 bytes. Ratio 193.23%     
Extraction time: cpu 0.23 sec/real 36.51 sec = 1%. Speed 31.89 mB/s
All OK

*no crashes or anything else

[78372]

Probably this disk full error is by fa(standard error), I faced it many times during many projects and when I used stdin for encoding, this was a common error, though I am not sure it is the same error for xtool or not. But those who are facing these errors, try using $$arcdatafile$$.tmp instead of stdin(Not tested here)

[Gupta]

why do you think i haven't tried it?

[darkwolves]

trying xtool with uharcmt it seems to be working pretty well

[Razor12911]

I'll take a look at x64 issue

[elit]

Greetings Razor, I only now discovered this. Its fantastic that you decided to remake ztool. Specifically CRI format is great to see for sure.

If you are interested in adding oodle in future, it is pretty much "8C 06" pattern to look for *always*, with cmd/uncmp sizes preceding it. Even in engines like unreal where offsets to these sizes are to get from initial game header, they are still located just before "8C 06"(xcom 2 wotch), e.g: cmp(long) - uncmp(long) - data(starting with and including "8C 06").
Oodle is in fact rather predictable to detect and extract, I made bms script that was able to extract from xcom 2(over 20gb+ data) unreal files error-free without bothering to use their own format to locate those chunks.
To differentiate from fakes, first byte before "8C 06" must be "00" because chunks should never be bigger than 8mb and whole 4byte set before "8C 06" when translated to integer should not exceed 8mb. Thats all.

Well anyway, I hope for this to become as great tool one day as is ztool now. Thank you.

[Razor12911]

Originally Posted by elit

Greetings Razor, I only now discovered this. Its fantastic that you decided to remake ztool. Specifically CRI format is great to see for sure.

If you are interested in adding oodle in future, it is pretty much "8C 06" pattern to look for *always*, with cmd/uncmp sizes preceding it. Even in engines like unreal where offsets to these sizes are to get from initial game header, they are still located just before "8C 06"(xcom 2 wotch), e.g: cmp(long) - uncmp(long) - data(starting with and including "8C 06").
Oodle is in fact rather predictable to detect and extract, I made bms script that was able to extract from xcom 2(over 20gb+ data) unreal files error-free without bothering to use their own format to locate those chunks.
To differentiate from fakes, first byte before "8C 06" must be "00" because chunks should never be bigger than 8mb and whole 4byte set before "8C 06" when translated to integer should not exceed 8mb. Thats all.

Well anyway, I hope for this to become as great tool one day as is ztool now. Thank you.

http://fileforums.com/showpost.php?p...8&postcount=64

[darkwolves]

sonic forces repacked from 16 gigs to 8.6 gigs using xtool with srep and uharcmt with it
will be testing other compressors with it as well