FileForums
Page 2 of 39 1 2 3412 Last »
Show 40 post(s) from this thread on one page

FileForums (https://fileforums.com/index.php)
-   Conversion Tutorials (https://fileforums.com/forumdisplay.php?f=55)
-   -   XTool - Successor of ZTool (https://fileforums.com/showthread.php?t=101729)

ZakirAhmad 16-04-2018 09:47
Tried it on a file from mass effect 3, precomp042 precompresses better than xtool on it.

Simorq 16-04-2018 10:04
Quote:
Originally Posted by Webster17 (Post 470254)
Cons:
Installer freezes if aborted, just like pzlib3. You have to close the xtool process from task manager.
Use TaskKill
Code:
Exec(ExpandConstant('{sys}\taskkill.exe'), ' /F /IM XTool.exe', '', SW_HIDE, ewNoWait, ResultCode);

Sergey3695 16-04-2018 11:28
When packed file more 4 gb
http://i104.fastpic.ru/big/2018/0416...ca106f6399.jpg

Razor12911 16-04-2018 15:10
Quote:
Originally Posted by doofoo24 (Post 470228)
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

Quote:
Originally Posted by Sergey3695 (Post 470262)
Probably some bug, will look at it, found more bugs while working on the Naruto series

Quote:
Originally Posted by ZakirAhmad (Post 470258)
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 16-04-2018 18:53
ofcourse i will send u the file.

darkwolves 17-04-2018 00:13
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- 17-04-2018 09:22
x64 xtool shows DiskFull
x86 is working

Gupta 17-04-2018 10:21
X32:

Code:

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:

Code:

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 17-04-2018 10:49
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 17-04-2018 10:57
why do you think i haven't tried it?

darkwolves 17-04-2018 11:59
trying xtool with uharcmt it seems to be working pretty well

Razor12911 17-04-2018 15:05
I'll take a look at x64 issue

elit 17-04-2018 17:14
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 17-04-2018 17:49
Quote:
Originally Posted by elit (Post 470326)
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 17-04-2018 19:32
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


All times are GMT -7. The time now is 04:53.
Page 2 of 39 1 2 3412 Last »
Show 40 post(s) from this thread on one page

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
FileForums @ https://fileforums.com