VJASS Documentation

JassHelper 0.A.2.B

Although World Editor's Jass compiler was finally replaced by PJass using WEHelper , there were a couple of other annoyances that still needed fixing, that's the reason this project begand.

Later I felt like going further and restarted the idea of extending Jass to OOP thus JassHelper is a compiler for the vJass language extension which includes structs, libraries, textmacros and more.

Although this is not really OOP the syntax is powerful enough I hope, there is no inheritance and that's the reason I am not calling the objects classes but structs. There are however, interfaces which allow polymorphism and since they can declare attributes you can have some kind of pseudo inheritance. Pseudo inheritance can be accomplished in many ways.

The design of vJass ought to stay static eventually so I stop adding syntax construct cause that' the right thing to do. After version 1.0.0 there should not be any addition, so if you have requests hurry up cause it would not be healthy to change the syntax after 1.0.0.

Version Z.0 introduces the addition of the Zinc language to jasshelper, it is just a less verbose alternative to vJass that is also more rigid on some aspects.

Table of contents

I. vJass reference:

  • Jass syntax mods
  • Entry preprocessors

II. Installation

III. Usage

I. vJass reference:

If you want actual instructions on how to install and use JassHelper: skip to the usage area, remember to come back here once you have it installed so you can actually take advantage of this solution.

Global declaration Freedom

Warcraft III world editor always made everything harder for us, inluding declaring globals, you needed to use that dialog and it was really difficult to recreate global variables from a map or another and you were forced to use GUI for that. It was also impossible to declare globals of some types without modding world editor and then make your map completelly unopenable by normal world editor.

Global declaration freedom simply allows you to write globals blocks wherever you want, for example in the custom script section or in a 'trigger', and because of this you can even use the constant prefix which can even make finalizers able to inline constants and stuff.

The JassHelper preprocessor will simply merge all the global blocks found around the map script and move them to the top of the map, all merged in a single globals block.

function something takes nothing returns nothing
    set somearray[SOMETHING_INDEX]=4
endfunction

globals
    constant integer SOMETHING_INDEX = 45
    integer array somearray
endglobals

Will now work without any error, there is one limitation though, you can't use functions or non-constant values in the default value, for example you can make a global start on null, 1 , 19923 , 0xFFF, true, false, "Hi" , etc. But you can't make them initialize with any function call or with a native (although it is possible to use a native, most natives tend to crash the thread when used in globals declaration). You can't also assign to another global variable, because there isn't really a way to control to what position of the map would a global declaration go.

Notes:

  • Please try to keep a good global naming method, some programs use pure caps for global names, Jass' standard set by common.j and blizzard.j is that constants should be uppercase, you can then use system_variable for a good variable name, although you can stick to the udg_ preffix as well.

Native declaration Freedom

This feature (added in 0.9.I.0) is similar to global declarations, but it is for more advanced users, so if you do not understand a single thing of these few paragraphs, feel free to skip to the explanation about the debug keyword. Warcraft III supports declaration of natives in the map script, but it requires the natives to be declared just after the script's globals section. Jasshelper will detect these declarations along the map and move them to the correct place.

Why would you want to do this? And what native functions exactly? There are some few native functions that were created for AI scripts that are not declared in common.j, some of them are actually useful for Jass maps. There is also the possibility you are using a modded/hacked version of warcraft III, and importing a whole new common.j for the native functions is probably too annoying for you, in this case you can declare the new custom functions in the map as well.

There is a protection in this feature that will make jasshelper delete declarations of duplicate natives. (i.e if the native was already declared in common.j, it will remove the native from the map script, to ensure your map is actually playable). This heavily depends on the common.j version provided to jasshelper. This is something to consider if for some reason the common.j version you (or newgen pack) is passing to jasshelper is different to the common.j version you intend the map to be playable with.

native GetUnitGoldCost takes integer unitid returns integer

function test takes nothing returns nothing
    call BJDebugMsg("A footman consts : "+I2S( GetUnitGoldCost('hfoo')+" gold coins" ) )
endfunction

Debug preprocessor

Jass includes a debug keyword which compiles correctly but makes the rest of the code be ignored. It seemed this keyword was used for debugging purposes like a switch in a debug build of warcraft III that enabled those calls.

We can now take advantage of this hidden Jass feature. Saving a map in debug mode using JassHelper will simply remove the debug keyword so the calls are enabled, if debug mode is not enabled, JassHelper will remove the lines that begin with debug.

function Something takes integer a returns nothing
   debug call BJDebugMsg("a is "+I2S(a))
   call KillNUnits(a)
endfunction

If we use this function in a map saved with debug mode, we will see "a is value" each time this function is called, otherwise it will only call KillNUnits silently.

You may also use the constant boolean DEBUG_MODE which is set to true or false depending on whether the debug mode is enabled.

Local variables shadowing

Starting with version 0.9.K.0, local variable shadowing is part of vJass syntax, unlike Jass syntax in which it has always been a problem. Up to patch 1.24, it was not even possible to shadow more than one variable, and it turned the whole map script into case-insensitive. These glitches were apparently fixed around patch 1.24, but they were fixed barely to a level of helping GUI users do local var tricks. Issues persist, and the issues are of the kind that could eventually cause some scripts issues in unpredictable places.

If the vJass code is used correctly and things are correctly scoped, this should not be a problem. However, when using code from multiple places, one of the codes may not be correctly scoped, which threatens to cause a conflict with a local variable and thus then making your map mysteriously unopenable in wc3. Jass' weakness with variable shadowing was too unpredictable in nature. So I decided to add a small preprocessor phase to jasshelper that will simulate correct local variable shadowing. This means that the local variables in your functions may now have the same name as any global in the map (even globals you do not know about) without causing further issues or unknown, unpredictable bugs (unlike normal Jass in which this is an active possibility). Although the vJass code allows variable shadowing, it is compiled to Jass code in which there is no shadowing (some l__ prefixes are added to conflicting local variables).

Patch 1.24 return bug false positive fixer

Note: This feature is disabled by default as the problems were fixed by patch 1.24b.

Retail patch 1.24 brought a lot of doom and destruction to the world of Jass, thanks to some new blizzard bugs, certain functions with more than one return statement would silent cause syntax errors or crash the game, effectively making innocent maps unplayable, even if they do not use the now infamous &aquot;Return bug exploiters&aquot;. This was the reason, that I had to add a quick fix to jasshelper, this compiler mod will replace all your functions with multiple return values into two separate functions that will be safe from the false positive.

Side effects and limitations

This fixer is only meant as a temporary measure while blizzard fixes this terrible bug or while you make your functions safe from having multiple return statements, whatever happens first. The technique is a little dumb, for each function that is suspect, it will create a new dummy one that returns nothing, and just assigns a global before returning, then the old function will actually call this dummy function. In short words, this means that this fixer will make calling certain functions (specifically those that have a return value and more than 1 return statements) slightly slower by adding an extra function call.

This method does not work correctly with recursive functions (as it is still not possible to call a function from above its declaration). It is likely that if a function is recursive and has multiple return statements, it will cause a compiler error. In this case, it is better to modify the function, as it is most likely also a return bug false positive (so it probably causes your map to be unplayable in patch 1.24). To prevent this, jasshelper will try to detect the recursion, and if possible, take care of it. But there are some recursion patterns that jasshelper cannot fix at this moment.

Enabling the return fixer

This feature must be manually enabled, so if you for some reason need to make your map work specifically with patch 1.24, or if maybe you think that some return bug false positive is still affecting your map, you can enable the feature.

In order to enable the return fixer, take jasshelper.conf and replace [noreturnfixer] with [doreturnfixer] if there is no tag [noreturnfixer] in jasshelper.conf, then simply add the [doreturnfixer] tag to it.

Import external script files

JassHelper also includes a //! import preprocessor like WEHelper's, it allows you to import external files.

The usage is //! import "scriptfile" , you can use fixed paths or relative paths.

For example: //! import "c:\x.j" will include x.j file located on c:\ in your map script. It is effectively like pasting the file there before compiling it, so the file can include globals, libraries, textmacros, etc. It can even use //! import itself

If you use //! import twice or more on the same file name , the command is ignored.

Relative paths are allowed, for example: //! import "x.j" or //! import "subfolder\f.j" will use relative paths. When the path is relative JassHelper will look for the script file in the map's folder or in the lookup folders set in JassHelper's configuration.

Grimoire's version uses jasshelper.conf to determine the lookup folders, WEHelper's version comes with a dialog that allows you to set them. Also the version for WEHelper will automatically add wehelper's import path to the lookup folders list.

WEHelper's internal import preprocessor is most likely to override JassHelper's import since the default is to call it before JassHelper, in case you want to use JassHelper's import you would have to disable WEHelper's, the only advantage the jasshelper one has over the wehelper one is the ability to configure lookup folders.

Grimoire's jassehlper.conf already determines grimoire' Jass folder as a position of scripts. You can add whatever folders you find necessary. Notice that there is a priority system, if a file is found on the map's folder it will be imported no matter the same file exists in another folder used in jasshelper.conf

There is a problem with using the map's folder and it is that testmap saves the map in another path. So you would preffer to use custom paths for this option.

Test map is often problematic with this kind of features. The best way to deal with this is to ALWAYS SAVE BEFORE USING TESTMAP, this will force the map to go to its path and then will use it for testmap, in case you need to test temporary changes, you can save it with another name in the same folder and then do testmap.

As of jasshelper 0.9.C.0 , relative paths used by import an already-imported file will be able to also support the file's path as possible container. Notice that the files in the same folder as the current file have priority over files on the configured paths or even the map's location.

import syntax has been extended to have an extra script type option:

//! import vjass/zinc/comment "filename"

vjass is assumed to be the default. zinc makes the file to be considered a zinc script. comment makes the import command get ignored unless we compile under the warcity mode.

Zinc

Jasshelper supports two scripting languages, vJass and Zinc. vJass is an extension to wc3's JASS, while Zinc is a less verbose language that is more rigid in certain aspects and also has control structures and things not well compatible with JASS.

For more info on the Zinc language and its syntax please refer to the other file, Zinc manual

No vjass!

The //! novjass and //! endnovjass preprocessor directives allow you to make vjass compilers (like jasshelper) completely ignore the code between them.

 function VerifyVJass takes nothing returns nothing
  local boolean b=true
    //! novjass
        set b=false
    //! endnovjass
    if(b) then
        call BJDebugMsg("You got vJass")
    else
        call BJDebugMsg("Where's vJass?")
    endif
 endfunction

If that code is parsed by a vJass compiler, it will remove what is inside the //! novjass blocks. If the function is just saved in normal World Editor, it will just ignore the //! novjass tags (since it will think they are comments) so it will still consider their contents.

Libraries

Yet another issue with World editor and Jass was that it is impossible to control the order of triggers in the map's script when saved. The custom script partially solved the problem but it is really problematic to ask users to paste things there, it is also anti-modular programming to keep it full of unrelated stuff.

The library preprocessor allows you to keep your top functions in the top and being able to control where each one goes. It also has an smart requirement support so it will sort the function packs for you.

The syntax is simple, you use library LIBRARYNAME or library LIBRARYNAME requires ONEREQUIREMENT or library LIBRARYNAME requires REQ1, REQ2 ...

Remember to mark the end of a library using the endlibrary keyword .

library B
    function Bfun takes nothing returns nothing
    endfunction
endlibrary

library A
    function Afun takes nothing returns nothing
    endfunction
endlibrary

If JassHelper finds this command, it will make sure to move the Afun and Bfun functions to the top of the map's script, so the rest of the map's script can freely call Afun() or Bfun().

Notice that it would be uncertain to know what would happen if Afun() was called from a function inside the B library. The command is to move libraries to the top, but we wouldn't know if B went before or after A.

If a function inside library B needed to call a function inside library A we should let JassHelper know that A must be added before B. That's the reason the 'requires' keyword exists:

    library C requires A, B, D
        function Cfun takes nothing returns nothing
            call Afun()
            call Bfun()
            call Dfun()
        endfunction
    endlibrary

    library D
        function Dfun takes nothing returns nothing
        endfunction
    endlibrary

    library B requires A
        function Bfun takes nothing returns nothing
            call Afun()
        endfunction
    endlibrary

    library A
        function Afun takes nothing returns nothing
        endfunction
    endlibrary
    

Note: For senseless reasons: requires, needs and uses all work correctly and have the same function in the library syntax, but please use requires, the other ones may be gone one day...

The result in the top of the map would be:

    function Afun takes nothing returns nothing
    endfunction
    function Dfun takes nothing returns nothing
    endfunction
    function Bfun takes nothing returns nothing
        call Afun()
    endfunction
    function Cfun takes nothing returns nothing
        call Afun()
        call Bfun()
        call Dfun()
    endfunction
    

Well, not necessarily. It would depend on the order WE saves the scripts in the input file, if two libraries do not require each other, then they may get added on a random order depending on the order in which they are declared in the map. It is always a good idea to require the libraries you are going to use in your library.

Make sure to remember that:

  • Library names are Case Sensitive.
  • If library A requires library B and library B requires library A , there's a cycle and JassHelper will popup a syntax error.
  • If library A requires a library that requires B and library B requires A, the cycle is still there.
  • You can't nest libraries.
  • Libraries might have globals blocks, as of version 0.9.B.0 library requirements determine the order in which these variables are added, notice that this warranty does not exist in prior versions.

It is also difficult to control what code is executed first, that's the reason libraries also have an initializer keyword, you can add initializer FUNCTION_NAME after the name of a library and it will make it be executed with priority using ExecuteFunc , ExecuteFunc is forced so it uses another thread, most libraries require heavy operations on init so we better prevent the init thread from crashing. After the initializer keyword the 'needs' statement might be used as well.

The initializers are added to the script in the same order libraries are added. So if library A needs B and both have initializers then B's inititalizer will be called before A's.

Notice the initializer must be a function that takes nothing .

    library A initializer InitA requires B
    
        function InitA takes nothing returns nothing
           call StoreInteger(B_gamecache , "a_rect" , Rect(-100.0 , 100.0 , -100.0 , 100  ) )
        endfunction
    
    endlibrary

    library B initializer InitB
        globals
            gamecache B_gamecache
        endglobals
    
        function InitB takes nothing returns nothing
            set B_gamecache=InitGameCache("B")
        endfunction
    endlibrary

B's initializer will be called on init before A's initializer.

Hints:

  • The library_once keyword works exactly like library but you can declare the same library name twice, it would just ignore the second declaration and avoid to add its contents instead of showing a syntax error, it is useful in combination with textmacros.
  • Older versions of vJass had a different syntax for libraries, that started with //! this was eventually deprecated and will now pop a syntax error out.

Hints: As of 0.9.Z.0, the declaration of a library will create a true boolean constant called LIBRARY_libraryname. Requirements may also be optional (prefix an optional keyword before the requirement name) which means that the library will be moved bellow that requirement, but if the requirement is not found, no syntax error will appear. These may be useful with another new 0.9.Z.0 feature: static ifs.

Static ifs

static ifs are like normal ifs, except that a) the condition must contain only constant booleans, the and operator and the not operator and b) They are evaluated during compile time. Which means that the code that is not matched to its condition is simply ignored.

    library OptionalCode requires optional UnitKiller
        globals
            constant boolean DO_KILL_LIB = true
        endglobals

        function fun takes nothing returns nothing
            local unit u = GetTriggerUnit()
            //the following code may need to kill the unit
            //but is alternatively able to use the external
            //'UnitKiller' library to do the library.
            // ONLY when DO_KILL_LIB is true AND the
            // library UnitKiller is in the map.
            static if DO_KILL_LIB and LIBRARY_UnitKiller then
                //static if because if the UnitKiller
                // library was not in the map, using a normal
                // if would not remove this line of code and
                // therefore it would cause a syntax error.
                // (unable to find function UnitKiller)
                call UnitKiller(u)
            else
                call KillUnit(u)
            endif
        endfunction

    endlibrary

    library UnitKiller

        function UnitKiller(unit u)
            call BJDebugMsg("Unit kill!")
            call KillUnit(u)
        endfunction

    endfunction

Private members

With the adition of libraries it was a good idea to add some scope control, private members are a great way of protecting users from themselves and to avoid collisions.

library privatetest
    globals
        private integer N=0
    endglobals
    private function x takes nothing returns nothing
        set N=N+1
    endfunction

    function privatetest takes nothing returns nothing
        call x()
        call x()
    endfunction
endlibrary

library otherprivatetest
    globals
        private integer N=5
    endglobals
    private function x takes nothing returns nothing
        set N=N+1
    endfunction

    function otherprivatetest takes nothing returns nothing
        call x()
        call x()
    endfunction
endlibrary

Notice how both libraries have private globals and functions with the same names, this wouldn't cause any syntax errors since the private preprocessor will make sure that private members are only available for that scope and don't conflict with things named the same present in other scopes. In this case private members are only to be used by the libraries in which they are declared.

