XTool 2020 (Main Project)

[Cesar82]

Originally Posted by Razor12911

I don't know if I said it here on the forum or to someone who asked for 32-bit version of xtool. I stopped shipping 32-bit xtool because there are certain mistakes that some people make when they use xtool. An example is when they use oodle/lz4. The library you use must be compiled from the same source code, this you must make sure (if the 64-bit dll of lz4 is v191, make sure the 32-bit dll is also v191). So what happens is people use 64-bit version of the library and then ship the 32-bit version of xtool along with different libraries making xtool to cause CRC errors because the libraries didn't come from the same source. 32-bit is available on request but it will be the users fault if they have issues with it. What you also must remember is xtool ships with xdelta, some streams cannot be restored so it tries to salvage a few streams but if there is a mismatch in the data caused by different dll, it causes xtool/xdelta to return errors.



Relax I backtrack posts when I return and answer all of them when I have time, I did say that I spend less time here and sometimes what happens is if a question is directed at someone, if they are not around and other people don't step in, it still falls behind and the question is still never seen (especially with threads). So I think he did what was best by giving a response right away best he can according to his knowledge.

Thanks for the quick response.

If I understand correctly, users compress a game with a library version and try to extract it with another.
But can't this happen with only the 64-bit version of XTool (Compressing with XTool X and trying to extract with XTool version Y)?
You always share the libraries together with XTool, so you should logically use them to decompress.

My idea was to update XTool on CIU so I decided to ask.
Now in CIU the libraries and decompressors are no longer included in the setup.exe, being added when the game is deleted in an external file, thus avoiding a bit of using different versions of the DLL and exes for extraction.

You said always go back on the posts and respond.
You ciu this question referring to ue4dt in the post HERE.

Can I have specific plug-in files for a game like "oo2ext_7_win64.dll / cp2077.ini" inside the XTool folder when using other methods?
If I want to include several plugins (specific files needed for a particular game) I can put them all in a folder with XTool and in the files for decompression do not include these files, or they must also be together in the extraction, even if it is specific to another method ? Of course, if the libraries in the "Libraries" folder shared with XTool exist alongside XTool in compression, must be together in decompression.

[Razor12911]

Originally Posted by Cesar82

Thanks for the quick response.

If I understand correctly, users compress a game with a library version and try to extract it with another.
But can't this happen with only the 64-bit version of XTool (Compressing with XTool X and trying to extract with XTool version Y)?
You always share the libraries together with XTool, so you should logically use them to decompress.

No you don't understand. The libraries have versions of their own. What I am saying is, if you used 64-bit version of xtool.exe and liblz4.dll when encoding. Repackers and other users have that thing of putting xtool.exe (x86) this is not a problem since xtool x86 and x64 are usually compatible with each other, the problem is then the liblz4.dll, users just look for any x86 liblz4.dll just because they want it to work with xtool.exe x86 even when liblz4.dll x86 and liblz4.dll are not the same version. Almost each version of liblz4.dll produces a different result when its used which causes crc errors for xtool.

You said always go back on the posts and respond.
You ciu this question referring to ue4dt in the post HERE.

This is user error, someone tried to help you solve this issue in the next post.
https://www.fileforums.com/showpost....2&postcount=77
therefore I didn't intervene.
-mue4dt:-m1:-k0x115EE4F8C625C792F37A503308048E79726E512F0BF8D2A D7C4C87BC5947CBA7+xzlib+srep:m3f+4x4:lzma+diskspan :4420mb:4470mb
the problem here is simple, you added -mue4dt:-m1:-k0x...

I don't know if that was the issue or with the program itself.

Can I have specific plug-in files for a game like "oo2ext_7_win64.dll / cp2077.ini" inside the XTool folder when using other methods?
If I want to include several plugins (specific files needed for a particular game) I can put them all in a folder with XTool and in the files for decompression do not include these files, or they must also be together in the extraction, even if it is specific to another method ? Of course, if the libraries in the "Libraries" folder shared with XTool exist alongside XTool in compression, must be together in decompression.

