- Joined
- May 6, 2013
- Messages
- 125
Hi again, I'm back with weird questions that probably nobody expected to read.
And again, its about my save-only-new-stuff hack, which by now, skips the entire creation of some files (doo, Units.doo, region file, camera file, etc.etc.)
Well, while the skipping the doo file seems to save quite a lot of time, i noticed that the next huge portion of time in the saving action is the creation of the Triggers (wtg and wtc file), and for obvious reasons, i can not just skip the entire creation of this file. So, my first impulse was to cache saved triggers and, when saved the next time, paste the cache instead of letting the WE generate the triggers part in the wtg file again. (caching custom text triggers seems kind of useless as they allready are there in plain text and the we practically only copies them into the wtc file.)
This is obviously bringing up the question where to save those caches:
- allocating a char* array listing those caches would require me to go through the list with O(n) and do string comparisions to find which trigger they belong to for every trigger, which means i have O(n^2) in total, which kind of defeats the purpose of the actual hack
- implementing a search tree, or even worse, a hashtable, which is not a trivial task in C already, not to mention that I'm using assembler here, while still beeing forced to to strcmps
- putting the buffer pointer into blizzards trigger structs. I already found the destructor of these structs, so making the destructor delete my buffer too and defeating the leak issue is a trivial task to do once i actually added the buffer somewhere in there.
By the looks of it, it seems to me that the third method is the best one (if you have a better idea, i'd be glad to hear it
), but it's bringing up another question, which is where to actually put this pointer.
- Enlarging blizzards struct could be possible if i found the constructor, but as most of them are created at startup of the world editor / loading of the map, it would require me to activate the hack before loading, which is a mean restriction; i will also have hard times checking if it was loaded at the correct time and it might kill existing blizzard code (e.g. arrays of this struct will fail if the struct is 5 bytes larger)
- Finding a cave in the trigger, which finally brings us to the actual reason why im here:
where should i place that pointer? Ideas i had:
- Using the flag that tells whether this trigger has been changed. It would, however, require me to hack every single place in the code where this flag is changed to avoid leaking the buffer
- I could try to use the Custom-Text-Trigger-Flag, as i know that it can only be changed on two places (convert to custom text and str+z), but i don't know if changing this flag to a pointer might screw up other routines of the world editor (besides the save routine, obviously)
- The Triggers name is 80 signs long. However, after this buffer, there are a lot of 0's that also don't seem to be accessed by anything i do; the next seemingly used values are 260 bytes after the buffer starts (some pointer, followed by the map description, which is 2048 bytes long and does NOT have such a seemingly empty buffer after it). Can it be that this empty space is the result of the compilers data structure alignment and therefor a safe place to use?
- using one of those thousands of flags whose purpose i don't know and which don't seem to have any use as they are constantly written into, but never read out (unless im missing something here, which is probably the case)
So, does anybody know better potential places to store the pointer into? Where would you put it? Is it save to use that seemingly empty buffer after the trigger name?
(ps: if you actually read the whole post: respect)
And again, its about my save-only-new-stuff hack, which by now, skips the entire creation of some files (doo, Units.doo, region file, camera file, etc.etc.)
Well, while the skipping the doo file seems to save quite a lot of time, i noticed that the next huge portion of time in the saving action is the creation of the Triggers (wtg and wtc file), and for obvious reasons, i can not just skip the entire creation of this file. So, my first impulse was to cache saved triggers and, when saved the next time, paste the cache instead of letting the WE generate the triggers part in the wtg file again. (caching custom text triggers seems kind of useless as they allready are there in plain text and the we practically only copies them into the wtc file.)
This is obviously bringing up the question where to save those caches:
- allocating a char* array listing those caches would require me to go through the list with O(n) and do string comparisions to find which trigger they belong to for every trigger, which means i have O(n^2) in total, which kind of defeats the purpose of the actual hack
- implementing a search tree, or even worse, a hashtable, which is not a trivial task in C already, not to mention that I'm using assembler here, while still beeing forced to to strcmps
- putting the buffer pointer into blizzards trigger structs. I already found the destructor of these structs, so making the destructor delete my buffer too and defeating the leak issue is a trivial task to do once i actually added the buffer somewhere in there.
By the looks of it, it seems to me that the third method is the best one (if you have a better idea, i'd be glad to hear it
), but it's bringing up another question, which is where to actually put this pointer.- Enlarging blizzards struct could be possible if i found the constructor, but as most of them are created at startup of the world editor / loading of the map, it would require me to activate the hack before loading, which is a mean restriction; i will also have hard times checking if it was loaded at the correct time and it might kill existing blizzard code (e.g. arrays of this struct will fail if the struct is 5 bytes larger)
- Finding a cave in the trigger, which finally brings us to the actual reason why im here:
where should i place that pointer? Ideas i had:
- Using the flag that tells whether this trigger has been changed. It would, however, require me to hack every single place in the code where this flag is changed to avoid leaking the buffer
- I could try to use the Custom-Text-Trigger-Flag, as i know that it can only be changed on two places (convert to custom text and str+z), but i don't know if changing this flag to a pointer might screw up other routines of the world editor (besides the save routine, obviously)
- The Triggers name is 80 signs long. However, after this buffer, there are a lot of 0's that also don't seem to be accessed by anything i do; the next seemingly used values are 260 bytes after the buffer starts (some pointer, followed by the map description, which is 2048 bytes long and does NOT have such a seemingly empty buffer after it). Can it be that this empty space is the result of the compilers data structure alignment and therefor a safe place to use?
- using one of those thousands of flags whose purpose i don't know and which don't seem to have any use as they are constantly written into, but never read out (unless im missing something here, which is probably the case)
So, does anybody know better potential places to store the pointer into? Where would you put it? Is it save to use that seemingly empty buffer after the trigger name?
(ps: if you actually read the whole post: respect
)
