Jass Precompiler

Eh, I don't know how useful this would be for anyone who uses the GUI at all (like myself).

The problem is that if the JASS is messed up (i.e. has preprocessor in it) when you try to save then it, ya know, doesn't save. Cool, idea, but without the GUI script compiler recognizing it I think it'd be of limited use :P

Woops.... 0_o

It would actually have worked if you had nested everything in an outer #IFDEF...

Well, this version is supposed to work with both #IFDEFs and #INCLUDEs, even nested, no parsing is done on the included file though. One temporary solution is to parse all file first and then include the parsed ones... There will have to be a better solution on that later though...

@dataangel: If you are creating triggers with the gui only, you will probably have no use of the pre-processor at all. The pre-proccesor is meant for those wanting to push the limits of jass scripting. Sorry, but that's the way it's going to be.

I voted for:

Inclusion of code from own libraries and Support for namespaces and library Management - sounds good, I think this will also encourage sharing of jass code.

Integration into the Editor - and/or a command line interface would be enough for me.

C-ish syntax - making "set" "local" and "call" optional would be convenient. Also to reduce repetative code += -= *= /= to reduce repetative code. adding an automatic "for" loop would also be cool since it would eliminate a few more lines of code. declaration of variables anywhere in a function/file may be needed for this.

structs - it seems like this is the hardest (and best) part. Allowing them to contain other structs, arrays, functions, etc. would all be great. I believe you would need to resolve multidimentional arrays to get all of this in, which would be a good feature on its own.


Regular expressions can't recognize context-free languages, so full jass syntax checking, or anything like that, would require a lot of effort to parse.


Looks cool so far. I may be able to contribute to this project, once I learn some more perl I can take a look at the source code.

The biggest problem with a precompiler, or any external jass tool for that matter, is the integration with the WE. A lost of people use the GUI to look up function and constant names. Terrain and everything else is also edited in the WE. This means the WE is always open (except for AI editing maybe?). You can either paste the JASS code into the WE, or add it to the W3M after WE saves the map. This is all very well possible, but perl might not be the best choice of language.

If the program isn't extremely easy to use, I'm not even going to download it. If you really want to make a good tool, it's going to require a lot of effort.

Besides all that, I'm all for a precompiler. If you need help with perl, ask. I know a lot about perl and already wrote a parser for a simple language in perl once. I also did one in C++, and perl is probably easier, unless you use some tools for C.

I regularly push the limits. And I'm not coding with the GUI only per se -- I'm coding everything in the WE. I use tons of custom text, but I'm not using the action/condition/event menus that much. I only use the GUI where it's more convenient. I haven't memorized the hundreds of different blizzard/common.j functions so it's easier for now.

Working preprocessor, if WE would recognize it when you saved, would be useful even for the non-elite though, because people could just download header files to add new commands.

If someone have any suggestion on how extended syntax and a pre-processor can co-operate with the WE, I would be more than happy. I would also be more than happy to know how people want to use an extended syntax/pre-processor.

I am merely a programmer, so please tell me what to program. :ggani:

You'll need to generate .wtg and .wct files as well. Zepir wrote a documentation about thier format. That should probably be enough. Use winmpq or maybe make your program inject them into the map that is being scripted to.

Not necessarily, he may be able to program the thing to just read from the active text window, read that in, clear it and put in the edited stuff, since most of the precompiling will be done in the custom script section anyways that would probably be enough. Although I'm not very sure an outside program can interact with the window of another one.

Epigoni the worldeditor is a very taxing program. I'd rather not have it open at all if I'm using his precompiler. I think if he adds support for wct and wtg generation it will be amazing and not require me to be annoyed to death.

You misunderstand, I meant that when you're editing code within the editor, and you press save, the precompiler runs, then saves.

The problem with that solution (if it is possible) is that you lose the non precompiled code. Best would be if the code saved in the wct and wcg files is the non precompiled code and the one in the map script the precompiled code. But the question is if that is possible.

MAKE TEH COMMENTS WITH TEH ORIGIONAL COED

The precompiler pretty much follows this specification now, except regarding the #INCLUDE <file> directive, where it just includes the filecontent without any parsing at all. The condition on the includetable also doesn't work yet.

Please do test it.

Thanks, it works fine except for one thing. It would be nice if the code in between the #INCLUDETABLE tags could be more than 1 line.
Since that allows to include slightly converted slks and Blizzard slks have many columns I suggest increasing the %x to 2 digits (%xy).

Good work so far :D

Multiple line supported and it might be possible with even %142 now. 8))