- Joined
- Jun 16, 2004
- Messages
- 108
Recently I have thought about going back and working on some things that I only conceptualized in the past. This post sort of refers to one of those things. (Also some of the byte code stuff I have been seeing lately has motivated me)
I wrote a basic jass parser for fun, though a basic syntax checking parser is not anything new (probably not useful either, due to existing solutions). I decided to have it compile scripts to byte code. That is not very useful either, because the byte code would not be usable. So I also coded the functionality to load such byte code into a tool I already had available.
And here I am presenting the proof of concept: loading new fully functional jass byte code while the game is running.
To me, in its current form it does not feel very useful for map makers, but perhaps eventually it can reach that point. The project was just for fun really, but I am curious if people can find good use cases for this sort of thing. It does set an apparent path forward to another idea I had.
... Anyway, in short, you can compile jass and get it in executable form in the game, provided things go well (the compiler probably has a lot of bugs in it still, as it has had fairly minimal testing).
If you are interested, you can download the attachment and try it out yourself.
First I will note some important things:
- this will only work on game version 1.28.0
- you should not play online with this tool running, as it modifies memory and can get you banned
- the tool will try to disconnect you if you are in a multiplayer game, which further cements the above point
Something resembling instructions:
- download and extract the archive
- verify you can run jasstool.exe in the /jasstool directory, either just run it (and look for errors) or maybe run it through a dependency walker; if you are missing dependencies you may need whatever runtime matches VS 2017
- copy your common.j and Blizzard.j files into the /bytecode directory.
- make sure you are not online (ideally be at the main menu screen)
- run EMS.exe as an admin
- in the ems console that pops up, type in "start" (without quotation marks) and then press enter
- if it all works out, the ems console should start spitting out a bunch of text and wc3 should still be running properly; if things do not work out, wc3 will probably crash - and you may need to kill the process (war3.exe) in your task manager (try running the game again if it fails - and kill the War3.exe task if it says it cannot initialize).
- now that ems is running, try starting a game in single player or in LAN (alone)
Next we can actually try compiling a simple script:
- while in game, type the following as a chat slash command: /jvm bal common.j Blizzard.j createfootman.txt
- the createfootman.txt file is one that should already be present in the /bytecode directory
- assuming all goes well, a cmd prompt should pop up briefly, and then the ems console should say it has inserted a function; if things have gone wrong, there will be error messages instead (verify you copied common.j and Blizzard.j into the /bytecode directory, and that you can run jasstool.exe)
- next, try typing: /jvm ib createfootman
- if it all worked, then you should now have a footman at position 0, 0
And those two slash commands are the basic functionality:
/jvm bal common.j Blizzard.j [customscript.j] - will load the byte code into the game
/jvm ib [function name] - will run a function
Some limitations:
- it is not easy to declare new globals with the current compiler, though you could do it if you really wanted to via using the assembler functionality and some other commands
- you probably will only want to run a "takes nothing returns nothing" function when using the "/jvm ib" command
- the "/jvm bal" command is able to replace functions that already exist, provided the function's parameter count/types and return type does not change; if any of those things change it will throw an error instead
- the compiler is limited to vanilla jass only - if you use some other flavor, you would have to precompile to vanilla jass before the compiler could function on the script
There are a few other slash commands that might be interesting:
/ripbc [function name] <- this will take the byte code from the specified function and write it in the /bytecode directory
/scanstr [hex number] <- looks up the specified string id in the scan string table
/scanstri [string] <- adds a new string to the scan string table (limited to one word, though you could fix it if you wanted by looking at /lua/slash_scanstr.lua)
/scanstrf [string] <- finds the string id of the given string (limited to one word)
/jfunc [function name] <- prints in the ems console the address of the data about the function (which holds things such as the byte code address, return type, name string, and other stuff)
/load, /reload, /unload [script name] <- handles loading/reloading/unloading of a lua script
Some known issues (plan ahead):
- ems can crash the game while it is attaching
- ems causes the game to crash when the game is closed (alt+f4/etc)
- ems will crash the game if you close ems after it already attached to the game
- ems has in the past managed to crash the world editor, not sure if this still happens since I changed the attach logic
Anyway, I am curious if anyone is interested in this sort of tool.
I wrote a basic jass parser for fun, though a basic syntax checking parser is not anything new (probably not useful either, due to existing solutions). I decided to have it compile scripts to byte code. That is not very useful either, because the byte code would not be usable. So I also coded the functionality to load such byte code into a tool I already had available.
And here I am presenting the proof of concept: loading new fully functional jass byte code while the game is running.
To me, in its current form it does not feel very useful for map makers, but perhaps eventually it can reach that point. The project was just for fun really, but I am curious if people can find good use cases for this sort of thing. It does set an apparent path forward to another idea I had.
... Anyway, in short, you can compile jass and get it in executable form in the game, provided things go well (the compiler probably has a lot of bugs in it still, as it has had fairly minimal testing).
If you are interested, you can download the attachment and try it out yourself.
First I will note some important things:
- this will only work on game version 1.28.0
- you should not play online with this tool running, as it modifies memory and can get you banned
- the tool will try to disconnect you if you are in a multiplayer game, which further cements the above point
Something resembling instructions:
- download and extract the archive
- verify you can run jasstool.exe in the /jasstool directory, either just run it (and look for errors) or maybe run it through a dependency walker; if you are missing dependencies you may need whatever runtime matches VS 2017
- copy your common.j and Blizzard.j files into the /bytecode directory.
- make sure you are not online (ideally be at the main menu screen)
- run EMS.exe as an admin
- in the ems console that pops up, type in "start" (without quotation marks) and then press enter
- if it all works out, the ems console should start spitting out a bunch of text and wc3 should still be running properly; if things do not work out, wc3 will probably crash - and you may need to kill the process (war3.exe) in your task manager (try running the game again if it fails - and kill the War3.exe task if it says it cannot initialize).
- now that ems is running, try starting a game in single player or in LAN (alone)
Next we can actually try compiling a simple script:
- while in game, type the following as a chat slash command: /jvm bal common.j Blizzard.j createfootman.txt
- the createfootman.txt file is one that should already be present in the /bytecode directory
- assuming all goes well, a cmd prompt should pop up briefly, and then the ems console should say it has inserted a function; if things have gone wrong, there will be error messages instead (verify you copied common.j and Blizzard.j into the /bytecode directory, and that you can run jasstool.exe)
- next, try typing: /jvm ib createfootman
- if it all worked, then you should now have a footman at position 0, 0
And those two slash commands are the basic functionality:
/jvm bal common.j Blizzard.j [customscript.j] - will load the byte code into the game
/jvm ib [function name] - will run a function
Some limitations:
- it is not easy to declare new globals with the current compiler, though you could do it if you really wanted to via using the assembler functionality and some other commands
- you probably will only want to run a "takes nothing returns nothing" function when using the "/jvm ib" command
- the "/jvm bal" command is able to replace functions that already exist, provided the function's parameter count/types and return type does not change; if any of those things change it will throw an error instead
- the compiler is limited to vanilla jass only - if you use some other flavor, you would have to precompile to vanilla jass before the compiler could function on the script
There are a few other slash commands that might be interesting:
/ripbc [function name] <- this will take the byte code from the specified function and write it in the /bytecode directory
/scanstr [hex number] <- looks up the specified string id in the scan string table
/scanstri [string] <- adds a new string to the scan string table (limited to one word, though you could fix it if you wanted by looking at /lua/slash_scanstr.lua)
/scanstrf [string] <- finds the string id of the given string (limited to one word)
/jfunc [function name] <- prints in the ems console the address of the data about the function (which holds things such as the byte code address, return type, name string, and other stuff)
/load, /reload, /unload [script name] <- handles loading/reloading/unloading of a lua script
Some known issues (plan ahead):
- ems can crash the game while it is attaching
- ems causes the game to crash when the game is closed (alt+f4/etc)
- ems will crash the game if you close ems after it already attached to the game
- ems has in the past managed to crash the world editor, not sure if this still happens since I changed the attach logic
Anyway, I am curious if anyone is interested in this sort of tool.
Last edited:
