- Joined
- Mar 27, 2012
- Messages
- 3,232
I've created a code construct that runs after the whole vJASS preprocessor(or before it, but that's not preferable).
Essentially it works like this:
There are blocks that start with //# extendor and end with //# endextendor.
There are also single-line calls that start with //# runextendor.
Each extendor is named.
Each extendor has a priority(0 if undefined)
When the map has been saved, all extendor blocks are combined into chunks based on name(blocks with the same name are combined together).
Then every runextendor line is replaced with the appropriate block.
If necessary, parts of a block are organized based on priorities. Blocks with lower priority numbers are placed first.
So the formats are:
When extendor blocks are compiled, then the leading whitespace+// is removed from code inside the blocks. Commenting code out is necessary because otherwise the vJASS preprocessor would throw errors.
If you want to use comments inside extendors you need to use another //.
Multiline comments are handled entirely by the vJASS preprocessor, so extendors don't even know of their existence.
Possible uses:
*A projectile system where collision handlers do not need to be defined as triggers. Callback efficiency varies, as at some point it is cheaper to run a trigger than to do a bunch of if-then-else cycles for finding out the proper handler.
*A damage handler for a damage detection system such as the one by looking_for_help. Adds priorities with 0 code overhead.
*Coding events with no code overhead.(unit indexers,damage detection systems,ability managers, among other things)
Thinking about this feature further I have concluded that several vJASS features are partially or entirely subtypes of this construct:
*Globals blocks - Place one runextendor line in the globals block of the war3map.j and add to it with extendors. Identical functionality.
*Text macros without arguments - Define blocks of code with extendor blocks and run with runextendor. Functionality is identical.
*Modules without scoping - Same as text macros.
*Libraries(code organization) - A single runextendor line for the whole map with one extendor block per library to add to it. Libraries work better in this case.
Download from pastebin.
Warning. I do not guarantee that this feature is bug-free or that I will fix it if it doesn't work right or that it will work out of the box like it does for me. I am however willing to help in getting it to work and change/add features when I find it appropriate to do so.
Purposefully breaking the feature does not prove a point to me, as this is not a fully foolproof code construct and was never meant to be such.
I am also not responsible in any way if this construct breaks your JNGPE installation, crashes the editor, destroys your map, targets a nuclear bomb at your house, kills your cat or does anything else that you may find undesirable.
EDIT: Current version is a bit buggy. I'm fixing it as soon as I can.
EDIT2: Not buggy. I'm just an idiot at using my own code.
Essentially it works like this:
There are blocks that start with //# extendor and end with //# endextendor.
There are also single-line calls that start with //# runextendor.
Each extendor is named.
Each extendor has a priority(0 if undefined)
When the map has been saved, all extendor blocks are combined into chunks based on name(blocks with the same name are combined together).
Then every runextendor line is replaced with the appropriate block.
If necessary, parts of a block are organized based on priorities. Blocks with lower priority numbers are placed first.
So the formats are:
JASS:
//# extendor NAME [PRIORITY]
//code
//more code
//# endextendor
//# runextendor NAME
When extendor blocks are compiled, then the leading whitespace+// is removed from code inside the blocks. Commenting code out is necessary because otherwise the vJASS preprocessor would throw errors.
If you want to use comments inside extendors you need to use another //.
Multiline comments are handled entirely by the vJASS preprocessor, so extendors don't even know of their existence.
Possible uses:
*A projectile system where collision handlers do not need to be defined as triggers. Callback efficiency varies, as at some point it is cheaper to run a trigger than to do a bunch of if-then-else cycles for finding out the proper handler.
*A damage handler for a damage detection system such as the one by looking_for_help. Adds priorities with 0 code overhead.
*Coding events with no code overhead.(unit indexers,damage detection systems,ability managers, among other things)
Thinking about this feature further I have concluded that several vJASS features are partially or entirely subtypes of this construct:
*Globals blocks - Place one runextendor line in the globals block of the war3map.j and add to it with extendors. Identical functionality.
*Text macros without arguments - Define blocks of code with extendor blocks and run with runextendor. Functionality is identical.
*Modules without scoping - Same as text macros.
*Libraries(code organization) - A single runextendor line for the whole map with one extendor block per library to add to it. Libraries work better in this case.
Download from pastebin.
Warning. I do not guarantee that this feature is bug-free or that I will fix it if it doesn't work right or that it will work out of the box like it does for me. I am however willing to help in getting it to work and change/add features when I find it appropriate to do so.
Purposefully breaking the feature does not prove a point to me, as this is not a fully foolproof code construct and was never meant to be such.
I am also not responsible in any way if this construct breaks your JNGPE installation, crashes the editor, destroys your map, targets a nuclear bomb at your house, kills your cat or does anything else that you may find undesirable.
EDIT: Current version is a bit buggy. I'm fixing it as soon as I can.
EDIT2: Not buggy. I'm just an idiot at using my own code.
Last edited: