Quote:
Originally Posted by elit
You may want to be interested in this.
I was trying to inflate cpk file from Diablo 3 from nintendo switch. Normaly these are crilayla but gfs detected lz. So I tried old ztool, some older xtool(date modified says 26.april 2019) and xtool2009R3.
For reference I tried single file "Act1.cpk" of 814mb size. GFS detected potential of inflation of up to ~1800mb.
Ztool could not inflate past few 10's of mb if any, regardless of setting like m2, m3 etc.
Later xtool2009R3 depended on codec, most were at about 100mb extra only, except reflate which did go to 1.1gb. However final packed size after srep+xlzma was about same which make me think of possible huge overheat?
Finally, that older xtool with :high setting was able to inflate to.. 1.7gb!!
I tried to compress that and got about ~40mb better compression.
General final compression after codecs was around 740mb+, this one went to ~704mb. I wonder if this was real inflated data to 1.7gb or too much overheat. I must also say that older xtool was able to do it only with :high option which unlike ztool is not even know or documented and probably unofficial. Also it took very long time compare to say ztool:high, it seems to work differently.
I have uploaded the file act1.cpk for further research if you are interested:
https://megaup.net/1zEg1/Act1.cpk |
"File not found"
btw, remember how this xtool works. Everything is decided by the user, before when you used zlib in the older xtool and ztool, if reflate library were nearby, it would use them so perhaps you need to combine zlib and reflate to get the desired output.
Quote:
Originally Posted by Masquerade
Having a few problems decompressing with the fcp option, I have tried a few different unpackcmds:
Code:
[External compressor: fcp]
header = 0
unpackcmd = xtool decode --dbase=fcp.xtl - - <stdin> <stdout>
Code:
[External compressor: fcp]
header = 0
unpackcmd = xtool decode - - <stdin> <stdout>
Code:
[External compressor: fcp]
header = 0
unpackcmd = xtool decode -mfcp - - <stdin> <stdout>
Yes, fcp.xtl and liblz4.dll are with xtool.exe
Errors like:
Code:
G:\Games\_Compressor>aarc x __test.msq
FreeArc 0.67 (March 15 2014) extracting archive: __test.msq
Extracting 1 file, 46,201,655 bytes. Processed 0%
ERROR: general (de)compression error in fcp
G:\Games\_Compressor>aarc x __test.msq
FreeArc 0.67 (March 15 2014) extracting archive: __test.msq
Extracting 1 file, 46,201,655 bytes. Processed 0%
ERROR: general (de)compression error in fcp
G:\Games\_Compressor>aarc x __test.msq
FreeArc 0.67 (March 15 2014) extracting archive: __test.msq
Extracting 1 file, 46,201,655 bytes. Processed 0%
ERROR: write error (disk full?) in compression algorithm fcp
This is just on 1 file with no extra compressors.
Is there something wrong with my unpackcmd? |
All issues related to libdunia will be fixed via a separate plugin of xtool
Quote:
Originally Posted by elit
In fact you already completed the work, why abandon it? So for the love of god I beg you, put it back in latest version!
PS(Zstd and lz4 are temporary and will stop working after time because of their retarded design. Not sure about lzo(that is actually a question, why is standard lzo not working in dunia and unreal engines and need special treatment? I thought its a stable design like zlib?). But crilayla, lzss, yaz0 and such should remain compatible.
|
I temporarily removed crilayla because I wanted to have a reworked 64-bit version via plugin support, not many games use it so it shouldn't ship with xtool. Oodle, zlib, lz4 and etc, these algorithms are common therefore they ship with xtool, anything else will be a plugin.
Quote:
Originally Posted by elit
-grittibanzli inflate completely randomly. Sometimes tested 20mb inflated zip file is 34mb, other times 31.6mb, another time 33mb atd. exactly same setting and just repeating same command on console.
-zlib codec did not inflated zip file at all!(I thought it was supposed to handle deflate?)
-preflate and reflate both did to same ~27mb, but preflate took ~6sec while reflate did it in ~1sec.
Looks like good old reflate is still the best zlib codec to stick.
EDIT(and ztool is also able to inflate to 27mb without :high or :m2 !) <<UPDATE(BS, scrap that claim, need m2 or high indeed)
EDIT2(ok I checked manual again and learned about zlib+reflate combination benefits. Maybe this is best way. It took ~3sec compared to ~1sec on deflate alone though. Not sure how big those benefits are in real application yet.)
EDIT3(have to explicitly state 'mb' in -c option instead of just 'm', e.g. -c128m vs -c128mb. No big deal but used to ztool, was more flexible. PS: I am really liking the idea of zlib+reflate in one go, before I used to pass twice in test to find out which one to use.)
|
zlib is the first codec that tries to process streams, if you mixed the methods zlib+reflate... if zlib fails, it gives it to reflate to try processing it.
Quote:
Originally Posted by Ele
Mr. Razor
Is lz4, lzo and zstd still not supported for xtool 2020?
|
lz4 and zstd are in xtool but lz4 is just a placeholder for now, lzo will be added as a placeholder too.