XTool 2020 (Main Project)

[ozolt]

Originally Posted by Razor12911

I'll add "+" as a resource string and if you want to change it as a user, you'd have to do it yourself. in the next update, that is

Thank you very much If I can make a small comment, isn't resource string editing "overkill"? I mean, simple "-mzlib,reflate" syntax is all that is needed...(currently, only possible is, for example, -mzlib+reflate)

Anyway, thanks again,
regards

[Razor12911]

Originally Posted by Gupta

> Turns out the issue was caused by this
https://community.idera.com/develope...ream-2gb-limit

because of these obscure bugs, I didn't continue with Delphi, especially ide is shit compared with other. You're still holding grounds nice work

Well I mostly evade the bugs by just sticking to WinAPI functions and a few times by using System functions but then with these I usually have to write custom code that do the same thing just that the one Delphi has is crap.

Originally Posted by ozolt

Thank you very much If I can make a small comment, isn't resource string editing "overkill"? I mean, simple "-mzlib,reflate" syntax is all that is needed...(currently, only possible is, for example, -mzlib+reflate)

Anyway, thanks again,
regards

the problem is commas are used for something else

example -mzlib:l98,w15+kraken:l9:t128...

if we replace + with , then syntax will look like this -mzlib:l98,w15,kraken:l9,t128..
zlib will start considering everything as one of its parameters.

Edit:

This is what you need to change via Resource Hacker in xtool.exe

[ozolt]

Originally Posted by Razor12911

if we replace + with , then syntax will look like this -mzlib:l98,w15,kraken:l9,t128..
zlib will start considering everything as one of its parameters.

I understand now and I agree comma is not a good choice, but how about & or # sign?...I never asked for , specifically, it does not matter as long as it is not +

Anyway, it is just a suggestion, ResourceHacker editing is not a problem, changed to & and it is working great (it's even more logical to me with & sign) ...
Thank you very much for your work,regards

[Masquerade]

Greetings Razor

Does the Dunia codec support for Far Cry Primal?

I haven't seen any mention of it here or on the DELZOREC thread on krinkels.org.

I tried using DELZOREC on the HD Texture file, but it certainly didn't work (3GB file somehow unpacked to 1GB).

If anything needs testing, I can upload some small samples. If there's a way you could show me to see what kind of compression is already on the files, that would also be appreciated.

[Gupta]

> Turns out the issue was caused by this
https://community.idera.com/develope...ream-2gb-limit

because of these obscure bugs, I didn't continue with Delphi, especially ide is shit compared with other. You're still holding grounds nice work :)

[Razor12911]

Update available

Changes

- updated search/config support

Notes

You can now use database files (*.xtl) posted in this thread to precompress games which the program does not have a native support for.

An example is Far Cry 5, the game is lz4 compressed and as there is no universal scanner for these streams, you can use a generated database to precompress the game.

Results on farcry5.dat:

Tested 1 file, 16,292,024,225 => 11,422,856,623 bytes. Ratio 142.63%
Testing time: cpu 11.25 sec/real 111.17 sec = 10%. Speed 102.75 mB/s

[dixen]

Tested FC5 *.dat with XTool R4 and...It closed on 10-20%

5.5%
ERROR: write error (disk full?) in compression algorithm xt20

[Razor12911]

Well it's not like I didn't say something was wrong and fixed it in the next release...

[dixen]

But...If tested without SREP or LOLZ - ALL fine unpacked and XT20 process used about 300-400 mb RAM.
UPD. XT20(R5) + SREP = same bug

[Razor12911]

try unpacking with temps (disable cls/stdio), maybe we can see what is causing the problem.

Edit: I may need to make cls of xtool perhaps just to avoid issues.

[dixen]

Originally Posted by Razor12911

try unpacking with temps (disable cls/stdio), maybe we can see what is causing the problem.

Edit: I may need to make cls of xtool perhaps just to avoid issues.

20 gb data.arc - same bug.

OFF stdin/stdout - in progress

UPD

[External compressor:xt20]
header = 0
unpackcmd = xtool decode -t100p --mem=75p --dedup=FC.bin $$arcpackedfile$$.tmp $$arcdatafile$$.tmp

With this parameters - same bug - xtool is closed on 2.5-2.7 gb RAM
R4 or R5 - no matter..
Offensively

[Razor12911]

could you try without deduplication, too many points where an error could occur.

[dixen]

Originally Posted by Razor12911

could you try without deduplication, too many points where an error could occur.

Of course...waiting
UPD.
Yes without dedup - the test was completed successfully and xt used about 500-600 mb RAM (XT20 R5)

Tested 11 files, 20,205,910,501 => 21,896,534,144 bytes. Ratio 92.28%
Testing time: cpu 68.59 sec/real 365.42 sec = 19%. Speed 59.92 mB/s
All OK

[ZiLATAN]

Can anyone give me the download link of SREP, LZMA/Lolz Please?

[dixen]

Originally Posted by ZiLATAN

Can anyone give me the download link of SREP, LZMA/Lolz Please?

https://fileforums.com/showthread.php?t=104866