-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I wrote a new loader without remote memory injection #56
Comments
The idea may be good, but it doesn't work on my ru client |
I built it on Turtle WoW. |
This is a regular 1.12 client, only patched (unrestricted mode) for loading ruRU resources. |
That's sounds like sideload-DLL.dll not loaded. You sure sideload-DLL.dll is also at the same folder with WoW_sideload-DLL.exe right? |
Thanks, I'll have a look, I'm downloading that RU client. Maybe the RU .exe is different than English client. |
np, vanillafixes injector works for me, it's just a remark |
@shikulja I got some bugs fixed. Could you try https://github.com/allfoxwy/vanilla-dll-sideloader/releases/latest see if it works? The Turtle EU client was so perfectly aligned so that those bugs didn't expose. |
@allfoxwy now works, thanks. |
Added customized DLL loading code. |
After I listen to Ayriana's words from turtle discord. I decided re-open this issue for a bit longer time. I believe my loader has following advantage:
Would you consider have a look or maybe adapt it? |
it can load .dll files according to the pattern, but cannot load from the subdirectory in which the .dll+lua project is located |
Yes Ayriana on discord asking me to make a text file to direct loading process now. |
I considered the option of modifying WoW.exe for VanillaFixes but decided against it because some servers kick you if you have a modified game executable. You can get around this by renaming it to something else and keeping WoW.exe in the same folder but I think this would make VanillaFixes harder to use. If you use something like vanilla-tweaks on top it can get even more confusing.
This also seems out of scope for VanillaFixes. It would be better suited for a generic modding framework for the game, where you could load VanillaFixes on top. Basically, the launcher is just there to get VanillaFixes loaded, and it's supposed to be as easy as possible to use. I added the option to load other DLLs because otherwise it can conflict with e.g. nampower. I explained this in the readme:
|
I can rename the DLL if necessary but this would have to be done for all other DLLs like nampower.dll, SuperWoWhook.dll, etc. Maybe it would be better if you loaded DLLs from a "mods" folder or from a text file like VanillaFixes? This code should work without any changes: https://github.com/hannesmann/vanillafixes/blob/main/src/textfile.c |
My loader won't work with nampower. Yes that one is special.
I received some words from Discord also suggest text file is better (could have comments). So no need adapt file name to my loader, I would see if I could adapt your implementation.
That's a big idea. I think need some time to come up a more complete plan like this. |
I adapted textfile.c . Now both loader works the same way. (I used to load mod from working folder, now I follow VanillaFixes, using wow base folder either) I would leave this issue open, in case we back on this topic or you need reach me. |
FYI https://github.com/allfoxwy/vanilla-dll-sideloader/releases/latest
It works by modify PE import directory, not by remote memory injection. Should calm some security software complain.
The text was updated successfully, but these errors were encountered: