- Joined
- May 6, 2013
- Messages
- 125
Well, i made this Hack a good while ago that would skip the creation of specific files when there was no need to recreate it in order so reduce the time needed to save maps. It was fully written in assembler, which certainly had a negative impact on its structure. In fact, i had problems to understand what i did there myself. And as i got myself a new cpu (boosted the time i needed to save my map from a sloppy 40 seconds to a whooping 10 seconds) i stopped working on it.
For some weird reason that i can not point to by myself, i recently got the idea to remake this hack; but this time encapsulating the important code parts in a c++ dll, to both get rid of cheat engine (which i originally made this hack with) and to tidy up the code.
Setting things up:
Download the attached .zip file and put the 3 files wherever you want them to be; however, the .exe and the .txt files have to be in the same folder, and the .txt file must not be renamed (Its name is Dllpath.txt).
Then, into the Dllpath.txt, write the full absolute path to the dll that came with this download.
To activate the hack:
(note: You need to do this every time you want to use the hack). Start the world editor, THEN start the executable that came with this zip file. A console that could really use some grammar lessons will pop up to inform you about the injection process and to tell if it failed or succeeded.
This hack does not need admin rights as long as the world editor it is attempting to hack was not started with admin rights. However, if you started the world editor with admin rights, you need to start the hack with admin rights as well, or the injection will fail.
Once it is activated, you should see a new menu item in the world editors main windows menu bar named "Save Settings". Clicking on this button will open up a window where you can activate and deactivate single hacks.
WARNING: You should have extreme caution with using the Mapscript-doo hack. The reason for this is simple: i do not know what this buildstep does. I know that it's part of the map script build (war3map.j), and its description states that its saving doodads. However, i do not know of anything doodad-related in a mapscript, nor did i see this thing do anything in any of the maps i've tested. What i do however know is that it loops through every single doodad on the map, consequently wasting a lot of time for a step that seems to do nothing at all. I've asked (even on this very forum) what the step does, but nobody seems to know. My personal idea that i got just in this second that i'm writing this is that its saving the drop table triggers, which seems pretty reasonable to me, and makes me wonder why i got this idea just now. I guess, don't use it when your doodads drop items. Thats also why it's turned off by default.
So, what is this hack about?
Short answer: it attempts to reduce the time that the world editor needs to save a map.
Long answer: to do so, it checks certain flags that the world editor keeps (but doesn't really use for anything) to determine whether a certain file has to be rebuild (such as a doo file) or not, and if not, copies an old version from the mpq. It also supports some special methods.
Does this hack patch the world editor?
No. This file does not touch any of warcraft 3s files, or any file for that matter. Its a pure memory-hack; you have to activate it whenever you start the world editor, and it will only affect this world editor instance that ran while you activated the hack.
Does this hack contain viruses?
Sure. Name it, this hack has it.
No, really. This package does not contain any viruses i'm aware of. So, unless i have a virus that infected my Visual Studio 2012 installation or 7zip that antivir can not detect, there are surely no viruses in here. And unlike JNGP, my antivir also doesn't complain about it.
If you want, i can upload the project, and everybody with visual studio 2012 can compile it themselves while gazing at the mess that i call source.
The Injection fails with the message "Could not find a process whose executable is named worldedit.exe"
This can have 3 different causes:
1: make sure the world editors executable is actually named "worldedit.exe" and was not renamed to something else
2: you forgot to start the world editor at all.
3: you started the world editor with admin rights, but not the hacks exe.
The Injection fails with the message "Could not load Library (126)"
Make sure that the Dllpath.txt contains the absolute path to the dll.
What does "Warning: not all Token Privileges could be assigned. The injection may fail." mean?
In essence, i am a little greedy here and actually request more privileges than i actually need (mainly because i don't even know what privileges i do need.) You can usually ignore this message, as other messages will pop up if things get critical.
What does "Successfully injected!" mean?
That you're a moron for actually looking at the answer of this question.
Why the heck do i have to enter actual text to end the application?
Because i was lazy and used cin.get() ._.
Why are some of the options greyed out?
Short answer: Because i either dont know when to skip these, or i feel like its not saving any time to skip them
Long answer: the save function is structured pretty simple, essentially a list of calls, each of which builds a specific file. I identified which call does what before i even thought about how to skip them. So, i ended up with stub-injections for files, only to figure out that i either don't know which flag i should look on (when does a shadow map change? when the terrain changes? or the doodads on it?), or feel like its not worth skipping them (the path map for instance has a constant complexity anyways); and of course, files from which i don't even know what they do (like the txt file.) So, i just greyed those options out to indicate that there is in fact the possibility to skip them, but i didn't implement it.
So, what do the two buffering injections do?
They 'buffer' the jass-text (and its wtg-file binary data, respectively) that a GUI trigger converts into the next time you save your map. On the second save, it checks whether the trigger has changed, and if not, uses the buffered text instead of letting the world editor convert the gui trigger once again. This can save quite some time on maps with a lot of gui triggers.
Is this hack compatible with JNGP?
Short answer: no
Long answer: JNGP, for some reason that is beyond me, still uses a old version of the world editor (if i had to take a guess, the one shipped with wc patch 1.21. why this number? wild guess. wild guess.). I believe they never saw the need to make it compatible with a newer version as most functions are completely redone anyways, and nobody gives a flying beep about the poor gui hashtable users anyway. However, as this is essentially still an assembler-based hack, it is highly depended on the inner structure of the executable it was written for; and since i never used JNGP, that is the NEW version of the world editor.
I'm not sure how many features the world editor version that JNGP relies on is lacking internally, but depending on how things turn out, porting this hack to the old world editor used by JNGP might be somewhere between very easy and impossible. I might give it a try if people want it, though.
Tell me what you think about it. Does it work for you? Is there any lengthy part about saving your map that this hack cannot skip? Would you be interested in a JNGP-(read: 1.21-)compatible version?
Any feedback is greatly appreciated
edit: wow, i forgot to attach the god damned zip
For some weird reason that i can not point to by myself, i recently got the idea to remake this hack; but this time encapsulating the important code parts in a c++ dll, to both get rid of cheat engine (which i originally made this hack with) and to tidy up the code.
Setting things up:
Download the attached .zip file and put the 3 files wherever you want them to be; however, the .exe and the .txt files have to be in the same folder, and the .txt file must not be renamed (Its name is Dllpath.txt).
Then, into the Dllpath.txt, write the full absolute path to the dll that came with this download.
To activate the hack:
(note: You need to do this every time you want to use the hack). Start the world editor, THEN start the executable that came with this zip file. A console that could really use some grammar lessons will pop up to inform you about the injection process and to tell if it failed or succeeded.
This hack does not need admin rights as long as the world editor it is attempting to hack was not started with admin rights. However, if you started the world editor with admin rights, you need to start the hack with admin rights as well, or the injection will fail.
Once it is activated, you should see a new menu item in the world editors main windows menu bar named "Save Settings". Clicking on this button will open up a window where you can activate and deactivate single hacks.
WARNING: You should have extreme caution with using the Mapscript-doo hack. The reason for this is simple: i do not know what this buildstep does. I know that it's part of the map script build (war3map.j), and its description states that its saving doodads. However, i do not know of anything doodad-related in a mapscript, nor did i see this thing do anything in any of the maps i've tested. What i do however know is that it loops through every single doodad on the map, consequently wasting a lot of time for a step that seems to do nothing at all. I've asked (even on this very forum) what the step does, but nobody seems to know. My personal idea that i got just in this second that i'm writing this is that its saving the drop table triggers, which seems pretty reasonable to me, and makes me wonder why i got this idea just now. I guess, don't use it when your doodads drop items. Thats also why it's turned off by default.
So, what is this hack about?
Short answer: it attempts to reduce the time that the world editor needs to save a map.
Long answer: to do so, it checks certain flags that the world editor keeps (but doesn't really use for anything) to determine whether a certain file has to be rebuild (such as a doo file) or not, and if not, copies an old version from the mpq. It also supports some special methods.
Does this hack patch the world editor?
No. This file does not touch any of warcraft 3s files, or any file for that matter. Its a pure memory-hack; you have to activate it whenever you start the world editor, and it will only affect this world editor instance that ran while you activated the hack.
Does this hack contain viruses?
Sure. Name it, this hack has it.
No, really. This package does not contain any viruses i'm aware of. So, unless i have a virus that infected my Visual Studio 2012 installation or 7zip that antivir can not detect, there are surely no viruses in here. And unlike JNGP, my antivir also doesn't complain about it.
If you want, i can upload the project, and everybody with visual studio 2012 can compile it themselves while gazing at the mess that i call source.
The Injection fails with the message "Could not find a process whose executable is named worldedit.exe"
This can have 3 different causes:
1: make sure the world editors executable is actually named "worldedit.exe" and was not renamed to something else
2: you forgot to start the world editor at all.
3: you started the world editor with admin rights, but not the hacks exe.
The Injection fails with the message "Could not load Library (126)"
Make sure that the Dllpath.txt contains the absolute path to the dll.
What does "Warning: not all Token Privileges could be assigned. The injection may fail." mean?
In essence, i am a little greedy here and actually request more privileges than i actually need (mainly because i don't even know what privileges i do need.) You can usually ignore this message, as other messages will pop up if things get critical.
What does "Successfully injected!" mean?
That you're a moron for actually looking at the answer of this question.
Why the heck do i have to enter actual text to end the application?
Because i was lazy and used cin.get() ._.
Why are some of the options greyed out?
Short answer: Because i either dont know when to skip these, or i feel like its not saving any time to skip them
Long answer: the save function is structured pretty simple, essentially a list of calls, each of which builds a specific file. I identified which call does what before i even thought about how to skip them. So, i ended up with stub-injections for files, only to figure out that i either don't know which flag i should look on (when does a shadow map change? when the terrain changes? or the doodads on it?), or feel like its not worth skipping them (the path map for instance has a constant complexity anyways); and of course, files from which i don't even know what they do (like the txt file.) So, i just greyed those options out to indicate that there is in fact the possibility to skip them, but i didn't implement it.
So, what do the two buffering injections do?
They 'buffer' the jass-text (and its wtg-file binary data, respectively) that a GUI trigger converts into the next time you save your map. On the second save, it checks whether the trigger has changed, and if not, uses the buffered text instead of letting the world editor convert the gui trigger once again. This can save quite some time on maps with a lot of gui triggers.
Is this hack compatible with JNGP?
Short answer: no
Long answer: JNGP, for some reason that is beyond me, still uses a old version of the world editor (if i had to take a guess, the one shipped with wc patch 1.21. why this number? wild guess. wild guess.). I believe they never saw the need to make it compatible with a newer version as most functions are completely redone anyways, and nobody gives a flying beep about the poor gui hashtable users anyway. However, as this is essentially still an assembler-based hack, it is highly depended on the inner structure of the executable it was written for; and since i never used JNGP, that is the NEW version of the world editor.
I'm not sure how many features the world editor version that JNGP relies on is lacking internally, but depending on how things turn out, porting this hack to the old world editor used by JNGP might be somewhere between very easy and impossible. I might give it a try if people want it, though.
Tell me what you think about it. Does it work for you? Is there any lengthy part about saving your map that this hack cannot skip? Would you be interested in a JNGP-(read: 1.21-)compatible version?
Any feedback is greatly appreciated
edit: wow, i forgot to attach the god damned zip
