XTool 2020 (Main Project)

[Cesar82]

Originally Posted by Razor12911

1) some interesting stuff,
x86: https://www.virustotal.com/gui/file/...296d/detection
x64: https://www.virustotal.com/gui/file/...7dfe/detection

the code is actually the same so I don't know...

2) Yes the issue is also the plugins which also have to shipped with 32-bit version, who still uses 32-bit system anyways?
Attachment 28717

3) Yes, shouldn't be a problem.

I'll ship x86 libraries but any incompatibility issues should fall on the end user.

1) For me it displays "Item not found" message in the virustotal links of your post.
Thank you for the informations.
The false positive does not happen when using Windows Defender. I don't understand why KIS is capturing him. (Just because it's x86 (same source code)... It's like COVID, it reaches the weakest organisms (x86)).

2) I know that few use x86 systems. But because CIU still works on x86 systems it is useful to have x86 compatibility.
Maybe in some time, by default, in the CIU, the "ArchitecturesInstallIn64BitMode=x64" and "ArchitecturesAllowed=x64" configs would limit the CIU to only 64-bit systems so only 64-bit versions of compressors would be needed.
But for now, if possible, I prefer to maintain compatibility.
I know that some plugins/libraries only exist 64-bit versions like the Kraken method that requires oo2core_#_win64.dll (I think there are no 64-bit versions of these libraries).

3) I see in your examples that zlibwapi.dll is always with XTool.
Is this library necessary to be together with XTool in methods other than zlib?
I ask why I want to keep the libraries that it is not mandatory to always be with XTool in a subfolder and depending on the method selected for compression before compressing, a copy of these libraries will be made to XTool. After compressing, these copied libraries will be deleted. In the installer decompressors there will be all libraries used with XTool to compress all Data # .bin that will be extracted by the installer. So I asked the previous question (already answered), if I could have other libraries that were not used in the compression method with XTool when performing the extraction.

Thanks for the great job.

[Razor12911]

1) Yeah a bit unfortunate
2) There are 32-bit versions just that the games usually never ship with them as they are unused and they are 64-bit anyways.
3) As you say "examples", it's just an example that just happen to require zlibwapi.dll if you don't use the method zlib you are not required to include the library

[Cesar82]

@Razor12911
Does XTool 2020 already support the "lz4" and "zstd" methods? Or do you have any limitations for these 2 methods?
If so, is this usage correct in arc.ini?

[External compressor:xtool_lz4]
header    = 0
packcmd   = xtool.exe precomp -mlz4 -c32mb -t100p --dbase - - <stdin> <stdout>
unpackcmd = xtool.exe decode -t100p - - <stdin> <stdout>

[External compressor:xtool_zstd]
header    = 0
packcmd   = xtool.exe precomp -mzstd -c32mb -t100p --dbase - - <stdin> <stdout>
unpackcmd = xtool.exe decode -t100p - - <stdin> <stdout>

@Razor12911, See your inbox.
I will send you a PM with some results using XTool with some samples that KaktoR sent me (Some tests did not inflate).

[Razor12911]

Update Available

Changes

- improved depthing
- updated library support
- fixed zstd codec issues
- removed fast memory

@Cesar82

-mzstd should work now, as for -mlz4. A plugin for that specific game or game engine should be made, the community can send in samples for games and I'll take a look at them if I can add support or not.

[Razor12911]

Update Available

Changes

- updated lz4 codec
- updated library support

[KaktoR]

Thanks for all these informations. Very usefull to us

[Razor12911]

Update available

Changes

- fixed bug depthing (thanks dixen)

[Razor12911]

Update available

Changes

- updated oodle codec (fixed lzna bug)
- added custom method configuration

Notes

Custom method configuration is that xtool.ini file near the executable where you can put all the method which can't be passed directly via Freearc when using {option} feature in arc.ini.

xtool.ini

[CustomMethods]
borderlands3=-mzlib+ue4:m1:k115EE4F8C625C792F37A503308048E79726E512F0BF8D2AD7C4C87BC5947CBA7 -d1
hitman3=-mlz4+hitman3 -d1
nfsheat=-mfrostbite3:nfsheat

if you want to compress borderlands for example, the command line via FA should look like this

arc.exe a -ep1 -r -ed -s; -w.\temp -mxtool:borderlands3 data.arc "pack\*"

xtool will check if the codec exist somewhere in the configuration then if it does it will convert it "-mborderlands3" to whatever is written in the configuration.

This feature was added to help Cesar's DiskSpan GUI project but it can have several uses. If methods become too many, users can add all the methods in xtool.ini so they know what they are for and use them by referring to them by their stored names.

[Cesar82]

@Razor12911, thanks for the new feature.
It will be very useful to include the methods of the plugins, but for the ue4 plugin it is necessary to send the key and parameter -m# because the decryption key can be used for any other game that is not listed.
There will be some changes to the "fcnd" plugin that KaktoR sent me, or it is finished (it was huge)?

[Razor12911]

You can always use SetIniString('CustomMethod','ue4customkey','-mzlib+ue4:m1:some key of a game that is not listed','xtool.ini');, basically you write the key the user has provided and each time use it as -mue4customkey.

as for fcnd, a few things need to be fixed.

[Cesar82]

Originally Posted by Razor12911

You can always use SetIniString('CustomMethod','ue4customkey','-mzlib+ue4:m1:some key of a game that is not listed','xtool.ini');, basically you write the key the user has provided and each time use it as -mue4customkey.

as for fcnd, a few things need to be fixed.

Yes I thought about it (setinistring), but I would have to completely separate the command line for the unreal plugin.
See in the VIDEO how it works on DiskSpan_GUI. It works the same way for ue4dt.

The Arc.ini file was fixed with Zlib.

[External compressor:xtool_ue4]
header    = 0
packcmd   = "PRE\XTool_2020\Win64\XTool.exe" precomp -mzlib+ue4{:option} -c32mb -t100p -d1 --dbase - - <stdin> <stdout>

It may be possible to check the method (s) prior to ue4dt and if it is an XTool 2020 method it could be cut (the previous ones together) and sent to XTool.ini and replaced with the name of the key (as an example ue4method=).

I'll think of something later, but this feature of XTool.ini is very useful.
Should I always use the name XTool.ini or if I rename XTool.exe to XTool_x64.exe should I also rename the INI?

[go2top]

Great work that makes me thrill enough to keep up the good work. If you want to make your brand popular just take service from the Go2Top Panel.

[Razor12911]

Update available

Changes

- updated oodle codec (fixed more lzna bugs)

[Masquerade]

Is there a way to cap memory usage by xtool?

I ask because I have wasted about 5 hours with Project Cars 3 Kraken codec, where it would get to nearly finished precompressing, then shoot up in memory usage completely crashing my PC needing force restart from the reset button on my case. (Bear in mind this is with xtool capped at only 6 threads of CPU, so memory usage isn't too bad anyway). Oodlerec is terribly slow.

Same thing happens with American/Euro Truck Simulator, in those cases I have no choice to use a chunk size of 8mb otherwise my PC just crashes.

Thanks!

Edit: I get past this just by swapping STDIO for $$arcdatafile$$.tmp $$arcpackedfile$$.tmp - seems good!

[Razor12911]

Update available

Changes

- updated library structure