not sure if I follow but you can probably do that, add several plugins. Even if they are not inuse. Or tell users to copy and paste the plugin info (ini) to a static file that you will use.
For example you can just make a custom configuration file, like extmethod.ini in your tools or CIU.
If a user wanted to use a certain plugin, instead of copying cp2077.ini, they can just copy its contents to extmethod.ini. this is also allowed. You can put in as many methods in there as you want but they must follow the standard ini section. [Stream1] ... [Stream2]... and etc. These configuration files as I mentioned are not required for decoding.

Remember, placing oo2ext_7_win64.dll as an example. This means xtool will use that library for everything oodle related so if your question was, can you make a folder which xtool will read cp2077 where there will be (oo2ext_7_win64.dll and cp2077.ini) and another game tc2 which uses (oo2ext_5_win64.dll and tc2.ini), xtool will use oo2ext_5_win64.dll for all of them.

[Cesar82]

Originally Posted by Razor12911

No you don't understand. The libraries have versions of their own. What I am saying is, if you used 64-bit version of xtool.exe and liblz4.dll when encoding. Repackers and other users have that thing of putting xtool.exe (x86) this is not a problem since xtool x86 and x64 are usually compatible with each other, the problem is then the liblz4.dll, users just look for any x86 liblz4.dll just because they want it to work with xtool.exe x86 even when liblz4.dll x86 and liblz4.dll are not the same version. Almost each version of liblz4.dll produces a different result when its used which causes crc errors for xtool.

But you usually share the libraries with XTool.
So if any user is going to replace Xtool with XTool x86 they must also replace the libraries with the libraries that come with XTool x86 (In the file you shared from xtool x86).

Originally Posted by Razor12911

the problem here is simple, you added -mue4dt:-m1:-k0x...

I cannot include "-" in the parameter.
So that must be the mistake. I'll check it out and send it to KaktoR to test it, but I think that's what happened. Thanks!
I did not pay attention to the user's Masquerade response. If he had highlighted the "-" he would have noticed.
It's even generating the wrong method on the DiskSpan_GUI that I created...

Originally Posted by Razor12911

not sure if I follow but you can probably do that, add several plugins. Even if they are not inuse. Or tell users to copy and paste the plugin info (ini) to a static file that you will use.
For example you can just make a custom configuration file, like extmethod.ini in your tools or CIU.
If a user wanted to use a certain plugin, instead of copying cp2077.ini, they can just copy its contents to extmethod.ini. this is also allowed. You can put in as many methods in there as you want but they must follow the standard ini section. [Stream1] ... [Stream2]... and etc. These configuration files as I mentioned are not required for decoding.

Remember, placing oo2ext_7_win64.dll as an example. This means xtool will use that library for everything oodle related so if your question was, can you make a folder which xtool will read cp2077 where there will be (oo2ext_7_win64.dll and cp2077.ini) and another game tc2 which uses (oo2ext_5_win64.dll and tc2.ini), xtool will use oo2ext_5_win64.dll for all of them.

So the ideal would be to put just XTool and the common libraries, and put the plugins in separate folders and create copies of these plugins to the XTool folder when initializing the compression and deleting after completion.

Perhaps a configuration file with a path for additional plugins would be a idea.
Example: Use an XTool.ini file and place keys such as Path1=Plugin1, Path2=Plugin2, etc.
When starting XTool, not only load libraries and files that are in the XTool path, but also check and load the subfolders with those paths.
The scan of the keys would have to be checked as long as the key Path#= exists, and not if it is empty because to disable a plugin it would only be necessary to pass an empty value to key path#=. This is only an idea if it doesn't hinder the performance of XTool.

[Ele]

Originally Posted by Razor12911

The libraries have versions of their own. What I am saying is, if you used 64-bit version of xtool.exe and liblz4.dll when encoding. Repackers and other users have that thing of putting xtool.exe (x86) this is not a problem since xtool x86 and x64 are usually compatible with each other, the problem is then the liblz4.dll, users just look for any x86 liblz4.dll just because they want it to work with xtool.exe x86 even when liblz4.dll x86 and liblz4.dll are not the same version. Almost each version of liblz4.dll produces a different result when its used which causes crc errors for xtool.

Razor12911, Thank you for the information.
It's very important to know because I've faced this situation before. It took a long time to find the cause of the CRC error. But I failed.