Quote:
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).
Quote:
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...
Quote:
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.