Sometimes, you don't want the code to go to the top of your script (it is not really a function library) yet you' still want to use the private keyword for a group of globals and functions. This is the reason we defined the scope keyword

The scope keyword has this syntax: scope NAME [...script block...] endscope

So, functions and other declarations inside an scope can freely use the private members of the scope, but code outside won't be able to. (Notice that a library is to be considered to have an internal scope with its name)

There are many applications for this feature:

scope GetUnitDebugStr

    private function H2I takes handle h returns integer
        return h
        return 0
    endfunction

    function GetUnitDebugStr takes unit u returns string
        return GetUnitName(u)+"_"+I2S(H2I(u))
    endfunction
endscope

In this case, the function uses H2I, but H2I is a very common function name, so there could be conflicts with other scripts that might declare it as well, you could add a whole preffix to the H2I function yourself, or make the function a library that requires another library H2I, but that can be sometimes too complicated, by using an scope and private you can freely use H2I in that function without worrying. It doesn' matter if another H2I is declared elsewhere and it is not a private function, private also makes the scope keep a priority for its members.

It is more important for globals because if you make a function pack you might want to disallow direct access to globals but just allow access to some functions, to keep a sense of encapsullation, for example.

The way private work is actually by automatically prefixing scopename(random digit)__ to the identifier names of the private members. The random digit is a way to let it be truly private so people can not even use them by adding the preffix themselves. A double _ is used because we decided that it is the way to recognize preprocessor-generated variables/functions, so you should avoid to use double __ in your human-declarated identifier names. Being able to recognize preprocessor-generated identifiers is useful when reading the output file (for example when PJass returns syntax errors).

In order to use private members ExecuteFunc or real value change events you have to use SCOPE_PRIVATE (see bellow)

Hint:Scopes support initializer just like libraries, there is a difference in implementation and it is that they use a normal call rather than an ExecuteFunc call, if you need a heavy process to init a scope, better use a library initializer or call a subfunction using ExecuteFunc from the scope initializer.

Note:In a similar way to libraries, scopes used to have a syntax that required //! , that old syntax is deprecated and will cause a syntax error.

Public members

Public members are closely related to private members in that they do mostly the same, the difference is that public members don't get their names randomized, and can be used outside the scope. For a variable/function declared as public in an scope called SCP you can just use the declared function/variable name inside the scope, but to use it outside of the scope you call it with an SCP_ preffix.

An example should be easier to understand:

    library cookiesystem
        public function ko takes nothing returns nothing
            call BJDebugMsg("a")
        endfunction

        function thisisnotpublicnorprivate takes nothing returns nothing
             call ko()
             call cookiesystem_ko() //cookiesystem_ preffix is optional
        endfunction
    endlibrary

    function outside takes nothing returns nothing
         call cookiesystem_ko() //cookiesystem_ preffix is required
    endfunction

Public function members can be used by ExecuteFunc or real variable value events, but they always need the scope prefix when used as string:

    library cookiesystem
        public function ko takes nothing returns nothing
            call BJDebugMsg("a")
        endfunction

        function thisisnotpublicnorprivate takes nothing returns nothing
             call ExecuteFunc("cookiesystem_ko") //Needs the prefix no matter it is inside the scope

             call ExecuteFunc("ko") //This will most likely crash the game.
             call cookiesystem_ko() //Does not need the prefix but can use it.
             call ko() //since it doesn't need the prefix, the line works correctly.
        endfunction
    endlibrary

Alternatively, you may use SCOPE_PREFIX (see bellow)

Note: If you use public on a function called InitTrig, it is handled in an special way, instead of becoming ScopeName_InitTrig it will become InitTrig_ScopeName, so you could have an scope/library in a trigger with the same scope name and use this public function instead of manually making InitTrig_Correctname.

Nested scopes

Scopes can be nested, don't confuse this statement with "libraries can be nested", in fact, you cannot even place a library inside an scope definition. You can however, have scope inside either library or scope definitions.

An scope inside another scope is considered a child scope. A child scope is considered to be a public member of the parent scope (?).

A child scope cannot declare members that were previously declared as private or global by a parent scope.

A child scope behaves in relation to its parent in the same way as a normal scope behaves in relation to the whole map script.

Since child scopes are always public members, you can access a child scope' public members froum outside the parent scope, but it needs a prefix for the parent and a prefix for the child.

An example :

    library nestedtest
        scope A
          globals
            private integer N=4
          endglobals

          public function display takes nothing returns nothing
            call BJDebugMsg(I2S(N))
          endfunction
        endscope

        scope B
            globals
                public integer N=5
            endglobals

            public function display takes nothing returns nothing
                call BJDebugMsg(I2S(N))
            endfunction
        endscope

        function nestedDoTest takes nothing returns nothing
            call B_display()
            call A_display()
        endfunction

    endlibrary

    public function outside takes nothing returns nothing
        set nestedtest_B_N= -4
        call nestedDoTest()
        call nestedtest_A_display()

    endfunction

The next example will cause a syntax error:

    library nestedtest
        globals
            private integer N=3
        endglobals

        scope A
          globals
            private integer N=4 //Error: 'N' redeclared
          endglobals
        endscope

    endlibrary

It is actually caused by a limitation in the parser, there is a conflict caused by using N for the parent and then declaring it for the child. However this version does not cause syntax errors:

    library nestedtest
        scope A
          globals
            private integer N=4
          endglobals
        endscope

        globals
            private integer N=3
        endglobals

    endlibrary


It does kind of the same thing, but since the child's N was declared before the parent's the parser no longer gets in a confusion.

Another thing to keep in mind is that unlike normal global variables, private/public global variables cannot be used before declared, otherwise JassHelper will think they are just normal variables.

Scopes cannot be redeclared, there cannot be 2 scopes with the same name. But 2 child scopes might have the same name if they are children of different scopes, the reason is that they actually don't have the same name, they have different names given by their public child scope situation.

    library nestedtest
      scope A
        function kkk takes nothing returns nothing
            set N=N+5  // By the time JassHelper gets to this line, it did not see the private integer N
                       // declaration yet, so it assumes N is an attempt to use a global variable and does not
                       // do any replacement
        endfunction
      endscope

   endlibrary

   scope X
       scope A
          //Declaring scope A again does not cause any problem, it is because the scope is actually X_A , the
          // previous declaration of A was actually nestedtest_A
          function DoSomething takes nothing returns nothing
          endfunction

       endscope
    endscope

There is no nesting limit, but notice that resulting variable and function names of private/public members get big and bigger depending of the depth of the scope nesting. Bigger variable names may affect performance. Not a lot but they do, and this efficiency issue is to be prevented by an obfuscator/finalizer that renames every identifier in the map script a.k.a the map optimizer's shortest names possible method.

SCOPE_PREFIX and SCOPE_PRIVATE

Whenever you are inside an scope/library declaration, SCOPE_PREFIX and SCOPE_PRIVATE are enabled string constants that you could use.

SCOPE_PREFIX will return the name (as a Jass string) of the current scope concatenated with an underscode. (The prefix added for public memebers)

SCOPE_PRIVATE will return the name (as a Jass string) of the current prefix for private members.

scope test

    private function kol takes nothing returns nothing
        call BJDebugMsg("...")
    endfunction

    function lala takes nothing returns nothing
         call ExecuteFunc(SCOPE_PRIVATE+"kol")
    endfunction

endscope

In the example, we are allowing lala() to call the private function kol via ExecuteFunc.

keyword

The keyword statement allows you to declare a replacement directive for an scope without declaring an actual function/variable/etc. It is useful for many reasons, the most important of the reasons being that you cannot use a private/public member in an scope before it is declared, in most cases this limitation is no more than an annoyance requiring you to change the position of declarations, in other situations though this is a limitator of other features.

For example two mutually recursive functions may use .evaluate (keep reading this readme) to call each other, but if you also want the functions to be private it is impossible to do it without using keyword:

scope myScope

   private keyword B //we were able to declare B as private without having to actually
                     //include the statement of the function which would cause conflicts.

   private function A takes integer i returns nothing
       if(i!=0) then
           return B.evaluate(i-1)*2 //we can safely use B since it was already
                                    //declared as a private member of the scope
       endif
       return 0
   endfunction

   private function B takes integer i returns nothing
       if(i!=0) then
           return A(i-1)*3
       endif
       return 0
   endfunction

endscope

Text Macros

Let's accept it, sometimes we want very complex things added to Jass but other times, the only thing we actually need is an automatic text copy+paste+replace, textmacros were added because they can be really useful in a lot of very different cases

The syntax is simple, //! textmacro NAME [takes argument1, argument2, ..., argument n] then //! endtextmacro to finish. And just a runtextmacro to run. It is easier to understand after an example:

    //! textmacro Increase takes TYPEWORD
    function IncreaseStored$TYPEWORD$ takes gamecache g, string m, string l returns nothing
        call Store$TYPEWORD$(g,m,l,GetStored$TYPEWORD$(g,m,l)+1)
    endfunction
    //! endtextmacro

    //! runtextmacro Increase("Integer")
    //! runtextmacro Increase("Real")

The result of the example is:

    function IncreaseStoredInteger takes gamecache g, string m, string l returns nothing
        call StoreInteger(g,m,l,GetStoredInteger(g,m,l)+1)
    endfunction
    function IncreaseStoredReal takes gamecache g, string m, string l returns nothing
        call StoreReal(g,m,l,GetStoredReal(g,m,l)+1)
    endfunction

The $$ delimiters are required because the replace tokens could require to be together to other symbols.

Notice that strings and comments are not protected from the text replacement. So if there is a match for any of the arguments delimited by $$ it will always get replaced.

textmacros don't need arguments, in that case you simply remove the takes keyword.

    //! textmacro bye
    call BJDebugMsg("1")
    call BJDebugMsg("2")
    call BJDebugMsg("3")
    //! endtextmacro

    function test takes nothing returns nothing
        //! runtextmacro bye()
        //! runtextmacro bye()
    endfunction

Textmacros add just a lot of fake dynamism to the language, the next is the typical attach/handle vars call for handles:

    //! textmacro GetSetHandle takes TYPE, TYPENAME
        function GetHandle$TYPENAME$ takes handle h, string k returns $TYPE$
            return GetStoredInteger(udg_handlevars, I2S(H2I(h)), k)
            return null
        endfunction
        function SetHandle$TYPENAME$ takes handle h, string k, $TYPE$ v returns nothing
            call StoredInteger(udg_handlevars,I2S(H2I(h)),k, H2I(v))
        endfunction
    //! endtextmacro

    //! runtextmacro GetSetHandle("unit","Unit")
    //! runtextmacro GetSetHandle("location","Loc")
    //! runtextmacro GetSetHandle("item","Item")

The development time has beed reduced significantly

Textmacros and scopes/libraries can become best friends by allowing some kind of static object orientedness:

    //! textmacro STACK takes NAME, TYPE, TYPE2STRING
        scope $NAME$
            globals
                private $TYPE$ array V
                private integer N=0
            endglobals
            public function push takes $TYPE$ val returns nothing
                set V[N]=val
                set N=N+1
            endfunction

            public function pop takes nothing returns $TYPE$
                set N=N-1
                return V[N]
            endfunction

            public function print takes nothing returns nothing
             local integer a=N-1
                call BJDebugMsg("Contents of $TYPE$ stack $NAME$:")
                loop
                    exitwhen a<0
                    call BJDebugMsg(" "+$TYPE2STRING$(V[a]))
                    set a=a-1
                endloop
            endfunction
        endscope
    //! endtextmacro

    //! runtextmacro STACK("StackA","integer","I2S")
    //! runtextmacro STACK("StackB","integer","I2S")
    //! runtextmacro STACK("StackC","string","")
    function Test takes nothing returns nothing
        call StackA_push(4)
        call StackA_push(5)
        call StackB_push(StackA_pop())
        call StackA_push(7)
        call StackA_print()
        call StackB_print()
        call StackC_push("A")
        call StackC_push("B")
        call StackC_push("C")
        call StackC_print()
    endfunction

Hint: You can use textmacro_once in a similar way to library_once.

Hint 2: If you //! runtextmacro optional textmacroname(args), the textmacro line will not cause a syntax error if the textmacro does not exist.

Structs

Structs introduce Jass to the object oriented programming paradigm.

I am unable to explain them without making an example first:

struct pair
    integer x
    integer y
endstruct

function testpairs takes nothing returns nothing
 local pair A=pair.create()
    set A.x=5
    set A.x=8

    call BJDebugMsg(I2S(A.x)+" : "+I2S(A.y))

    call pair.destroy(A)

endfunction

As you can see, you can store multiple values in a single struct, then you can just use the struct as if it was another Jass type, notice the . syntax which is used for members on most common languages.

Declaring structs

Before using an struct you need to declare it, duh. The syntax is simply using the struct <name> and endstruct keyword, notice how similar they are to global blocks

To declare a member you simply use <type> <name> [= initial value]

In the above example we are declaring an struct type named pair, which has 2 members: x and y, they do not have an initial value set.

It is usually a good idea to assign initial values to the members, so that you don't have to manually initialize them after creating an object of the struct type, the usual default values are the null ones, but depending on the problem you want to solve you could need any other value.

Creating and destroying structs

Structs are pseudo-dynamic, you would often need to create and destroy structs, and you should create an struct an assign it to a variable before using it.

The syntax to create an struct (It is actually to get a unique id) is : structtypename.create()

In the case of the above struct you would have to use pair.create() to get a new struct.

JassHelper is just a preprocessor not a hack so whatever adition to Jass we add is still limited by Jass' own limitations, in this case, structs use arrays which have a 8191 values limit, and we cannot use index 0 which is null for structs, so there is an 8190 instances limit. This limit is for instances of each type, so you may have 8190 objects of a pair struct type and still are able to have many other instances of other types.

It means that if you keep creating many structs of a type without destroying them you would eventually reach the limit. So keep in mind this: IN the case the instances limit of a type is reached structtype.create() WILL RETURN 0.

The limit is not usually a worrying issue, 8190 is in practice a huge number, unless you want to make linked lists or things like that, but those should be solved by a lower level approach.

For example, if you are only using structs for spell instance data, it is even impossible to get more than 9 instances. And many other practical applications would never need more than 2000 instances.

UNLESS, of course some structs that are not used anymore are not getting destroyed. In that case the limit is reached by a bug in the usage of structs that should be fixed (In the case of structs, unlike handles, not destroying them does not increase the memory usage, but the risk of reaching the limit)

If you make calculations, if you create an struct per second and always forget to remove it, the map would need 2 hour, 16 minutes in order to reach the limit.

Either way if you are making this for usage by other people and are unsure about the possibility of reaching the limit you can always use a comparission with 0 after calling create() and block the process somehow in case the error is found.

In case the limit is reached and you don't have a way to catch it, struct 0 would be used and assigned and probably cause some conflicts later, the strenght of the conflicts could be null or huge depending on the way you are using the structs.

If debug mode is on when compiling the script, create() will show a warning message whenever the limit is reached.

To destroy an struct you simply use the destroy method which can work as an instance method or as a class method, in the above example call pair.destroy(a) is used to destroy the instance, but you could also use call a.destroy().

In the case you attempt to destroy the zero struct destroy will do nothing or would show a warning message if debug mode is on.

Struct usage

Just declare struct values the way you declare variables/functions/arguments of normal types.

Once an struct is declared and you create it and you want to access it, you have to access its members, the way is often (struct value).(member name) , in the case of pairs you use pair.x to access the x member and pair.y to access the y member.

Once a member is accessed the usage is quite similar to the usage of a variable. You can use it in set statements or as a value inside expressions.

struct pair
    integer x=1
    integer y=2
endstruct

function pair_sum takes pair A, pair B returns pair
 local pair C=pair.create()
    set C.x=A.x+B.x
    set C.y=A.y+B.y
 return C
endfunction

function testpairs takes nothing returns nothing
 local pair A=pair.create()
 local pair B=pair_sum(A, A)
 local pair C=pair_sum(A,B)

    call BJDebugMsg(I2S(C.x)+" : "+I2S(C.y))

    //Dont forget, if you are not using an struct instance anymore, you destroy it
    call B.destroy()
    call C.destroy()
    call pair.destroy(A)

endfunction

It would display "3 : 6"

Instance members

So, you can declare struct members of any type, even struct types. You cannot however declare array members, this limitation should be removed in later versions.

struct pairpair
    pair x=0 //you cannot use pair.create() and should actually only use constants for default initial values.
    pair y=0
endstruct

function testpairs takes nothing returns nothing
 local pairpair A=pairpair.create()
 local pair x

    set A.x=pair.create()
    set A.y=pair.create()

    set x=A.y //notice we are saving A.y in a backup variable so we can destroy it.
    set A.y= pair_sum(A.x,A.y) //this replaces A.y that's the reason we saved it

    call BJDebugMsg(I2S(  A.y.x )+" : "+I2S( A.y.y )) //notice the nesting of the . operator

    call A.x.destroy()
    call A.y.destroy()
    call A.destroy()
    call x.destroy()
endfunction

Globals of struct types

You can have globals of struct types. Because of Jass' limitations you cannot initialize them directly.

globals
     pair globalpair=0 //legal
     pair globalpair2= pair.create() //not legal
endglobals

You would have to assign them in an init function instead.

Static members

An static member would just behave like a global variable inside struct syntax, just add the static keyword before the member syntax. There can be static arrays as well.

They might be useful in conjunction to methods.

public/private Structs

You can declare scope's public or private structs and struct variables with all freedom

scope cool
    public struct a
        integer x
    endstruct

    globals
        a x
        public a b
    endglobals


    public function test takes nothing returns nothing
        set b = a.create()
        set b.x = 3
        call b.destroy()
    endfunction

endscope

function test takes nothing returns nothing
 local cool_a x=cool_a.create()
    set a.x=6
    call a.destroy()
endfunction

Methods

Methods are just like functions, the difference is that they are associated with the class, also [normal] methods are associated with an instance (in this case 'this')

Once again an example is needed

    struct point
        real x=0.0
        real y=0.0

        method move takes real tx, real ty returns nothing
            set this.x=tx
            set this.y=ty
        endmethod

    endstruct

    function testpoint takes nothing returns nothing
     local point p=point.create()
        call p.move(56,89)

        call BJDebugMsg(R2S(p.x))
    endfunction

this : A keyword that denotes a pointer to current instance, [normal] methods are instance methods which means that they are called from an already assigned variable/value of that type, and this will point to it. In the above example we use this inside the method to assign x and y, when calling p.move() it ends up modiffying x and y attributes for the struct pointed by p.

method syntax : You might notice that method syntax is really similar to function syntax.

this is optional : You can use a single . instead of this. when you are inside an instance method. (For example set .member = value)

Methods are different to normal functions in that they can be called from any place (except global declarations) and that you are not necessarily able to use waits, sync natives or GetTriggeringTrigger() inside them (but you may use any other event response), you might be able to use them but it depends on various factors, it is not recommended to use them at all. In next versions the compiler might even raise a syntax error when it finds them.

Encapsullation

Encapsullation is an object oriented programming concept in which you only give access to things that need to have access, in other words it is private and public for structs

    struct encap
        real a=0.0
        private real b=0.0
        public real c=4.5

        method randomize takes nothing returns nothing
            // All legal:
            set this.a= GetRandomReal(0,45.0)
            set this.b= GetRandomReal(0,45.0)
            set this.c= GetRandomReal(0,45.0)
        endmethod

    endstruct

    function test takes nothing returns nothing
     local encap e=encap.create()

         call BJDebugMsg(R2S(e.a)) //legal
         call BJDebugMsg(R2S(e.c)) //legal
         call BJDebugMsg(R2S(e.b)) //syntax error

    endfunction

private members can only be used inside the struct declaration. Public and private are options for both variables and methods.

All struct members are public by default, so the public keyword is not necessary, on the other hand you must specify private. Something to point out is the existance of the readonly keyword, it allows code outside the struct to read the variable but not to assign it. It is a nonstandard at the moment, so you shouldn't use it on public releases.

Static methods

Static methods or class methods do not use an instance, they are actually like functions but since they are declared inside the struct they can use private members.

    struct encap
        real a=0.0
        private real b=0.0
        public real c=4.5

        private method dosomething takes nothing returns nothing
            if (this.a==5) then
                set this.a=56
            endif
        endmethod

        static method altcreate takes real a, real b, real c returns encap
         local encap r=encap.create()
            set r.a=a
            set r.b=b
            set r.c=c
            call r.dosomething() //even though it is private you can use
                                 //it since we are inside the struct declaration
         return r
        endmethod

        method randomize takes nothing returns nothing
            // All legal:
            set this.a= GetRandomReal(0,45.0)
            set this.b= GetRandomReal(0,45.0)
            set this.c= GetRandomReal(0,45.0)
        endmethod

    endstruct

    function test takes nothing returns nothing
     local encap e=encap.altcreate(5,12.4,78.0)
         call BJDebugMsg(R2S(e.a)+" , "+R2S(e.c))
    endfunction

You might notice that the usual create() syntax works like an static method, and destroy() can work as static or instance method

You can override the static method create by declaring your own one, once you do it, you might require another method just to allocate a unique id for the struct, this is the allocate() static method which is added by default to all structs, it is a private method. When a struct does not have an specific create method declared, jasshelper will use allocate directly when .create is called.

Since 0.9.Z.1 you may also override the destroy method by declaring your own one. Then use deallocate to call the normal destroy method.

struct vec
   real x
   real y
   real z

   // static method create must return a value of the struct's type
   // create may have arguments.
   static method create takes real ax, real ay, real az returns vec
     local vec r= vec.allocate() //allocate() is private and
                                 //it gets a unique id for the struct
         set r.x=ax
         set r.y=ay
         set r.z=az

     return r
   endmethod

endstruct

function test takes nothing returns nothing
 local vec v= vec.create(1.0 , 0.0 , -1.0 )

    call BJDebugMsg( R2S(v.z) )

    call v.destroy()
endfunction

Static methods that take nothing can also be used as code values

    struct something
        static method bb takes nothing returns nothing
            call BJDebugMsg("!!")
        endmethod
    endstruct

    function atest takes nothing returns nothing
     local trigger t=CreateTrigger()
         call TriggerAddAction(t, function something.bb)
         call TriggerExecute(t)
    endfunction

The onDestroy method

There is no actual syntax for destructors, but there is a rule and it is that if the struct has a method called onDestroy, it is always automatically called when .destroy() is issued on an instance.

It is useful to have onDestroy when an instance of the type may hold things that have to be correctly cleaned, it saves time and even makes things safer.

    struct sta
        real a
        real b
    endstruct

    struct stb
        sta H=0
        sta K=0

        method onDestroy takes nothing returns nothing
            if (H!=0) then
                call sta.destroy(H)
            endif
            if (K!=0) then
                call sta.destroy(K)
            endif
        endmethod
    endstruct

In the above example, it is only needed to destroy the object of type stb and it would automatically destroy the attached objects of type sta if present.

The onInit method

It is usual to need some initialization to be done to an struct's static members during map initialization, you can use an static onInit method to make code execute during map initialization.

Notice struct initializations are executed before any library initializer, if you require a library initializer to be executed before your initialization, use a library initializer instead. The relative order between different struct initializers depends on the location they are found in the map script, therefore they actually depend on things like libraries as well (A struct initializer inside a library will run before the initializers inside other libraries that require it and also before initializers inside scopes).

     struct A
        static integer array ko

        private static method onInit takes nothing returns nothing //may be public as well
         local integer i=1000
             loop
                 exitwhen (i<0)
                 set A.ko[i]=i*2
                 set i=i-1
             endloop
        endmethod
     endstruct

Interfaces

Polymorphism is an OOP concept in which different object classes may have the same action, although the action is different, the action gets the same name. For example both an ant and a person run, but they are pretty different objects and the run action is implemented in different ways.

An interface is like a set of rules struct types follow and allow you to call actions of an struct without really knowing the exact type of the struct.

    interface printable
        method toString takes nothing returns string
    endinterface

    struct singleint extends printable
        integer v
        method toString takes nothing returns string
            return I2S(this.v)
        endmethod
    endstruct

    struct intpair extends printable
        integer a
        integer b

        method toString takes nothing returns string
            return "("+I2S(this.a)+","+I2S(this.b)+")"
        endmethod
    endstruct

    function printmany takes printable a, printable b, printable c returns nothing
        call BJDebugMsg( a.toString()+" - "+b.toString()+" - "+c.toString())
    endfunction


    function test takes nothing returns nothing
     local singleint x=singleint.create()
     local singleint y=singleint.create()
     local intpair z=intpair.create()

        set x.v=56
        set y.v=12
        set z.a=45
        set z.b=12

        call printmany(x,y,z)
    endfunction


The printmany function takes three arguments of type printable, it does not know exactly which types the objects are, only that they are of struct types that extend printable

The rule for an struct to follow the printable interface is that it has a toString() method, the printmany function can use that method even though it does not know the exact types of the arguments

The toString() method is different for singleint and intpair, when printmany is called it calls the correct version of toString() for each argument, the result for the above sample is : "56 - 12 - (45,12)".

Interfaces can have any number of methods and structs that extend them should implement all those methods, but can ther methods implemented as well.

It is illegal to declare onDestroy for an interface declaration, you can consider it to be automatically declared, you can use .destroy() on a variable of interface type and it will call the appropiate onDestroy method when necessary.

Interfaces can also implement variables, in this case interfaces allow some pseudo inheritance

    interface withpos
        real x
        real y
    endinterface

    struct rectangle extends withpos
        real a
        real b

        static method from takes real x, real y, real a, real b returns rectangle
         local rectangle r=rectangle.create()
            set r.x=x
            set r.y=y
            set r.a=a
            set r.b=b
            return r
        endmethod

    endstruct

    struct circle extends withpos
        real radius=67.0

        static method from takes real x, real y, real rad returns circle
         local circle r=circle.create()
            set r.x=x
            set r.y=y
            set r.radius=rad
            return r
        endmethod

    endstruct


    function distance takes withpos A, withpos B returns real
     local real dy=A.y-B.y
     local real dx=A.x-B.x

     return SquareRoot( dy*dy+dx*dx)
    endfunction

    function test takes nothing returns nothing
     local circle c= circle.from(12.0, 45.0 , 13.0)
     local rectangle r = rectangle.from ( 12.3 , 67.8, 12.0 , 10.0)

         call BJDebugMsg(R2S(distance(c,r)))

    endfunction

It is possible to acquire the type id of an instance of an struct that extends an interface, this type id is an integer number that is unique per struct type that extends that interface.

interface A
    integer x
endinterface

struct B extends A
    integer y
endstruct

struct C extends A
    integer y
    integer z
endstruct

function test takes A inst returns nothing
   if (inst.getType()==C.typeid) then
     // We know for sure inst is actually an instance of type C
       set C(inst).z=5 //notice the typecast operator
   endif
   if (inst.getType()==B.typeid) then
       call BJDebugMsg("It was of type B with value "+I2S( B(inst).y  ) )
   endif
endfunction

In short, .getType() is a method that you use on instances of an object whose type extends an interface. And .typeid is an static constant set for struct types that extend an interface.

So, in the example we get to recognize that the given inst argument is of type C, then we can do the typecast and assignment.

There is another feature that uses typeids got another feature, and it is that interfaces got a constructor method that would create a new object given a correct typeid.

For example:

interface myinterface
    method msg takes nothing returns string
endinterface

struct mystructA extends myinterface
    method msg takes nothing returns string
        return "oranges"
    endmethod
endstruct

struct mystructB extends myinterface

   string x
   static method create takes nothing returns mystructB
    local mystructB m=mystructB.allocate()

       set m.x="apples"

       return m
   endmethod

   method msg takes nothing returns string
       return this.x
   endmethod
endstruct

struct mystructC extends myinterface
   string x

   //myinterface.create(...) can only use the default allocator or custom create
   //methods that take nothing.
   //
   //this declaration is not going to be taken into account if mystructC
   //is used in myinterface.create(...)
   //
   static method create takes string astring returns mystructC
    local mystructB m=mystructB.allocate()

       set m.x=astring

       return m
   endmethod

   method msg takes nothing returns string
       return this.x
   endmethod
endstruct

function test takes nothing returns nothing
 local integer T = mystructB.typeid
 local myinterface A


    set A=myinterface.create(mystructA.typeid) //this is not that useful since mystructA.create() does the same
    call BJDebugMsg(A.msg())

    set A=myinterface.create(T) //this is more useful, we can create objects of variable types...
    call BJDebugMsg(B.msg())

    set A=myinterface.create(122345) //using invalid values or 0 will make .create return 0 (no object)

    set A=myinterface.create(mystructC.typeid) //note that this will not use mystructC.create, just 
                                               //mystructC.allocate, possibly causing errors, if this
                                               //happens you can an error message in-game if you compile under debug mode

    call BJDebugMsg(C.msg())

endfunction

If you plan using this feature, always be careful to handle 0 return values and also specify that it is better to use constructors without arguments on the interface's children.

It is also possible to declare the interface in a way that all the childs use a custom create method that returns nothing.

interface myinterface
    static method create takes nothing

    method qr takes unit u returns nothing
endinterface

struct st1 extends myinterface

    static method create takes nothing returns st1 //legal
        return st1.allocate()
    endmethod

    method qr takes unit u returns nothing
        call KillUnit(u)
    endmethod
endstruct


struct st2 extends myinterface
 integer k

    static method create takes integer f, integer k returns st2 //not legal
     local st2 s=st2.allocate()
        set st2.k=f+k*f
     return st2
    endmethod

    method qr takes unit u returns nothing
        call ExplodeUnitBJ(u)
    endmethod
endstruct

Interface methods allow you to use the defaults keyword. The defaults keyword allows methods to be optional when implementing the child struct. So if the method is not present in the child struct it will not show syntax errors requesting the method to be implemented. Instead we will implement a default empty method.

defaults is followed by "nothing" or by a value depending on the return type of the method (if the method returns nothing then it should default nothing, else it should default a value). defaults only supports constant values.

interface whattodo
    method onStrike takes real x, real y returns boolean defaults false
    method onBegin  takes real x, real y returns nothing defaults nothing

    method onFinish takes nothing returns nothing
endinterface

struct A extends whattodo //don't forget the extends...

    method onFinish takes nothing returns nothing //must be implemented
        //.. code
    endmethod

    // We are allowed to add onBegin, but not forced to
    method onBegin takes real x, real y returns nothing

        //.. code 
    endmethod

    // when somebody calls .onStrike on a whattodo of type A, it will return false
endstruct

struct B extends whattodo
    method onFinish takes nothing returns nothing //must be implemented
        //.. code
    endmethod

    // when somebody calls .onBegin on a whattodo of type A, it will do nothing
endstruct

Operator making

Jasshelper allows you to declare custom operators for your structs, these operators would then be converted to method calls, vJass currently allows operators for <, > , array set and array get.

The official name for this process (In wikipedia and books) is operator overloading. In the case of vJass, An overloaded operator is a method, but it gets operator as name, after the operator keyword you specify the operator being overloaded.

An example is worth 1000 words:


    struct operatortest
        string str=""

        method operator [] takes integer i returns string
            return SubString(.str,i,i+1)
        endmethod

        method operator[]= takes integer i, string ch returns nothing
            set .str=SubString(.str,0,i)+ch+SubString(.str,i+1,StringLength(.str)-i)
        endmethod

    endstruct


    function test takes nothing returns nothing
     local operatortest x=operatortest.create()
        set x.str="Test"
        call BJDebugMsg( x[1])
        call BJDebugMsg( x[0]+x[3])

        set x[1] = "."
        call BJDebugMsg( x.str)
    endfunction


By this example we are overloading the [] operator and giving it a new function for the objects of type operatortest. The operator [] specifies the replacement for array get and []= is the replacement for array get.

After inspecting the code you may notice that we are making the string function as an array of strings (or actually characters)

The [] operator requires 1 argument (index), the []= operator requires 2 arguments (index and value to assign). [] must return a value.

[] and []= operators can also be declared as static. This might have some uses, the struct name is going to be allowed to use index operators.

There is a lot of criticism towards operator overloading since it allows programmers to make code that does not make sense, please use this feature with responsibility.

You can also overload < and > , notice that there is only syntax to declare < by declaring it you are forcefully determining an order relation for structs of that type. So it automatically makes > based on your < declaration.


    struct operatortest
        string str=""

        method operator [] takes integer i returns string
            return SubString(.str,i,i+1)
        endmethod

        method operator[]= takes integer i, string ch returns nothing
            set .str=SubString(.str,0,i)+ch+SubString(.str,i+1,StringLength(.str)-i)
        endmethod

        method operator< takes  operatortest b returns boolean
            return StringLength(this.str) < StringLength(b.str)
        endmethod

    endstruct


    function test takes nothing returns nothing
     local operatortest x=operatortest.create()
     local operatortest y=operatortest.create()

        set x.str="Test..."
        set y.str=".Test"

        if (x<y) then
            call BJDebugMsg("Less than")
        endif
        if (x>y) then
            call BJDebugMsg("Greater than")
        endif
    endfunction


In the example, an object of type operatortest is considered greater than another object of that type if the length of its str member is greater than the length of the other object's str member.

operator< must return a boolean value and take an argument of the same type as the struct.

Operators are interface friendly meaning that an interface may declare operators, there is a catch and it is that the operator< must be declared without signature in an interface. Also when using > or < to compare interface objects both instances must have the same type, otherwise the function would halt before performing the comparisson, if debug mode was enabled when compiling, it will also show a warning message.

    interface ordered
        method operator <
    endinterface

    interface indexed
        method operator [] takes integer index returns ordered
        method operator []= takes integer index, ordered v returns nothing
    endinterface

    function sort takes indexed a, integer from, integer to returns nothing
     local integer i
     local integer j
     local ordered aux

        set i=from
        loop
            exitwhen (i>=to)
            set j=i+1
            loop
                exitwhen (j>to)
                if (a[j]<a[i]) then
                    set aux = a[i]
                    set a[i] = a[j]
                    set a[j] = aux
                endif
                set j=j+1
            endloop

            set i=i+1
        endloop
    endfunction

This is an interface for a sorting algorithm. We may now declare custom types that work to sort stuff:


    struct integerpair extends ordered
        integer x
        integer y

        method operator< takes integerpair b returns boolean
            if (b.x==this.x) then
                return (this.y<b.y)
            endif
            return (this.x<b.x)
        endmethod
    endstruct

    type ipairarray extends integerpair array [400]

    struct integerpairarray extends indexed
        ipairarray data

        method operator[] takes integer index returns ordered
            return ordered( this.data[index] )
        endmethod

        method operator[]= takes integer index, ordered value returns nothing
            set this.data[index] = integerpair( value)
        endmethod
    endstruct

Of course, it is just an example, the logical way would be using quicksort, operators are also good since they would also allow textmacros to use them, the same sorting textmacro might then be compatible with integer, real and any struct with overloaded < operator.

You may also declare a custom ==, works same as < if you declare this operator, != will be translated to not(your method). Also, notice that to do pointer comparisons you will need to use integer(var1)==integer(var2)

More things we can do with custom operators

One thing is to overload [], >, <, you can also make a method mimic a field, to keep abstraction and simplify syntax.

struct X
    integer a=2
    integer b=2

    method operator x takes nothing returns integer
        return this.a*this.b
    endmethod

    method operator x= takes integer v returns nothing
        set this.a=v/this.b
    endmethod


endstruct



function test takes nothing returns nothing
 local X obj= X.create()

    set obj.x= obj.x + 4

    call BJDebugMsg(I2S( obj.x) ) //outputs 8
    set obj.b=4

    call BJDebugMsg(I2S( obj.x) ) //outputs 16

endfunction

You can use this to implement read only fields:

struct X
    private integer va=2

    method operator a takes nothing returns integer
        return this.a
    endmethod

endstruct



function test takes nothing returns nothing
 local X obj= X.create()

    call BJDebugMsg(I2S( obj.a) ) //This is legal

    set obj.a=2 //this is not

endfunction

More importantly, you can use it to implement fields that take extra provisions for assigments:

struct movableEffect

    private unit dummy
    private string rfx
    private effect uniteffect

    //...
        //(A lot of code implementing other actions and creation)
    //...

    method operator x takes nothing returns real
        return GetUnitX(this.dummy)
    endmethod

    method operator y takes nothing returns real
        return GetUnitY(this.dummy)
    endmethod

    method operator x= takes real value returns nothing
        call SetUnitX(this.dummy, value)
    endmethod

    method operator y= takes real value returns nothing
        call SetUnitY(this.dummy, value)
    endmethod


    method operator effectpath takes nothing returns string
        return this.rfx
    endmethod

    method operator effectpath= takes string path returns nothing
        set this.rfx=path
        call DestroyEffect( this.uniteffect)
        set this.uniteffect = AddSpecialEffectTarget(this.dummy, path, "origin")
    endmethod

endstruct


function moveRandom takes movableEffect me returns nothing
    set me.x= me.x + GetRandomReal(-50,50)
    set me.y= me.y + GetRandomReal(-50,50)
endfunction

function toFire takes movableEffect me returns nothing
    set me.effectpath ="war3mapimporte\\cutefireeffect.mdl"
endfunction

Hint: With operators like .fieldname= and []= it is possible to have a return value in the method, however this return value would almost always be impossible to get from outside the function, there is an exception, and it is when these methods return a value of the struct's type, then it will get translated to an assignment. For example, instead of call var_set(object,45), the result would be set object=var_set(object,45)

Note: Since 0.9.Z.1, this syntax is also supported for static members.

Extending structs

It is possible to base an struct from a previously declared struct, by doing this your new type is going to acquire methods and variable members of the base struct, it is also able to use instances of this type with functions and variables of the base type.

Consider doing this as a way to add code and properties to a previous type.

struct A
   integer x
   integer y

   method setxy takes integer cx, integer cy returns nothing
       set this.x=cx
       set this.y=cy
   endmethod
endstruct

struct B extends A
   integer z
   method setxyz takes integer cx, integer cy, integer cz returns nothing
       call this.setxy(cx,cy) //we can use A's members
       set this.z=cz
   endmethod
endstruct

Internally, B.allocate() is actually calling A's constructor and B.destroy will also call B's deconstructor. If a base struct got a custom create method, the structs extending it will have to use it for allocate(). If the custom create method requires arguments, the allocate method for child structs will require the same arguments:

struct A
   integer x
   static method create takes integer k returns A
    local A s=A.allocate()
       set A.x=k
    return s
   endmethod
endstruct

struct B extends A
    static method create takes nothing returns B
        return s= B.allocate(445)  //notice that B.allocate requires the same arguments as A.create()
    endmethod
endstruct

struct C extends B //yep, it is possible to extend an struct that is extending another one
    static method create takes nothing returns B
     local C s=C.allocate() //C is a child of B that got a custom create method that takes nothing, so allocate takes nothing as well.
       set s.x=s.x*s.x //once again reusing the parents' members.
     return s
    endmethod
endstruct

If an struct has declared create to be private, it is impossible to extend it. Structs cannot use private members from parent structs.

The behaviour of the onDestroy method is special in this case, if in the last example, A,B and C had an onDestroy method each, destroying an instance of a C would call C.onDestroy(), B.onDestroy() and A.onDestroy() (in that order)

It is possible to extend an struct that extends an interface, in this case, the child that extends the interface directly is forced to implement the interface's methods, but its childs are not. But it is possible for them to replace them again.

interface myinterface
   method processunit takes unit u returns nothing
   method onAnEvent takes nothing returns boolean
endinterface

struct A extends myinterface

   method processunit takes unit u returns nothing
       call KillUnit(u)
   endmethod

   method onAnEvent takes nothing returns boolean
       return false
   endmethod
endstruct

struct B extends A

   method processunit takes unit u returns nothing
      //we have just replaced A&apos;s processunit method,
      //if an interface variable of type myinterface holds an instance of 
      //type B it will explode the unit.
      call ExplodeUnitBJ(u)
   endmethod
   // we are implementing processunit but we do not have to implement onAnEvent   

endstruct

If you plan using interface.create() you will have to be careful once again about constructors with arguments, if an interface is declared with the condition that create takes nothing every child (,grandchild, etc) of the interface will be affected by this condition.

Stub methods

stub methods can simply be rewriten by child structs. An example should help:

struct Parent

    stub method xx takes nothing returns nothing
        call BJDebugMsg("Parent")
    endmethod

    method doSomething takes nothing returns nothing
        call this.xx()
        call this.xx()
    endmethod

endstruct

struct ChildA extends Parent
    method xx takes nothing returns nothing
        call BJDebugMsg("- Child A -")
    endmethod
endstruct

struct ChildB extends Parent
    method xx takes nothing returns nothing
        call BJDebugMsg("- Child B --")
    endmethod
endstruct


function test takes nothing returns nothing
 local Parent P = Parent.create()
 local Parent A = ChildA.create()
 local Parent B = ChildB.create()
    //notice the variables are of the 'Parent' type.
    call P.doSomething() //Shows 'Parent' twice
    call A.doSomething() //Shows 'Child A' twice
    call B.doSomething() //Shows 'Child B' twice
endfunction

 

Just notice there are differences between these and interfaces, first of all, interfaces require you to make the methods. They also allow the .exists().

super

When you are extending another struct, it could happen that the struct is extending an interface, or that the method you are coding is replacing a stub method. What happens if you want to call the parent's version of the method? It is not possible without specifying that you want to do it. (Else it will end up calling the child's method instead).

super is meant to allow that, it works in the same way as this, but it forces the parent's method to be called:

struct Parent

    stub method xx takes nothing returns nothing
        call BJDebugMsg("Parent")
    endmethod

    method doSomething takes nothing returns nothing
        call this.xx()
        call this.xx()
    endmethod

endstruct

struct ChildA extends Parent
    method xx takes nothing returns nothing
        call BJDebugMsg("- Child A -")
        call super.xx()
    endmethod
endstruct

struct ChildB extends Parent
    method xx takes nothing returns nothing
        call BJDebugMsg("- Child B --")
    endmethod
endstruct


function test takes nothing returns nothing
 local Parent P = Parent.create()
 local Parent A = ChildA.create()
 local Parent B = ChildB.create()
    //notice the variables are of the 'Parent' type.
    call P.doSomething() //Shows 'Parent' twice
    call A.doSomething() //Shows 'Child A|nParent' twice
    call B.doSomething() //Shows 'Child B' twice
endfunction

 

Dynamic arrays

Dynamic arrays are arrays you can instanciate dynamically, EACH custom array type has got a limit of 8190 TOTAL indexes, that means that an array type of size 100 has got an 81 instances limit.

They are kind of easy to declare and use, and somehow share syntax with structs.

You simply make a line outside any function/struct declaration: type <nameoftype> extends <nameofbasetype> array [ <size>] Where size is an integer value or constant global.

Then you can simply create/usem them in a similar way to structs and use the [] operator to access its indexes, dynamic arrays have also got an static size constant

type arsample extends integer array[8]

function test takes nothing returns arsample
 local arsample r=arsample.create()
 local integer i=0
     loop
         exitwhen i==arsample.size //holds size of the array type
         set r[i]=i
         set i=i+1
     endloop
 return r
endfunction

function test2 takes nothing returns arsample
 local arsample r=test()
 local integer i=0
     loop
         exitwhen i==arsample.size
         call BJDebugMsg(I2S(r[i]))
         set i=i+1
     endloop
 return r
endfunction

You can extend arrays of any type, even of custom types (structs, interfaces, other dynamic arrays) thus making a dynamic array of dynamic arrays, a matrix like syntax is possible:

type iar extends integer array[3]
type iar_ar extends iar array[3]

function test takes nothing returns arsample
 local iar_ar r=iar_ar.create()
 local integer i=0
 local integer j
     loop
         exitwhen i==iar_ar.size //holds size of the array type
         set r[i]=iar.create()
         set j=0
         loop
             exitwhen j==iar.size
             set r[i][j]=j*i
             set j=j+1
         endloop

         set i=i+1
     endloop
 return r
endfunction


And structs may have these arrays as members thus allowing array members for instances (non-static)


type stackarray extends integer array [20]

struct stack
   private stackarray V
   private integer N=0

   method Create takes nothing returns stack
    local stack s=stack.create()
       set s.V=stackarray.create()
       if (s.V==0) then
           debug call BJDebugMsg("Warning: not enough space for stack array")
           return 0
       endif
   endmethod

   method push takes integer i returns nothing
       if (this.N==stackarray.size) then
           debug call BJDebugMsg("Warning: stack is full")
       else
           set this.V[this.N]=i
           set .N = .N +1 //remember this syntax is valid as well
       endif
   endmethod

   method pop takes nothing returns nothing
       if (this.N>0) then
           set this.N=this.N-1
       else
           debug call BJDebugMsg("Warning: attempt to pop an empty stack");
       endif
   endmethod

   method top takes nothing returns integer
       return .V[.N-1]
   endmethod

   method empty takes nothing returns boolean
       return (.N==0)
   endmethod

   method onDestroy takes nothing returns nothing
       call this.V.destroy()
   endmethod
endstruct

As you may notice, if there is no space for a new instance, the create method of arrays returns 0. It will also warn you automatically if compiled in debug mode

Dynamic arrays got the .size member that allows you to easily access the size you used to declare the array type.

Array members

Structs may have array members but you also require to declare the size of them.

struct stack
   private integer array V[100]
   private integer N=0

   method push takes integer i returns nothing
      set .V[.N]=i
      set .N=.N+1
   endmethod

   method pop takes nothing returns nothing
      set .N=.N-1
   endmethod

   method top takes nothing returns integer
      return .V[.N-1]
   endmethod

   method empty takes nothing returns boolean
      return (.N==0)
   endmethod

   method full takes nothing returns boolean
      return (.N==.V.size)
   endmethod

endstruct

In some way, this is syntax candy for declaring a new array type and making it a member of the struct, but this way is a little more optimizer and handles the array allocation/deallocation for you, with the exchange of some limitations.

Notice that this drastically reduces the instances limit of an struct type, for example, we can only have 80 instances (8190 div 100) of the above declared stack object.

An struct may have as many array members as you can type, notice that the array with the maximum size is the one considered when setting the instances limit, so if an struct has 2 array members, one of size 4 and one of size 100, the struct will have a limit of 80 instances.

The disadvantage of this method over declaring the dynamic array type separatedly is that you have less freedom in what concerns assigning to the member another array you create in other occation and things like that... The advantage is that it is faster and takes less code.

As dynamic arrays, array members may also use the .size field.

Delegate

So far, we've seen many things, interfaces, structs extending other structs, operators, dynamic arrays. You might be asking yourself, is it possible he would add another way to confuse me like heck? Do not despair! Delegate is the answer.

delegate is a strange feature, a delegate is just a member of the struct that does stuff for it. The struct just delegates the work to another object, in this case, work would mean 'methods'. It would appear as pointless or just an abbreviation, however it can be very useful and a interesting alternative to extends. The whole delegate idea is in use in some other languages, just notice that Jass is not very dynamic and vJass does inherit a lot of its flaws. For the better or the worse, delegation is a completely compile-time deal in the case of vJass.

A delegate does the struct's job, that is a very simple way to put it, a more complicated way would be, that during compile, if jasshelper cannot find a certain requested member of method, it will begin to look up for that member in the struct's delegates, if it finds this member in one of the delegates it will then compile it as a call to the delegate's member instead.

//Array structs are hard to explain, but should be simple to understand with an example

struct A
    private real x
    private real y

    public method performAction takes nothing returns nothing
        call DestroyEffect( AddSpecialEffect("path\\model.mdl", this.x, this.y) )
    endmethod

endstruct

struct B
    delegate A deleg

    static method create takes nothing returns B
     local B b = B.allocate()
        set B.deleg = A.create()
    endmethod

endstruct

function testsomething takes nothing returns nothing
 local B myB = B.create()

    call myB.performAction()

    //Since performAction() is not a member of struct B, jasshelper will check out the
    //delegator, it does have a method called performAction, so it will just try to call
    //it, the result would be the same as:

    call myB.deleg.performAction()

endfunction

 

Some considerations:

  • You can have multiple delegates, however that should probably be the exception rather than the rule.
  • jasshelper gives priority to the struct's members before its delegates' this means that if both the struct and a delegate have the same member, jasshelper will always consider the struct's over the delegate's.
  • Between delegates in the same struct, the priorities are the same as the declaration order.
  • You can do a lot of quacky things like delegating to an array member, you will even be able to use .size() and [] on the struct in that case.
  • You can also do non-sense as making a integer member a delegate, this will not cause a syntax error but does not really do much by itself, considering that integers have no members.
  • Right now, you cannot make a delegate's method fulfill a interface's rules, for example if struct B was extending a certain interface that required a method called performAction, jasshelper would not recognize the delegate's method and will cause a syntax error, this might change in the future.

  • You would usually have to initialize the delegate if you do not want bugs in your code.
  • You can have a private delegate, it would only be accessible by outside code in cases where a member is necessary.
  • If you try to call/use a delegate's private member, it will probably appear as a syntax error about not being able to find it in the struct rather than telling you that it is a private member of the delegate.

thistype

The thistype keyword behaves exactly as the struct's name in code that is inside a struct.

//The next code,
struct test 
    thistype array ts
    method tester takes nothing returns thistype
        return thistype.allocate()
    endmethod
endstruct

//Is equivalent to:

struct test 
    test array ts
    method tester takes nothing returns test
        return test.allocate()
    endmethod
endstruct

The intended usage for thistype, is when it is actually necessary, e.g: textmacros, modules. I do not endorse the idea of people using this so they can rename the struct later, but I guess they are allowed to.

Module

A module is like a code package you can place in a struct to gain extra methods or members, etc. module, ..., endmodule are used to declare a module and implement is used to copy the module's members to the struct. Consider this as a high level textmacro.

methods in modules can call/use methods/members that belong to the struct (which could be private), just notice that if the struct does not have such members, a syntax error would pop up as if you were pasting the module's code into the struct. A module's private members will not be visible to the calling struct and their names will not conflict with other members in the struct, there are some exceptions, however: create, and onDestroy which will be handled differently later. You cannot have private operators in modules (operators are often meant for public APIs so it does not make any sense to make them private anyway).

Since Jasshelper 0.9.Z.1, private onInit methods inside a module will be executed on init once per struct implementing it. Multiple onInit methods from multiple modules can coexist with the struct's onInit method as well.


///
// Declare the module, similar to a struct declaration
//
module MyRepeatModule

    method repeat1000 takes nothing returns nothing
     local integer i=0
        loop
            exitwhen i==1000
            call this.sub() //a method that is expected
                            //to exist in the struct
            set i=i+1
        endloop
    endmethod

endmodule

// the struct :
struct MyStruct
    method sub takes nothing returns nothing
        call BJDebugMsg("Hello world")
    endmethod
    implement MyRepeatModule //adds the module.

endstruct

function MyTest takes MyStruct ms returns nothing
    call ms.repeat1000() //will call ms.sub 1000 times.
endfunction

You can call other modules from inside a module using implement, adding the keyword optional after implement will make them module implementation optional, that is if the module cannot be found, no error will show up, vJass will just ignore the implement call. Another useful idea is to use thistype when necessary. If implement attempts to implement a module that has already been implemented in a struct, the call is ignored as well.

A module's contents obey the scope rules from the scope/library in which it is declared (if any).


module MyOtherModule

    method uhOh takes nothing returns nothing
    endmethod
endmodule

///
// Declare the module, similar to a struct declaration
//
module MyModule

    //next line adds a member uhOh that does nothing
    implement optional MyOtherModule

    //since OptionalModule is not declared, next line is ignored
    implement optional OptionalModule

    // This method call requires that the struct had
    //  a copy() method
    static method swap takes thistype A , thistype B returns nothing
     local thistype C = thistype.allocate()
     //we are from the inside, so can use allocate, even though it is private

        call C.copy(A)
        call A.copy(B)
        call B.copy(C)
        call C.destroy()
        
    endmethod

endmodule

// the struct :
struct MyStruct
    integer a
    integer b
    integer c

    //code a copy method
    method copy takes MyStruct x returns nothing
        set this.a = x.a
        set this.b = x.b
        set this.c = x.c
    endmethod

    //get the swap method "for free"
    implement MyModule
    implement MyOtherModule //this module was already include by MyModule, so this line is ignored

endstruct

function MyTest takes MyStruct A, MyStruct B returns nothing
    call MyStruct.swap(A,B) //it now got that method afterall
endfunction

Functions as objects

For vJass functions may behave as objects with 2 methods: evaluate and execute, both methods got the same arguments list as the function, and evaluate got its return value as well.

Using functions as objects has a couple of advantages, evaluate() allows you to call the function even from code that is above its function declaration, execute allows the same but it is also able to run the function in another thread.

The disadvantages are: Functions that are used with evaluate(), should not use GetTriggeringTrigger() (but you may use any other event response) or any sync native, evaluate() does not support waits, and evaluate() is slower than a normal function call.

.execute() is actually faster than good old ExecuteFunc, and in later versions it might actually get even faster. evaluate halves the duration of ExecuteFunc and it may get much better later.

For functions that have function arguments you would have to use global variables to pass arguments when using ExecuteFunc, .execute and .evaluate will pass the arguments directly.

function A takes real x returns real
 if(GetRandomInt(0,1)==0) then
    return B(x*0.02)
 endif
 return x
endfunction

function B takes real x returns real
 if(GetRandomInt(0,1)==1) then
    return A(x*1000.)
 endif
 return x
endfunction

These are mutually recursive functions, and with normal Jass this would give a syntax error, in order to prevent this issue you may use evaluate:

function A takes real x returns real
 if(GetRandomInt(0,1)==0) then
    return B.evaluate(x*0.02)
 endif
 return x
endfunction

function B takes real x returns real
 if(GetRandomInt(0,1)==1) then
    return A(x*1000.)
 endif
 return x
endfunction

Let us say you need to destroy an special effect after waiting x seconds using a wait. You could use a timer but for example sake we are going to use a normal wait, we do not want to stop execution of the function calling this effect destroying function so we need a new thread:

function DestroyEffectAfter takes effect fx, real t returns nothing
    call TriggerSleepAction(t)
    call DestroyEffect(fx)
endfunction

function test takes nothing returns nothing
 local unit u=GetTriggerUnit()
 local effect f=AddSpecialEffectTarget("Abilities\\Spells\\Undead\\Cripple\\CrippleTarget.mdl",u,"chest")

  call DestroyEffectAfter.execute(f,3.0)

  set u=null
  set f=null
endfunction

Note: This feature is currently limited to functions declared in the map script, you cannot use it with common.j natives or blizzard.j functions yet.

The .name member in functions will return a string containing the function's compiled name, useful when you want to use a scope function in things like ExecuteFunc.

scope test
    public function xxx takes nothing returns nothing
        call BJDebugMsg(xxx.name) //will show "test_xxx"
    endfunction
endscope

Function interfaces

If functions are objects then we may as well have interfaces for them.

The syntax for function interfaces is: function interface name takes (arguments) returns (return value)

It is actually similar to a function declaration.

Variables/values of a function interface type may be called using execute() and evaluate() as defined above:

To assign to variables of a function interface type you first need to get a function's pointer. The syntax to get them is understandable if you assume that every declared function interface will get as static members the functions found in the map script that follow its argument/return value rules.

function interface Arealfunction takes real x returns real

function double takes real x returns real
    return x*2.0
endfunction

function triple takes real x returns real
    return x*2.0
endfunction

function Test1 takes real x, Arealfunction F returns real
    return F.evaluate(F.evaluate(x)*F.evaluate(x))
endfunction

function Test2 takes nothing returns nothing
 local Arealfunction fun = Arealfunction.double //syntax to get pointer to function

   call BJDebugMsg( R2S(  Test1(1.2, fun) ))

   call BJDebugMsg( R2S(  Test1(1.2, Arealfunction.triple ) )) //also possible...
endfunction

In this example we are actually having functions as arguments and as a variable. You may also typecast(see bellow) a function pointer to integer and then back to the interface function it originated.

It is also possible to get a function pointer without typing the interface's name, notice that this will not allow you to validate the function as following the interface's declaration, but it is simpler nontheless.:/

//repeat a call of the same function on a real variable thrice!

function double takes real x returns real
    return 2*x
endfunction

function square takes real x returns real
    return x*x
endfunction

   function interface realfunc takes real x returns real

function repeater3 takes real x, realfunc F returns real
    set x=F.evaluate(x)
    set x=F.evaluate(x)
    set x=F.evaluate(x)
    return x
endfunction

function test takes nothing returns nothing
 local real x = repeater3( 2.0, double) //notice we are just using the functions' names as if they were values.
 local real y = repeater3( 2.0, square)

   //The results are x=16 and y=256.
   //explanation: the first is equivalent to:
   //    set x=2
   //       set x=2*x
   //       set x=2*x
   //       set x=2*x
  
   // While the second is:
   //    set y=2
   //       set y=y*y
   //       set y=y*y
   //       set y=y*y

 // yep, function interfaces allow you to use functions as if they were just another sort of variable.
endfunction

You may also use methods for function interfaces, the static method gets converted into a function pointer.

    function interface myFunc takes integer a, integer b returns nothing

    struct try
        static method AAAA takes integer a, integer b returns nothing
           call BJDebugMsg( I2S(a)+", "+I2S(b) )
        endmethod

        method ooz takes nothing returns nothing
           local myFunc fun = try.AAAA
              call fun.evaluate(5,6)
              call fun.evaluate(7,8)
        endmethod
    endstruct

Notice that non-static methods are usable as well for function interfaces. They behave as functions that take an integer in the first argument though.

When using non-static methods as function pointers, you are just converting them into functions that take an integer as first argument, the function pointer instance will require one of the struct's instances to get called.

function interface myFunc takes integer x returns nothing


struct TestStruct
    string msg
    method AAAA takes nothing returns nothing
       call BJDebugMsg(msg)
    endmethod
endstruct

function test takes nothing returns nothing
 local TestStruct ts = TestStruct.create()
 local myFunc mf
    set ts.msg = "!!! !!! !!! !!! "

    set mf = TestStruct.AAAA

    call mf.evaluate(ts ) //notice that we are explicitly feeding the function a instance

endfunction


 

Typecast

For the moment, assigning a value of an struct type to an integer variable / or variable of any other struct type will already change the type of that reference for the compiler

Notice that sometimes using a variable might get tedious or even create unneeded overhead, that is the reason the type cast operator was added.

Its syntax is mostly like a function but the name of the function is the name of a custom type. It will soon allow native types as well.

interface  wack
    //... some declarations
endinterface

struct wek extends wack
   integer x
   // some more declarations
endstruct

function test takes wack W returns nothing
   //You are certain that W is of type wek, a way to cast the value is:
 local wek jo = W
   set jo.x= 5 //done

   // but sometimes creating a variable is too much work for the virtual machine and you
   // are only accessing it once 

   set wek(W).x=5 //also works.
endfunction


type anarrayofdata extends integer array [6]

function getdata5 takes unit u returns integer
    //a reference to an object of type anarrayofdata is saved as the unit's custom value
    return anarrayofdata(GetUnitUserData(u))[5]
endfunction

function setdata5 takes unit u, anarrayofdata x returns nothing
    // Here we are doing the opposite, notice that integer may be used as a type cast
    // operator for struct and dynamic array types.
    call SetUnitUserData(u,  integer(x))
endfunction

Method function name

Methods may work as objects to use the .execute()/.evaluate() feature, they may also work as objects to allow access to the name field. This .name field will return the function name given to a method after the compiling.

This is specially useful in case you want to use an struct's static method on an ExecuteFunc based system.



struct mystruct
    static method mymethod takes nothing returns nothing
        call BJDebugMsg("this works")
    endmethod
endstruct

function myfunction takes nothing returns nothing
    call ExecuteFunc(mystruct.mymethod.name) //ExecuteFunc compatibility

    call OnAbilityCast('A000',mystruct.mymethod.name)
    //for example, caster system's OnAbilityCast, requires a function name
endfunction

Method exists

Another field used by methods is the exists field, it is a boolean field that returns true if the method has been declared or false otherwise. Most of the times it would be true, the only case whatsoever in which it could be false is if the struct is extending a interface that uses defaults for the method.

interface myInterface
    method myMethod1 takes nothing returns nothing
    method myMethod2 takes nothing returns nothing
endinterface

struct myStruct
    method myMethod1 takes nothing returns nothing
        call BJDebugMsg("er")
    endmethod
endstruct

function test takes nothing returns nothing
 local myInterface mi = myStruct.create()
    //outputs:
    // yes
    // no
    if( mi.myMethod1.exists) then
        call BJDebugMsg("Yes")
    else
        call BJDebugMsg("No")
    endif
    if( mi.myMethod2.exists) then
        call BJDebugMsg("Yes")
    else
        call BJDebugMsg("No")
    endif

endfunction

Array structs

Sometimes, you'd like to have a global array of a struct type, just to be able to have that field syntax we all like so much, it can be more complicated than it is supposed to, for example you have to manually initialize all the indexes to create the unique indexes, etc. Another issue is when you do not really want to use .allocate() and .destroy() you would like to have your own ways for allocation. Array structs are a small syntax enhancement that is equivalent to an array of a struct type, you would be able to use the members for each index and you will not have to worry about .create().

//Array structs are hard to explain, but should be simple to understand with an example

struct playerdata extends array //syntax to declare an array struct
    integer a
    integer b
    integer c
endstruct

function init takes nothing returns nothing
 local playerdata pd

    set playerdata[3].a=12  //modifying player 3's fields.
    set playerdata[3].b=34  //notice it behaves as a global array
    set playerdata[3].c=500

    set pd=playerdata[4]
    set pd.a=17             //modifying player 4's fields.
    set pd.b=111            //yep, this is also valid
    set pd.c=501
endfunction

function updatePlayerStuff takes player p returns nothing
 local integer i=GetPlayerId(p)

    //some random function.
    set playerdata[i].a=playerdata[i].b

endfunction

Certain issues with array structs: You cannot declare default values (they would automatically be zero, null or false depending on the type of the member) , you cannot declare onDestroy (it would be pointless), you cannot use .allocate or .destroy, you cannot have array members. Notice that the problem with default values and array members are likely to be fixed in a next version.

Notice that you can use operator declarations to override the get [] operator, in this case, to be able to use ids you would be able to use the typecast operator, e.g. playerdata(4) to get the instances. If you did not understand this last paragraph, don't worry, you probably did not need to know this anyway.

Keys

key is a special vJass type that is meant to generate unique integer constants you can use in various ways, it is mostly intended to be used for key generation for warcraft 3's hashtable handle type.

Whenever you use the key type to declare a variable, a unique integer number is assigned to it. You may add the constant keyword for extra readability if you want.

scope Tester initializer test

globals
             key AAAA
    private  key BBBB // yes it is just another type, so you can have
    public   key CCCC // public or private ones...

    constant key DDDD  //correctly describe it as a constant (not necessary)
endglobals


    private function test takes nothing returns nothing
     local hashtable ht = InitHashtable()
        call SaveInteger(ht, AAAA, BBBB, 5)
        call SaveInteger(ht, AAAA, CCCC, 7)
        call SaveReal(ht, AAAA, DDDD, LoadInteger(ht,AAAA, BBBB) * 0.05 )
        call BJDebugMsg( R2S( LoadReal(ht,AAAA,DDDD) ) )

        call BJDebugMsg( I2S(BBBB) ) // will show two numbers, and
        call BJDebugMsg( I2S(CCCC) ) // the numbers will be different...
    endfunction

endscope

Storage enhancers

Introduction

There is an internal limit in Jass regarding array sizes, jasshelper is widely affected by it since it directly affects struct instance limits, for example. There is a way to virtually increase the limit by combining together a number of Jass arrays and translate indexes of the bigger array into indexes of the smaller arrays.

By using storage enhancer syntax you can make Jasshelper do this trick. But there is a catch, by increasing the limit of available indexes you make sacrifices of many kinds:

  • Operations that would usually just need an array lookup would require a function call instead, function calls are very slow in Jass in comparison to array lookups.
  • The function requires to do some extra operations itself, currently the number of operations these functions take depends on (index_limit / 8191), soon a jasshelper improvement might allowe them to do log_2(index_limit/8191), notice that for smaller index limits this improvement is not important.
  • The script size can increase significantly if you use very big index limits, on a lot of objects, for example if your struct got 20 fields and you use an index limit of 60000, the compiled script will require 40 new functions each with a little more than 16 lines.

Some Jass applications will require more space which means you would have to use enhancers regardless of the limitations, in case you do not really need more space, using these enhancers is discouraged because of the cons described above, if you are making a flexible system that might or might not require these enhancements you can make the enhancer usage optional, because space syntax allows you to use constant variables in its declaration you can make the user able to determine it, if you use size enhancer syntax to specify a size not bigger than 8191 (or 8190 in the case of structs, since you also need the 0 instance) nothing will happen and the penalties described above will not apply.

An internal jasshelper limit forbids a declaration that would require the script to use more than 8 arrays for the same big array, leading to an index space limit of around 408000, if you need more space, request so but include a good description of the (rather crazy) thing you are doing that requires so much space, I am interested in learning about it...

Sized arrays

Global arrays might sometimes require more index space, jasshelper introduces syntax for sized arrays, it serves two purposes: It will allow you to request more space, and it also allows you to place a .size field on global arrays.

globals
    integer array myArray [500]
endglobals

function test takes nothing returns nothing
 local integer i=0

    call BJDebugMsg(I2S(myArray.size)) //prints 500

    loop
        exitwhen i>=myArray.size
        set myArray[i]=i
        set i=i+1
    endloop
endfunction

Of course, you can bypass the 8191 array size limit:


globals
    integer array myArray [9000]
endglobals

You can use a constant as well:

globals
    constant integer Q= 60000
    integer array myArray [Q]
endglobals

You can use this on struct static member arrays. (static integer A[10000])

2D arrays

A quick improvement from sized arrays, is the ability to have two-dimensional arrays, n-dimensional arrays are not implemented, if you really need it very hard, contact me.

Two dimensional arrays in vJass, since vJass is implemented on top of Jass, are just normal arrays in disguise, using a multiplication trick to convert 2-dimension indexes into a one-dimension one. The way to declare one of these arrays is: <type> array name[width][height], notice the real size of the array is width*height, this size suffers the same limitations as normal array's size, it cannot go above approximately 40800, and if this size is bigger than 8191, you will be using slower function calls instead of array lookups and multiple arrays in the final script, etc.

The field size would return this total size we are talking about, the fields height and width return the ones we used to declare the array. As with sized arrays, you can use constants for the width and size.


   globals
       integer array mat1 [10][20]

       constant integer W=100
       constant integer H=200
       integer array mat2 [W][H]

   endglobals

   function test takes nothing returns nothing
    local integer i=0
    local integer j=0
    local integer c=0
       call BJDebugMsg(I2S(mat1.size)) //displays 200 (10 * 20)

       //fill the array:
       loop
           exitwhen (i==mat1.width)
           set j=0
           loop
               exitwhen (j==mat1.height)
               set c=c+1
               set mat1[i][j]=c
               set j=j+1
           endloop

           set i=i+1
       endloop

       call BJDebugMsg( I2S( mat1[0][1]  )  ) //displays 2

       call BJDebugMsg( I2S( mat2.width) ) //displays 100
   endfunction

Structs with more index space

We got a struct X:


struct X
    integer a
    integer b
endstruct

For some reason, the 8190 instances limit is not enough for us, we need 10000 instances ! so:


struct X[10000]
    integer a
    integer b
endstruct

Not to be confused with an instance limit improvement, it is an improvement for index space, both terms are usually equivalent unless there are array members involved:


struct X[10000]
    integer a[2]
    integer b[5]
endstruct

This struct got a maximum instance count of 2000

You cannot specify index space enhancers on structs that extend other structs or interfaces.


struct X[10000] extends Y //bad
    integer a[2]
    integer b[5]
endstruct

interface A[20000] //good
    method a takes nothing returns nothing
endinterface

struct B extends A
    method a takes nothing returns nothing
       call BJDebugMsg("...")
    endmethod
endstruct

struct C[20000] //good
    integer x
endstruct

struct D extends C
    integer y
endstruct

Notice that A,B,C and D got a limit of 20000 indexes.

It is a little different for array structs, since as you can see, you cannot use the [] storage size specifier and extends at the same time. Since 0.9.E.1, it is possible to use array structs with enhanced storage specifying the size after the array keyword:

struct aBigOne extends array [ 20000]
   integer a
   integer b
   integer c
endstruct

function meh takes nothing returns nothing
   set aBigOne[19990].a = 12
endfunction

Dynamic arrays with more index space

Dynamic arrays already use [] to specify the size for each instance, but what if you want to specify the maximum storage space? I was forced to add a comma:


type myDyArray extends integer array [200] //a normal dynamic array type of size 200
                                           //max 40 instances


type myDyArray extends integer array [200,40000] //an enhanced dynamic array type of size 200
                                                 //max 200 instances

Jass Syntax extensions

Colon

This is a new operator that basically allows you to use [] differently, call it a reverse []. Sometimes the logic of a script requires the order to be different in order to make more sense.

function test takes nothing returns nothing
 local integer a=3
 local integer array X

    set X[a]=10 //both of these statements do the same
    set a:X =10

    set X[a] = X[a] + 10 //The same.
    set a:X = a:X +10 

    set X[3]=1000
    set 3:X =1000 //this is invalid syntax, sorry, only use : on variables and stuff like that.

endfunction

Delimited comments

These are the typical /* ... */ comments, that you can use to comment out blocks of code not necessarily ending with a line break. These comments are then just deleted from the map script. You can also nest these comments and do funny things as well...


/* Delimited comments example
 They are a lot more useful than normal
 comments, really

 */
function test takes nothing returns nothing
    call Something( /*5*/ 66) /*We temporarily commented out 5, and replaced it with 66*/

    /*
    call Something( /*5*/ 66)
    */

    // That comment up there contains another delimited comment... /*
    call BJDebugMsg("Notice how the previous comment start was ignored" + /*
    */+"because it was inside a 'normal' comment "+/*
    */+"Also notice how we made the parser skipped the previous "+/*
    */+"line breaks because they were inside a comment"+/*
    */"These comments do not count if they are /*inside a string*/ ... ")


endfunction





 

hook

There are functions that are outside of our control most of the times, like natives and those in blizzard.j. The hook keyword allows us to detect them.

Use hook, the name of the native/bj function and the name of a function or static method and you will be able to detect when that native is called and also capture the arguments given to it.

function onRemoval takes unit u returns nothing
    call BJDebugMsg("unit is being removed!")
endfunction

struct err
    static method onrem takes unit u returns nothing 
       call BJDebugMsg("This also knows that a unit is being removed!")
    endmethod
endstruct

hook RemoveUnit onRemoval
hook RemoveUnit err.onrem //works as well


 

Try the code in some map, in which RemoveUnit is called sometimes and see what happens next time it is called.

There are some limitations for now, if the native/bj function is called by another bj function, the hook does not work when that other bj function gets called.

inject

Certain advanced users might use the world editor yet prefer to have more control over the map script, namely making their own main or config functions, the inject preprocessors allows to replace such functions.

The syntax is: //! inject main/config (...) //! endinject

For example:


//! inject main
   //some function calls may go here

   // this places vjass initializations there, notice structs are first initialized then library initializers
   // are called
   //! dovjassinit


   //other calls may go here

   call InitCustomTriggers() //maybe you want to exploit that world editor function...
//! endinject



The dovjassinit preprocessor may prove very helpful, it is only necessary if there is no call to InitBlizzard in the custom main or if you need to control the position of such initializing of structs and libraries.

//! inject config works the same way only that there is no //! dovjassinit for that case.

Loading structs from SLK files

It is possible to load (convert) an slk into code to be added to the map's script, specifically struct assigments. This can be really useful when a system uses structs to store data, since SLK is a table format it can save some work and make things easier to edit without the manual struct assigning.

The preprocessor to load an slk file is //! loaddata "path.slk" . The file path argument follows exactly the same rules as the ones I already specified in import (including lookup folders)

Both the slk and the struct type to be loaded need to follow very specific rules.

The SLK

The SLK file requires to have an struct name at (row 1, column 1) Then the first row contains field names, the next rows contain a [key] and values for the names specified up there.

stname this is just an example
1 2 3 4 5 6
7 8 9 10 11 12

In the example, the name of the struct type to be loaded is stname, the keys of the instances that will be loaded are 1 and 7, and the rest is information about fields and values.

The struct type

The struct type to be used (in the example, stname) requires a getFromKey static method that returns a value of the struct type.

getFromKey() would simply convert a key value and return an equivalent struct, this is because you often want data structs to be related to something else. (Most of the times the [something else] will be an object id.)

For this example, getFromKey would have to take an integer value

The struct type also requires to have the fields declared in the SLK file, the SLK is not forced to list all the fields of the struct type.

So if we have this struct definition:

struct stname
    integer this
    integer is
    integer just
    integer an
    integer example

    static stname array values

    static method getFromKey takes integer i returns thistype
        if (stname.values[i]==0) then
            set values[i]=stname.create()
        endif
     return stname.values[i]
    endmethod

endstruct

And we also load the SLK from the previous example, the loaded init code would be:

    set s=stname.getFromKey(1)
    set s.this=2
    set s.is=3
    set s.just=4
    set s.an=5
    set s.example=6
    set s=stname.getFromKey(7)
    set s.this=8
    set s.is=9
    set s.just=10
    set s.an=11
    set s.example=12

Notice that this code is then run after the struct and libraries initialization

For a more practical explanation check out the SLK demo included in the JassHelper distribution.

Script optimization

Since version 0.9.A.0 script optimization is available in jasshelper, it is currently enabled by default, in order to disable optimization you can either enable debug mode or use the --nooptimize argument (jasshelper.exe), newgen should get a menu entry for toggling this option added soon.

At the moment the only available optimization is function inlining. More methods shall be added later including some improved versions of some of wc3mapoptimizer's options.

Function inlining

Function inlining will look for function calls that can be inlined and then just convert their calls to a direct usage of the function's contents. In order not to break the normal execution of the map, this is done only in few cases. An example of inlining follows.

function MyFunction takes integer a, integer b returns integer
    return myarray[a]*b
endfunction

function MyOtherFunction takes nothing returns integer
    return MyFunction(3,4)
endfunction

//becomes:

function MyOtherFunction takes nothing returns integer
    return myarray[3]*4
endfunction

Inlining is important because it will reduce the number of function calls and make certain parts of the map script faster, while at the same time it will allow you to write readable code.

How to make a function inlineable? The current algorithm basically follows these rules (which are subject to change to allow more functions to be considered inlineable in the future):

  • The function is a one-liner
  • If the function is called by call the function's contents must begin with set or call or be a return of a single function.
  • If the inlined function is an assigment (set) it should not assign one of its arguments.
  • Every argument must be evaluated once and only once by the function, in the same order as they appear in the arguments list.
  • If the function contains function calls, they should all be evaluated after the arguments UNLESS the function is marked as non-state changing, at the moment some very few native functions and also return bug exploiters are considered as non-state changing.

External Tools

JassHelper allows the //! external preprocessor that let you call other tools on the map after the map is compiled with JassHelper, this way these tools may work the same with grimoire and WEHelper

The preprocessor is //! external EXTERNAL_TOOL_NAME [external arguments]

EXTERNAL_TOOL_NAME must match the name of the tool in the configuration (Either the dialog in the wehelper plugin or the .conf file for the grimoire version)

The text after the external name is optional and is given to the tool as command line arguments.

You may also use the externalblock preprocessor if you want to specify an input that will be send to the external tool in stdin:

//! externalblock EXTERNALNAME ARGUMENTS LIST
//! i These lines will get send to
//! i The tool as stdin
//! i The i and the space after the i are ignored.
  
     //comment and whitespace not to appear in stdin

//! i
//! i That one up there was just an empty line to send to the program
//! endexternalblock

What if the tool supports not stdin but a file? Well, you can make jasshelper save the contents of externalblock in a temp file and then send that file to the tool using $FILENAME$

//! externalblock EXTERNALNAME SOME_ARGUMENTS $FILENAME$ OTHER_ARGUMENTS

If you try this you will find out that some tool makers out there for some strange reason require you to use specific extensions for the provided file names. Well, in that case you may use extension=

//! externalblock extension=lua OBJECTMERGER SOME_ARGUMENTS $FILENAME$ OTHER_ARGUMENTS

The next is kind of a section for programmers:

What kind of tool?

For a tool to work correctly with the external preprocessor it must have a very specific behaviour.

First of all JassHelper will pass these arguments to the tool

  • The map's file path.
  • A tokenized chain of directory paths ( c:/;d:/somepath;c:/anotherlocation/ ) These are the lookup paths used by JassHelper, in order to fix some issues the \ character is replaced with / here.
  • The rest of the line in the external preprocessor. (The tool might or might not have more arguments)

Then the tool must use the 0 code if it was succesful, otherwise return any number different to 0 and should write an error message to either stdin or stderr.

Linebreak fixer.

As a side effect of the parsing necessary for this project it also replaces line breaks inside Jass string literals into properly escaped \n this also fixes an issue with PJass giving the wrong line number if there are strings with linebreaks.

II. Installation

* Supported platforms

This program is currently developped for windows XP SP2, WINE 1.0 (or greater) . It probably works well on older versions of windows in wich warcraft III also runs. Windows XP SP3 probably works as well. It might work on vista but there is no testing for that OS or ability to debug there. Please, notice that though you are able to run in platforms other than windows XP and WINE>=1.0 I might not able to fix bugs you report in them that I cannot reproduce in XP or WINE.

* Jass New Gen Pack

Jass New Gen Pack already comes with JassHelper, although it might not come with the most recent version, in order to update you can simply copy executable\jasshelper.exe to the NewGen Pack"s jasshelper subfolder. You may also update the JassHelper documentation if you wish

It is suggested that you install new gen pack first and then update jasshelper, it may be the case that newgen pack's jasshelper holds the same version of jasshelper then it would not be necessary to update.

In order to get Jass New Gen Pack visit: http://www.wc3campaigns.net/showthread.php?t=90999

* WEHelper Plugin

I decided to stop including the WEHelper plugin in jasshelper's distribution package. If you still use WEHelper you should consider moving to newgen, else you can request me the .dll file for jasshelper. You may also make your own WEHelper plugin and make it use the standalone jasshelper.exe to compile the map. Or you can compile the .DLL file from the sourcecode if you have a delphi compiler.

* Grimoire

You need grimoire 1.2 or greater which includes wehack.dll. Then you have to copy executable\jasshelper.exe to a jasshelper subfolder in grimoire's folder. You also need pJass, locate pJass.exe on grimoire's folder as well. As of grimoire 1.2 you may have to update wehack.lua yourself or wait for a newer grimoire version that will be compatible with the new way jasshelper works.

You will have to copy SFMPQ.dll to the jasshelper folder

* Standalone

executable\jasshelper.exe may also work as an standalone compiler, you require bin\SFMPQ.dll and pjass in the same folder (notice SFMPQ.dll needs to be inside a subfolder called bin), after that simply refer to the command line subsection in the usage section.

If you are gonna call jasshelper.exe from another tool, notice that jasshelper will create and use logs and backups subfolders inside its work folder. jasshelper.conf has priority in the work folder and if it is not found the one in jasshelper's folder is gonna be created and used.

III. Usage

* Newgen Pack

After installing the new jasshelper executable, just open Newgen World Editor as usual, it should now call the new jasshelper version. In order to know more about newgen's jasshelper menu you should probably take a look to newgen's readme file.

* Grimoire

Simply use we.bat to run grimoire, then you'd have to disable the syntax checker and enable the map compiler using the grimoire menus. To use debug mode simply use compiler\compiler debug mode.

Currently, compiler is not called when using testmap, so you must save the map before using the testmap button.

Command line

jasshelper.exe combined with the sfmpq.dll and pjass is able to compile maps without any aid from an editor hack, you might want to know about this if you are on Linux (where WINE allows you to use WorldEditor and jasshelper but not grimoire) or for example if you cannot run grimoire for whatever reason.

The basic command line syntax is:

jasshelper.exe <path_to_common.j> <path_to_blizzard.j> <path_to_map.w3x>

This will make jasshelper to process the source map, and update the map with a new compiled script. You can extract common.j and blizzard.j from the scripts folder in war3patch.mpq.

If instead of three arguments you pass four file arguments to the program, the behavior changes:

jasshelper.exe <path_to_common.j> <path_to_blizzard.j> <path_to_mapscript.j> <path_to_map.w3x> 

It will ignore the map's script file, and instead consider the given script file as the vJass source. Since the 3 files syntax removes the original vJass source code from the map, this method is more useful, you can generate the source map by exporting the map's script from the editor. (Hint: Use //! import and //! novjass in combination to command line jasshelper and World Editor)

Of course, that is not enough flexibility, so jasshelper supports a couple of options you can place before the path to blizzard.j:

  • --debug : This flag will make jasshelper compile in debug mode (more information in the quite extense vJass section). It also turns --nooptimize on.
  • --nopreprocessor : If for some reason you just want to check normal Jass syntax, and call PJass using jasshelper as proxy, so you can use this option.
  • --nooptimize : Disables optimization, refer to the script optimization section for more information.
  • --scriptonly : This one changes the behavior of the next arguments, it forces you to provide four files:
    jasshelper.exe --scriptonly <path_to_common.j> <path_to_blizzard.j> <path_to_input.j> <path_to_output.j>

    This syntax requires no map to be provided, will simply evaluate the input .j file and show syntax errors if necessary. If the compiling is successful, jasshelper will write the output script to the file path you provided.

  • --warcity : This setting will automatically turn --scriptonly on, it makes jasshelper evaluate the input script file as if it was a "warcity script file", WarCiTy is a program that converts a map's custom trigger data into a special sort of .j script. This setting will simply make jasshelper evaluate only the //! import and //! novjass preprocessors, it will also prevent the adition of guide comments specifying it just imported the file. There is no syntax checking feature for this mode.
  • --zinconly : This setting will automatically turn --scriptonly on, it makes jasshelper evaluate the input script file assuming it is a single zinc source file. It will then output the compiled vJass code after the zinc phase.
  • --macromode : Like warcity but also evaluates textmacros.
  • --about : This just displays the about dialog (Do you want to know what jasshelper version you got?) Notice that it ignores the file arguments provided.
  • --showerrors : Shows the previous syntax error(s) (Without compiling).
  • clijasshelper.exe : clijasshelper.exe behaves exactly as jasshelper.exe but it does not use/need windows GUI, (it is still a windows-WINE app though), it may be useful sometimes (for example if you want to use jasshelper from a ssh sesion), it just outputs stuff to stdout, if for some reason stdout does not work, it will output to stdout.txt in the work folder.

IV. Updating

Unless otherwise stated, the way to update jasshelper for newgen pack is to simply replace the executable file.

IV. Uninstalling

  • WEHelper plugin : Move JASSHelper.dll out of the plugins folder/delete it
  • Newgen pack/grimoire: I think removing the jasshelper folder would make it notice it was uninstalled.
  • From your computer: jasshelper does not use the registry, so you can just wipe the folder containing it.

VI. Credits and thanks

  • The Gold parsing system assists in some of the most complex parsing involved: http://www.devincook.com/goldparser/
  • pipedream: For a lot of help in deciding how the syntax additions would work. And having contributed so much to WE hacking.
  • weaaddar: Clever allocation method used by structs and arrays.
  • Zoxc : for making WEHelper.
  • Vexorian : Just converted stuff inside his mind into this compiler.
  • ZergLeb : Helped me fix an evil bug
  • Grim001 : Bug reporting
  • Anitarf : made me implement plenty of things he did not even use later. Help finding bugs.
  • Rising_Dusk: delegate would not have been added without him.
  • StealthOfKing : Helped fix SLK issues
  • rain9441: found plenty of bugs with onDestroy in structs extending other structs.
  • Captain Griffen, Here-b-Trollz, and some other people for bug reports.
  • Alexander244: For using loaddata so much that the generated function is too large for PJass.
  • Litany: Suggestions.
  • Flame_phoenix: For making me figure out how necessary 2D arrays are and how hard to use the work aroudns were.
  • C2H3NaO2: Bug reports
  • Av3n: Provided his script file so I could fix a bug
  • Zoxc and Deaod: , helping to fix some blizzard/common.j related issues.
  • MindworX: Bug reports.
  • http://www.wc3c.net Just wanted to put a link to my home site...
  • I used gvim to generate most of this file http://www.vim.org/
  • The Ultimate Packer for eXecutables : Copyright (c) 1996-2002 Markus Oberhumer & Laszlo Molnar : http://upx.sourceforge.net (though to be honest I do not use it anymore)

VII. Changelog

  • 0.A.2.B
    • Fixed a bug with static ifs that made them fail when the constant boolean variable had a comment in its declaration line.
    • It is now possible to use . syntax inside a global/static member declaration. However, you must notice that this will not usually work unless you are calling a static member from a place bellow its declaraton . Else you would get a Pjass error.
    • Array structs no longer 'declare' unusable allocate/deallocate methods. In other words, you may now use those method names when declaring a method inside an array struct.
  • 0.A.2.A
    • Fixed a bug that allowed scope members to have invalid names and still compile.
    • Fixed a bug that allowed natives and BJ to compile when given more arguments than necessary.
    • _F, _I and _V do not get created anymore for array structs.
    • Manual: Fixed the getFromKey example.
    • Zinc: Fixed bugs that prevented some real literals to compile.
    • Zinc: while(true) does not add a useless exitwhen(false).
    • Zinc: Added do{..}while(..); .
    • Zinc: You may now separate assignments with commas. These commas can be used in the for construct. In other words:
      for ( x=0, y=0, z=0; x<=10 && y<=10 && z<=10; x+=1, y+=x, z+=y) is now possible.
  • 0.A.2.9
    • All module initializers run before any struct initializer.
    • Fixed a bug that forbade comments after then in static ifs.
    • Structname.methodName.exists should work outside static ifs.
    • Static ifs should now work correctly with members/methods that are explicitly public or private. Note that private members/methods will not be visible to static ifs outside the struct.
    • Zinc: Fixed random compile error bugs introduced in last version.
  • 0.A.2.8
    • double import check now considers full path instead of just file name.
    • static ifs can check if a method exists using .exists.
    • private module destroy now works like module create (is not hidden from the implementing struct)
    • Zinc: structs onInit and library onInit no longer conflict.
  • 0.A.2.7
    • Added "comment" import mode.
    • Added +=,/=,-=,/=, and for(assignment; condition; assignment) to Zinc.
    • Fixed a bug with import doing a double import when given the same filename twice in OSes that use / instead of \
    • Fixed a crash when attempting to use special methods like allocate for function interfaces, now it gives a syntax error...
    • Fixed a bug with function literals not working correctly when the function returned a custom type.
    • Fixed a bug with function interfaces not working correctly when they had themselves as argument/return value.
    • Fixed a bug with //! import inside //! zinc tags
    • Unclosed //! zinc tags inside a file will get reported.
  • 0.A.2.6
    • externalblock now allows a $FILENAME$ argument and a extension= property.
    • Fixed a bug that made /* */ comments mess up with the syntax error line number in the zinc/libraries phase when import was not used.
    • Improved the library requirements error message.
    • Zinc: Make [implement] cause syntax errors.
  • 0.A.2.5
    • Limit of strings in a single line raised from 27 to 61.
    • Zinc: Fix not being able to parse certain real literals.
  • 0.A.2.4
    • Fixed a bug that allowed .getType() to cause jasshelper crashes.
    • thistype works in static ifs. (not implicit though)
    • When debug mode is on, static if phase will comment out lines instead of deleting them.
    • Fixed a bug with optional requirements sometimes not working correctly.
    • Zinc: jasshelper.conf's [noimplicitthis] option does not affect Zinc code.
    • Fixed a bug with the shadow helper phase duplicating some comments.
  • 0.A.2.3
    • Fixed a bug that made .exists cause obscure syntax errors.
  • 0.A.2.2
    • Fixed a bug that prevented using .evalaute/ .execute on methods.
    • Fixed a bug that caused syntax errors when you used a hook for a native that takes nothing.
  • 0.A.2.1
    • .pointer has been removed from the syntax for using methods for function interfaces.
    • You may now also use non-static methods for function interfaces (they are treated as functions that take an extra integer first)
    • Zinc: Added anonymous methods.
  • 0.A.2.0
    • Fixed some struct member declaration syntax errors appearing in line 1.
    • Fixed a bug that made method.name return wrong values when using the method implicitely (without this).
    • Fixed missing syntax error messages in the structs phase.
    • Static Methods can be used as function pointers. Just do struct.method.pointer to get such function pointer. Implicit casting between methods and function interfaces will come later (so you do not have to use .pointer).
    • Zinc: Allow anonymous functions in global / struct variable declarations.
  • 0.A.0.1
    • Fixed some undefined code related to implicit this in member usage. Which could have caused very odd code to get generated.
    • Fixed an old bug that sometimes added indentation and comments to syntax errors.
    • Zinc: Fixed a random crash related to comments.
    • Zinc: Fixed a lame mistake that made all of a zinc struct's members LIBRARY-private.
  • 0.A.0.0
    • . or this. are not required anymore to use members. Note that this may cause issues if for some (incredibly weird) reason you try to use global variables from a method of a struct that has variables of the same name. To disable this feature, you can add [noimplicitthis] to jasshelper.conf.
    • Improved the syntax error when you place a function inside a struct.
    • Code values might get implicitly casted to boolexpr in some occasions, specifically, when using them as arguments for natives/bjfunc that take boolexpr. More cases will get added when type safety gets on its way for more stuff...
    • Zinc: Added anonymous functions, but they cannot use locals from their parent (yet).
    • Zinc: Fixed a crash that could happen when the zinc input is much smaller than the vJass output.
    • Zinc: Fixed a couple of missing ; mistakes in the examples.
  • 0.9.Z.5
    • Added externalblock.
    • optional textmacros work.
    • static ifs support elseif.
    • static ifs support a struct's static constant booleans.
    • Missing thens in static ifs are reported as a syntax error.
    • Comments inside static ifs are deleted correctly when the condition is false.
  • 0.9.Z.4
    • Reversed the deprecation of automatic method TriggerEvaluate, you may enable the syntax error adding [forcemethodevaluate] to jasshelper.conf.
    • Added a syntax error when . and other unsupported operations are used in static ifs.
    • Added a --zinconly command line argument that will just compile a zinc file into vJass code.
    • Fixed a probable error with --macromode removing the first line of code.
    • You may now use the identifier DEBUG_MODE as a constant boolean that is true if and only if debug mode is on.
  • 0.9.Z.3
    • Correct operator precedence in structs phase, this change is not noticeable unless you had an overloaded == operator.
    • structs phase's "Syntax Error" message is now slightly more detailed.
    • You may now use a pair of decorative parenthesis in static ifs.
    • custom operators used from above their declarion will once again use .evaluate automatically. (as it is not possible to do it manually).
    • Hopefully fixed issues regarding using deallocate on child structs.
    • Fixed a bug with deallocate requiring evaluate for no reason.
    • Fixed a syntax error regression that happened when calling .destroy from above onDestroy.
    • Zinc: When an if is all that is inside an else's contents, it is translated into elseif.
    • Zinc: Compiler will try its best to keep comments, though it might place them in awkward positions...
    • Zinc: Fixed a z.2 regression that made Zinc eat up parenthesis...
  • 0.9.Z.2
    • Fixed a crash related to ==.
    • Fixed a bug that for some reason required slks to have more than 2 columns, instead of more than 1...
    • If a SLK value for a boolean member is 0 or 1, jasshelper will convert it into true or false.
    • Added runtextmacro optional .
    • .evaluate() is mandatory on methods if you want to call them from above their declaration
    • to disable this new syntax error, add a [automethodevaluate] option to jasshelper.conf
    • Zinc: Make grammar allow negating a negation.
    • Zinc: A while's condition is compiled neatly, being able to avoid unnecessary not operators.
  • 0.9.Z.1
    • Important: Removed virus that sneaked into some hidden folder inside the source tree.
    • destroy can get replaced inside a struct.
    • Added a deallocate method that works like allocate
    • Added static versions of the name and name= operators.
    • Added == overloading (and != for that matter)
    • Zinc: add operator== to grammar.
  • 0.9.Z.0
    • Added static ifs
    • Added optional library requirements
    • Added Zinc.
  • 0.9.K.0
    • Variable shadowing is now part of correct vJass syntax. Compiler guarantees (or at least should) that there won't be global-local conflicts in the compiled jass code.
  • 0.9.j.2
    • Fixed a memory out of bounds error related to some bugged native declaration usage.
    • Fixed issues with undeclared variables and also array member leaks when you use array members on an interface and do not have onDestroy declared on one of its children.
    • Fixed a bug with methods called the same as any function not being callable.
  • 0.9.j.1
    • Removed returnfixer from the default, you may still toggle it on but it is not necessary anymore.
    • Fixed some crashes in windows with non-cli jasshelper.
  • 0.9.J.0
    • Jasshelper now comes with a phase that will do its best to fix return bug false positives at the cost of an extra function call. This is meant as a temporary fix while blizzard fixes the bugs caused by patch 1.24 , or you update your functions to avoid multiple return statements. This phase can be disabled through the config file. Check the updated manual for more info.
  • 0.9.I.2
    • Fixed a bug with function hooks not working correctly if nothing else related to function interfaces is used by the map.
    • Fixed a bug with function hooks not working correctly at all most of the time.
    • The manual no longer wrongfully states that the order of execution of onInit methods is undefined (as it turns out it isn't).
  • 0.9.I.1
    • Fixed a crash related to extends and array members.
    • Fixed some chance that clijasshelper would attempt to create window.
    • Fixed a bug with stub keywords causing childless struct not to call onDestroy correctly.
    • Added hooks.
    • It is more likely that methods using evaluate will not use TriggerEvaluate if they only call natives/blizzard.j functions.
  • 0.9.I.0
    • Jasshelper can now support native declarations around the map script, and move them to the top of the script.
  • 0.9.H.3
    • Added GetHandleId, StringHash, the gamecache Get and HaveStored natives and the hashtable Load and HaveSaved natives to the list of natives that do not modify the state. This means that functions that directly or indirectly call these natives are more likely to get inlined.
    • Fixed a small typo bug inside a comment of sample jasshelper.conf .
  • 0.9.H.2
    • Fixed a freeze and out of memory bug with mass storage arrays/structs/dynamic arrays when the storage size was greater than 8191*13.
    • The mass storage arrays/structs/dynamic arrays picker functions will now take slightly less lines of code,
  • 0.9.H.1
    • Fixed an off-by one error in the mass size arrays/structs/dynamic array code that caused various issues on boundary cases.
    • jasshelper.conf can now determine the command line arguments given to the Jass syntax checker.
    • Added key
  • 0.9.H.0
    • Added block comments.
    • If call InitBlizzard() is not found in the main function, jasshelper will add the initializing code to the end of the function, instead of raising an error
  • 0.9.G.3
    • Fixed a crash when there were empty lines on some methods.
    • Fixed a bug that prevented array structs from having static array members.
    • Fixed private delegates/constants not working correctly inside modules (and possibly causing further bugs)
    • Fixed problems related with clijasshelper not working in windows' cmd.exe.
    • If for some bizare reason, there's no stdout assigned for clijasshelper, it will automatically send its output to stdout.txt.
    • GetUnitUserData is now considered a non-state changing function by the inliner, which should increase the chances of functions that use it to get inlined.
  • 0.9.G.2
    • Fixed a regression introduced in G.0 that caused various issues with function interfaces.
    • Fixed "operators that return self" adding a chance to cause odd syntax errors, stack overflows and access violations.
  • 0.9.G.1
    • Modules' private members are now truly private, unlike the other members, they are not visible to the calling struct, and their names will not collide with other names declared in the struct.
  • 0.9.G.0
    • Added Modules and thistype.
    • Will now call the optimize phase after PJass, as it was always intended, this should prevent some crashes during optimizations.
    • Functions can now use .name in a similar way to methods.
    • Fixed a bug that made child structs ignore the parent's storage size if a constant was used.
    • Fixed a crash when the user attempts to assign a static array member.
  • 0.9.F.7
    • $ Is now supported as hexadecimal prefix in integers - turns out wc3 always did.
    • You can now tweak jasshelper.conf to set a different Jass compiler (i.e. change pjass.exe requirement into foojassc.exe).
    • Fixed bugs related with displaying errors in blizzard.j / common.j in an unusual jasshelper setup is unusual like newgen's - several situations in which it would fail to show the correct file in the syntax error window/report have been fixed.
    • clijasshelper will now specify the script file in which the errors were found.
  • 0.9.F.6
    • jasshelper will avoid using TriggerEvaluate when the evaluated function/method does not contain function calls.
    • function interfaces will consider all custom types as integers when comparing for validity, later it will have some type safety (i.e. you will not be able to use a integer in place of a struct, but you would be able to do the opposite) but for now it is type unsafe, use with care.
    • member declarations with odd characters between the type and the name are now reported as syntax errors.
    • static 2d arrays used to calculate their storage space incorrectly which caused issues like them not using get/set functions correctly, this has been fixed.
    • It is not anymore possible to declare a member variable with the same name as a method operator.
    • Fixed a documentation bug in the section about interfaces.
  • 0.9.F.5
    • Old OS/X line breaks are now supported in input .j files, this would most likely be useless to everyone unless a bugged text editor saves the file using those...
    • Fixed a crash bug introduced in 0.9.F.4 related with structs that extend interfaces/stub methods and don't override the method.
  • 0.9.F.4
    • stub on a childless struct is not going to cause a syntax error anymore.
    • The getType() method can be called on any struct instance.
  • 0.9.F.3
    • More stub related bug fixes.
  • 0.9.F.2
    • Fixed a bug when using super on methods that had arguments.
    • Fixed a bug with bigarray.size using an undefined type which caused some type comparisons errors.
  • 0.9.F.1
    • Fixed some bugs with stub methods on structs that extended interfaces.
    • clijasshelper?
  • 0.9.F.0
    • Fixed the return bug detector, there will not be false possitives, which means more functions will be inlined.
    • Added stub methods.
    • Added super.
  • 0.9.E.1
    • Fixed issue with operator priority in result code of using 2D arrays.
    • Fixed compile error caused by .execute on static methods with arguments.
    • Fixed an usual chance to incorrectly inline return bug exploiters.
    • Single-line return bug exploiters now recognized as non-state changing functions by the inliner (Increases chance to inline certain functions).
    • dynamic array declarations now report garbage code after the end of the declaration.
    • Fixed a bug with scope initializers making a next library unable to have nested scopes.
    • Array structs can now have a max size specifier after "array".
    • Fixed a readme bug, it incorreclty stated the command line arguments order.
  • 0.9.E.0
    • Added --macromode.
    • Added method.exists.
    • Added 2D global arrays (and 2D static array members)
    • Extra text after certain array size declaration is not ignored anymore (a correct syntax error now appears)
    • Fixed certain readme bugs.
  • 0.9.D.3
    • Array structs now work as intended.
    • Fixed yet another regression with method calls.
  • 0.9.D.2: -Fixed a [list out of bounds] error when using .method() syntax.
  • 0.9.D.1
    • Non-static methods that take no arguments are possible to be called again i.e: .destroy().
    • Delegate cycles will now cause a crypting syntax error, which is better than jasshelper overflowing the stack.
  • 0.9.D.0
    • Added delegate.
    • Added functionname for function pointer values.
    • Added a way to get the return value of .name= and []= assignment operators.
    • Added extends array.
  • 0.9.C.1
    • Fixed a problem caused by waits inside library initializers, they prevented other library initializers from running.
    • SLK cells with either - or _ as ignored, whitespace inside these cells is also ignored.
    • Fixed syntax errors caused by international compatibility issues in certain setups.
  • 0.9.C.0
    • Fixed a crash that happened if you attempted to assign a method. (set x.create=2 )?
    • Fixed a bug that made children struct cause syntax errors if the parent uses extra space.
    • Fixed a conflict between --nopreprocessor and using script arguments (the script used to be ignored)
    • Fixed a conflict between --nopreprocessor and --scriptonly though it would be nonsense to use both simultaneously anyway...
    • Inline phase no longer gets confused by control characters in strings.
    • Inline phase no longer gets confused by control characters in strings (Both of these were meant to handle those things correctly, but there were small bugs in certain functions that made the provisions fail)
    • Added the colon operator.
    • Improved the syntax error caused by getFromKey not taking a single argument
    • Fixed a bug with the SLK parser that made it unable to parse SLKs with UNIX (normal) linebreaks.
    • Certain loaddata syntax errors will now also point to the location of the related struct/member.
    • Cells with - are now ignored (that would have created bad syntax anyway).
    • Compatibility with yet another odd quote sequence used by openoffice in SLKs.
    • Given how absurdly hard and tool-dependent it is to use " in a SLK cell, jasshelper will now automatically add "" to cells in columns for string-typed cells that don't have them. (unless it is - or an empty cell, in which case it will use the default value, which is probably "" anyway)
    • Similarly, If a column's field is of integer type, it will add '' automatically to non-integer values of length 4 or 1 inside cells.
    • Code generated by loaddata is now split in function batches of 100 loaded structs each (each using its own thread), long functions cause PJass errors and might also cause thread crashes...
    • If you use //! import from an imported file, you are able to use relative file paths based on the importing file's location.
    • Backwards incompatibility: I hope no one was using variables in SLK cells. It should still work if the type is not string or integer, if the type is integer, variables would still work provided their name length is not 4 or 1.
  • 0.9.B.1
    • Once again struct members can be initialized.
  • 0.9.B.0
    • Fixed a bug with the first jasshelper phase which used to cut the last line of an input file potentially causing problems if WE decides not to print a last empty line (which apparently happens sometimes).
    • Fixed a chance for access violation after the structs phase finishes.
    • Jasshelper no longer ignores extra code after a struct member declaration (It now shows an error).
    • Jasshelper no longer ignores extra code after a local variable declaration (It now shows an error).
    • Structs now allow sized static array members.
    • Added //! novjass and //! endnovjass.
    • Added --scriptonly and --warcity
    • global variable addition order is now affected by library requirements.
    • Fixed a couple of "&aquot;" bugs in the readme file.
    • The readme file comes with description about jasshelper's command line options.
  • 0.9.A.0
    • Added inline phase and --nooptimize
  • 0.9.9.B
    • Fixed a bug that would cause syntax errors when two or more scopes got initializers.
    • Maximum extended array size limit increased to 409550.
    • Dynamic arrays allow sizes smaller than array's storage limit / 8.
  • 0.9.9.A
    • Fixed yet another bug that prevented f__arg_this from being created.
    • Scopes now use normal calls instead of ExecuteFunc for initializers.
    • Updated readme, scope initializers are mentioned, made it aware //! for libraries and scopes now cause a syntax error.
  • 0.9.9.9
    • Hopefully fixed onDestroy issues with extends and similar.
    • Fixed memory corruption when using [] on structs/interfaces to increase index limit.
    • Added big sized global arrays.
    • Library declarations more likely to survive comments.
    • Fixed hang outs related to wrong use of extends.
    • Fixed bug with defaults on methods that return custom types.
    • Scopes can have initializers.
  • 0.9.9.8 (test release)
    • Fixed a bug with f__arg_this not being declared when required if extends is involved.
    • Fixed a crash related to misplaced endscope inside a library.
    • Fixed a bug with array members in child structs, possibly "leaking", which means they did not get recycled properly and the struct would eventually malfunction.
    • Can declare methods to replace variable access and write operators (method operator name and method operator name=)
    • "member is private" syntax error now also shows the name of the involved struct.
    • Access violations will report a related line of code if possible
    • Can setup max index space on dynamic arrays and structs ( type arrayname extends typename array [ instancesize, spacerequired ] )( struct name[spacerequired] )( interface name[spacerequired]
    • In order for last feature to work I have to modiffy plenty of things, expect an unstable version, releasing it so I could get free testing...
  • 0.9.9.7
    • Fixed a bug with methods, pseudo inheritance and interfaces that is just too hard to explain.
    • Fixed a bug with third generation (and above) child structs and array members.
    • Scopes and libraries may now use numbers in their names (Still not _).
    • External command line length limit extended to 1000.
  • 0.9.9.6
    • Fixed a bug with onDestroy if it contains calls to methods from other structs and is used on an struct extending another struct.
    • [] and []= operators can also be declared as static.
    • Order of addition of libraries that don't extend each others is now sorted by name.
    • empty interfaces or onDestroy methods are assigned to null rather than not assigning their arrays, it probably was all right but this sounds better.
  • 0.9.9.5
    • Fixed more bugs related to onDestroy and extends.
    • Fixed various bugs relating to syntax errors and library declarations.
    • Fixed a certain line off-set present for syntax errors after files are imported.
    • Fixed a readme bug with the changelog.
  • 0.9.9.4
    • Fixed a bug with static methods that return custom types and require evaluate.
    • Fixed plenty of bugs related to "running" undeclared textmacros.
    • Fixed plenty of bugs related to onDestroy methods when inheritance or interfaces are involved.
    • Fixed an access violation crash when the [] operator is used on methods
    • Fixed probable (local-not-set-to-null) memory leak with function interfaces, methods called from above their declaration, evaluate, execute and function interfaces
    • Long external calls will now popup an error instead of crashing jasshelper.
    • Added onInit method support for structs.
  • 0.9.9.3
    • Fixed a bug with return statements in interface functions that return nothing
    • Fixed a crash with --nopreprocessor that introduced a long ago.
  • 0.9.9.2
    • Fixed a major bug causing desyncs (All functions generated by jasshelper that are passed to Condition() will have a boolean return value)
    • struct.typeid now returns an accurate integer not dependant on parent ids and is replaced by a constant added to the map script instead of a single number.
  • 0.9.9.1
    • Fixed a bug with static methods that return custom types and required evaluate mode, causing some pjass parse errors.
    • Structs may now extend other structs.
    • Interfaces are now allowed to declare a rule so that constructors of the interface's children do not declare a create method that takes arguments.
    • interface.create() will now return 0 when there is attempt to call the private allocate() method.
  • 0.9.9.0
    • Fixed a critical error causing infinite loops when there were external commands used for grimoire version.
    • Improved Wine compatibility again, should work with more versions of Wine including the newest.
    • Grimoire version's compile error window used to have a chance to look akward under certain windows UI settings, this problem is fixed.
  • 0.9.8.9
    • Documented inject.
    • Added information about problems related to sync natives and methods/evaluate().
    • Improved the error message given if InitBlizzard() is not present in the main function.
    • New command line option to use an external war3map.j instead of the one found in the map.
    • Improved compatibility with WINE, at least on the recent WINE versions I have tested jasshelper.exe and it can compile a map fine.
    • Added some syntax errors for maluse of dynamic arrays or array members
    • Fixed issues with commented-out/incomplete return statements inside certain methods or functions.
    • private or public are ignored when using on scope declarations, used to silently cause other bugs before.
    • Made usage of public and private more strict to prevent bugs (Instead there would be syntax errors)
    • Added: keyword
    • [scope symbol redeclared] syntax error will now also specify the first declaration of the symbol.
    • Made certain statements more strict, some used to allow extra text after the statement (scope or globals for example)
    • Made a syntax error related to libraries more understandable.
    • Struct member initializers may now use . syntax (it used not to parse them)
    • Added a .name field for static methods, returns the string of the generated function name.
    • interfaces can use .create if given a typeid value.
  • 0.9.8.8
    • Fixed plenty of issues with parsing of runtextmacros and handling of syntax errors in textmacros.
    • Child structs may override the initia default values of members of the interface.
    • structs allocation needs one less array and is a littler faster.
    • Improved error message given when someone makes an attempt to make an struct that extends an struct.
    • Can use .execute() on methods.
  • 0.9.8.7
    • Fixed a bug that caused issues with functions that returned custom types.
  • 0.9.8.6
    • Fixed a bug with scope private/public members used inside an struct.
    • Optimized performance of struct stage.
    • Compiler will now prevent name conflicts and rais errors if it finds them, these prevent bugs later but it is possible that an old name conflict in your map survived for a lot of time and this new jasshelper version will popup a previously unheard error for that map.
    • Undeclared InitTrig functions are ignored instead of poping syntax errors, this allow for cleaner usage of the trigger editor with libraries.
  • 0.9.8.5
    • Added defaults keyword for interface methods.
    • Fixed some bugs with the installer for WEHelper, should be easier to install to 1.8 although you still have to specify the path.
    • Fixed a bug that made jasshelper unable to recognize hex integers if they had lower case letters.
    • Formatted the manual a little.
  • 0.9.8.4
    • Fixed a bug with interface extending structs with multiple array members.
    • Fixed a bug with international characters inside strings.
    • Fixed some scoping issues, locals are now handled correctly by the structs convertor.
    • Added getType() and typeid for interfaces.
  • 0.9.8.3
    • Fixed a possible compiler crash.
    • Fixed a bug that made function interfaces unable to have arguments of custom types.
    • Modified the way grimoire version works in many ways, just replacing the executable will not work. A new version of newgen pack is released which you should update, else you may also have to wait for a new grimoire version.
  • 0.9.8.2
    • Fixed a 0.9.8.0 bug that prevented dynamic arrays from being used.
  • 0.9.8.1
    • Fixed a bug with function evaluate/execute methods using wrong variables.
  • 0.9.8.0
    • Structs now come with an internal private static method called allocate that does what .create used to do.
    • If no correct static method create is declared within an struct body, a default one which calls .allocate is added.
    • Functions are now objects, you can call methods evaluate and execute on function names no matter the position of the function declaration, execute() runs the function in another thread.
    • Added function interfaces, this allows function variables and other fun stuff.
  • 0.9.7.4
    • Fixed bugs with array members in structs that extend interfaces.
    • Fixed syntax error bug with calling .destroy above an onDestroy declaration.
    • Improved performance of interfaces (reduced a function call when calling a method, and improved constructor performance).
    • Also improved performance of methods when called from above their declaration
  • 0.9.7.3
    • structs may now have array members.
    • Constant integer variables may now be used for size of dynamic array and array member declarations.
  • 0.9.7.2
    • <, > comparissons between zero and an struct type are allowed again.
    • Fixed logic flaw in implementation of < operator for interfaces that made them unable to use it.
    • Added SCOPE_PREFIX and SCOPE_PRIVATE, assist to use ExecuteFunc / real variable events on scope private/public members, and are also useful for debugging.
    • Public InitTrig function is now translated to InitTrig_ScopeName instead of ScopeName_InitTrig (makes some stuff way easier, specially for JESP spells)
    • Grimoire version now writes logs in a logs subfolder as compliance with newest grimoire version.
    • Fixed multiple bugs related to handling SLKs saved by certain versions of MSExcel
  • 0.9.7.1
    • Fixed a major bug introduced on 0.9.7.0 that made interfaces useless.
  • 0.9.7.0
    • Fixed bug with big string literals.
    • Fixed major bug with the way dynamic array indexes are handled.
    • Added an integer() typecast operator (for structs and dynamic arrays only, we'll soon have an actual typecast operator for native types).
    • Added operator overloading for [] (both get and set) and >
    • Fixed a bug with some syntax error showing extra, debugging information that was supposed to be removed
    • Structs extending an interface no longer have to be declared after the interface
    • Will now show a proper syntax error if a method derived from interface is declared as static, instead of generating bugged code.
  • 0.9.6.3
    • Fixed requirement of whitespace before [ in dynamic array declarations.
    • Fixed some issues with nested methods causing misleading syntax errors.
    • Fixed some problems with local variables/arguments with the same name of previous local variables/arguments that were of custom types while the new ones were not (causing some confusion/odd syntax errors).
    • Fixed a probable issue with dynamic array indexes
    • Added instructions about how to update jasshelper in newgen pack
  • 0.9.6.2
    • Fixed syntax errors that could appear if there were special characters in strings or comments.
  • 0.9.6.1
    • (WEHelper only) fixed a bug that made worleditor unable to ever finish compiling.
  • 0.9.6.0
    • Added dynamic arrays (type name extends anothertype array [size]).
    • Added typecast operators (for struct types, soon we will have them for all the types).
    • It might now detect some few syntax errors before the pjass stage (prevents confusion when there are errors in code that is already compiled by JassHelper)
    • Instances might also call static members
    • Fixed a bug with the readme's html
  • 0.9.5.2
    • Fixed a bug with struct methods that had more than one argument of different types.
    • JassHelper now repeats its process after external tools are executed.
    • Added an interfaces demo.
  • 0.9.5.1
    • Fixed a bug that could cause [Undeclared variable f__arg_this] pjass errors when saving
    • Fixed a bug with //! import not importing the last line of the file.
    • Fixed a bug with //! import not being able to import a file if quotes weren't used for the path and there were comments after the command (may happen if import is the last line of a world editor [trigger]])
  • 0.9.5.0
    • Can now convert slk files to struct assignments with the //! loaddata preprocessor.
    • Added the //! external preprocessor which allows you to configure jasshelper to run command line tools, the way the command line tools have to work is very specific so if you should check out the manual if you are interested in making them.
    • WEHelper's plugin has now dialogs to configure lookup folders and external tools. Grimoire's mapcompiler can take advantage of a .conf file.
    • Grimoire mapcompiler is now able to run wewarlock once configured correctly.
    • Jasshelper's import can now be used in WEHelper if WEHelper's is disabled. The advantage you can get from it is the ability to configure the lookup folders.
    • Fixed some terrible typos in the interfaces explanation of the readme
  • 0.9.4.4
    • Fixed a compiler crash when there was an struct (something) extends (something else) when the parent struct name wasn't declared yet.
    • Fixed a chance for the struct usage to generate game-crashing code.
  • 0.9.4.3
    • Fixed a bad bug that could cause access violations if textmacros are used extensively
    • Fixed a bug with public/private members not being replaced accordingly on lines that had a / in them.
    • Grimoire version allows relatives paths for //! import , you can specify where to look for files in the newly set mapcompiler.conf file
  • 0.9.4.2
    • It is again safe to call jasshelper twice. (Fixes some issues with testmap and WEHelper)
    • Grimoire version now includes a beta of //! import , use //! import on complete paths only (for example: //! import c:\goo.j )
  • 0.9.4.1
    • Documented 0.9.4 features.
    • Fixed a bug with static methods on interface extending structs causing PJASS errors.
    • Fixed a bug with static methods with no arguments having a chance to cause compile errors that to make matters worse were not detectable by PJASS.
    • Fixed a bug with default values being ignored on structs that extend interfaces.
  • 0.9.4
    • structs can now have methods.
    • Added interfaces
    • Added //! inject
    • Again, documentation of new features would take a while
    • Compiler for grimoire now got a progress bar and uses SFMPQ.dll directly instead of mpqutils, which should be faster and also be compatible with a later version of grimoire which will remove mpqutils and replace them with mpq2k.
  • 0.9.3
    • Fixed multiple bugs in compatibility between scopes and structs.
    • Fixed a minor issue with the grimoire compiler.
    • Updated some sections of the manual, added more info about structs.
  • 0.9.2
    • Fixed grave bugs probability when many structs were used
    • Destroying the 0 struct will do nothing instead of sending it to the recycle stack.
    • Include compiler to be used by grimoire's wehack.dll.
    • Documented 0.9.0 aditions.
  • 0.9.1
    • Fixed a wrong syntax error when comments with triple / were present
    • Fixed a syntax error caused by having dot characters inside comments
    • The new additions to the syntax are not documented yet
  • 0.9.0
    • Fixed some wrong instructions that could end up causing access violations
    • Fixed a bug with some textmacro declaration errors giving the wrong line number.
    • Fixed a bug that made libraries unable to have child scopes unlike what the documentation said.
    • Fixed a bug with private/public that made it unable to rename identifiers correctly after single / characters.
    • Added library_once
    • Added textmacro_once
    • Added structs, dynamically allocated object types. Seriously.
    • The new additions to the syntax are not documented yet
  • 0.8.0
    • Added //! textmacro support.
    • Fixed a bug with private/public that didn't process global variables correctly if they were initialized and had = stuck to the name.
  • 0.7.0
    • Better handling of some syntax errors.
    • Nested scopes are now legal.
    • Added the public keyword.
    • Cut the file size.
  • 0.6.1 : Added installer for the WEHelper plugin.
  • 0.6
    • Added private keyword and //! scope.
    • Various optimizations, specially for the plugin edition.
    • JASSHelper is called again after WEWarlock, so you can use features like debug or private in files called by //! require
  • 0.5.2: For WEHelper 1.5.2
  • 0.5
    • Fixed wrong error messages in the case of unclosed strings causing issues.
    • Fixed a bug that made debug cut the last character
  • 0.4
    • Fixed a bug that made this preprocessor unable to recognize globals//comment and endglobals//comment.
    • Removed the progress bar from WEHelper plugin
    • Added WEWarlock support to WEHelper plugin (Can call the WEWarlock compiler, and you can use wewarlock's features in your map by just saving.).
    • For WEHelper 1.5.1
  • 0.3
    • initializer will now call the init functions AFTER call InitBlizzard() allowing to use blizzard globals on init functions.
    • requires and uses also work in the place of needs
    • For WEHelper 1.5
  • 0.2: (initial public release)
Power of Corruption - A Warcraft III altered melee map   Chaos Realm - The world of Game modders and wc3 addicts     WC3JASS.com - The JASS Vault   Jetcraft - A Starcraft II mod