- Joined
- Jul 29, 2007
- Messages
- 5,174
When a map is saved with the World Editor, it takes some of its internal files, like units/items, regions, and map sounds, and converts them to Jass code that is injected in the final map script.
A while ago I said I'll work on code that tries to rebuild map files from the map script.
That is, the reverse process - taking the final map script, and recreating the internal World Editor files.
I had a small demo back then, but it was extremely limited and only served as a proof of concept.
Then I wrote most of what I now call the Jass context, which is not quite a Jass VM, but something towards there.
It converts the Jass code to equivalent JS code, stores all of the global variables, functions, etc.
Handles and references are tracked, and in fact technically almost everything that happens, including function calls, variable sets/gets etc. is tracked.
Due to it not being an actual VM, it inherently cannot support multiple threads and thus TriggerSleepAction, though.
Obviously most of the natives are not implemented. Most of the simple ones are.
A long time passed since I did most of this, and now I finally went back to it and made a new demo.
It's still very minimal, but it works on many maps.
It's not likely I'll work on this much more, overall it's still here to serve as a proof of concept.
There was a more featured so called "deprotector" that was made many years ago. If that's what you're after, go search for it.
With that out of the way, you can check it here.
A thing to note - the Jass parser I use is extremely slow and inefficient. I may switch to my own parser rather than using a generic one. If your map isn't small, expect it to take a few seconds, and up to tens of seconds for really big scripts.
For comparison's sake, parsing common.j (175KB) takes about 470 milliseconds on my computer, and Blizzard.j (443KB) takes about 1039 milliseconds.
It also seems to be waaaaaay slower on Firefox than Chrome, and can fail while Chrome doesn't.
A while ago I said I'll work on code that tries to rebuild map files from the map script.
That is, the reverse process - taking the final map script, and recreating the internal World Editor files.
I had a small demo back then, but it was extremely limited and only served as a proof of concept.
Then I wrote most of what I now call the Jass context, which is not quite a Jass VM, but something towards there.
It converts the Jass code to equivalent JS code, stores all of the global variables, functions, etc.
Handles and references are tracked, and in fact technically almost everything that happens, including function calls, variable sets/gets etc. is tracked.
Due to it not being an actual VM, it inherently cannot support multiple threads and thus TriggerSleepAction, though.
Obviously most of the natives are not implemented. Most of the simple ones are.
A long time passed since I did most of this, and now I finally went back to it and made a new demo.
It's still very minimal, but it works on many maps.
It's not likely I'll work on this much more, overall it's still here to serve as a proof of concept.
There was a more featured so called "deprotector" that was made many years ago. If that's what you're after, go search for it.
With that out of the way, you can check it here.
A thing to note - the Jass parser I use is extremely slow and inefficient. I may switch to my own parser rather than using a generic one. If your map isn't small, expect it to take a few seconds, and up to tens of seconds for really big scripts.
For comparison's sake, parsing common.j (175KB) takes about 470 milliseconds on my computer, and Blizzard.j (443KB) takes about 1039 milliseconds.
It also seems to be waaaaaay slower on Firefox than Chrome, and can fail while Chrome doesn't.
Last edited:
