Jass Code Generation from GUI

[Mercious]

I usually always generate the trigger part of a trigger from GUI, because I am too lazy to write it myself and also look up the specific event-translations.

I noticed though that the generated translation always uses a global variable, that it somehow automatically generated upon compilation.

Meaning that the CreateTrigger() call is assigned to some udg_<triggername> variable.

When syntax checking that with jaashelper it obviously returns an error because it didn't know how this variable and wc3's global creation magic hasn't happened yet.


Should I rewrite these auto generations? Is the global variable at that places necessary?

 

[WereElf]

I don't really understand your question.
When you create a trigger - a global trigger variable gg_trg_(your trigger's name) is created automatically in the part of the script, which declares globals.
If you want to have more than 1 trigger in 1 trigger block, you could do:

scope gg_trg
    globals
        public trigger /*second trigger's name*/
    endglobals
endscope

If you don't need to call the 2-nd trigger from other triggers, you can do it as a local trigger:

 function InitTrig_Something takes nothing returns nothing
    local trigger tr = CreateTrigger()
    set gg_trg_Something = CreateTrigger()
    call TriggerRegisterAnyUnitEventBJ(gg_trg_Something, ....)
    call TriggerRegisterAnyUnitEventBJ(tr, .....)
    // give them conditions
    set tr = null
endfunction

 

[Mercious]

Well, that's JNGP, but I am using standard WE, which does not declare the variable it uses anywhere visible.

 

[WereElf]

Just use the 2-nd method then

 

[Mercious]

Good to know that these globals are just meant to make triggers accessible from other triggers

Somehow, these generated InitTrigger functions really f*** my code base.
For example, I can't declare, call of do anything in the map header - it always generates a compile error and in the error window I can see that the code I just put into the header is randomly between a bunch of auto generated stuff from world-editor, such as the global variables declared in the Variables-Editor and also all triggers.

I'd like to put some stuff in the map header, but I really can't - no idea what's up with that.


Apart from that, I also cannot acces a function from trigger A in trigger B, despite them actually all being global.

Even when I put the trigger B underneath trigger A in the list of triggers.

I have seen other maps doing exactly that and it works fine, but it won't for me.

Guess I have to finally migrate the code base over to JNGP and adjust all global triggers to local.

It might work then.

 

[WereElf]

Well, you could use call ExecuteFunc("function name") and you should be able to access functions from other triggers.
But yeah, using vJASS makes it easier.

 

[Mercious]

True, but I heared that this particular function has some risk of crashing wc3?

Anyways, time for JNGP

 

[SAUS]

You shouldn't be getting errors from doing this. Are you saying you make a trigger, save the trigger with no errors, turn it into JASS, save again, and you get an error this time?

What are you writing in your header? The bug you are getting sounds almost like your WC3 editor is broken. Maybe it is not the latest version or something. Maybe just reinstalling it will help.

It is completely impossible to have code in Trigger A and Trigger B both calling functions from each other. They are defined in an order and functions must be declared before being used. The order of trigger definitions is awkward to manipulate and some people claim it is random. JNGP will help with this, but it is still impossible to have two libraries that both talk to each other via functions (you would need to use ExecuteFunc or triggers that are run as functions). You can, however, have one library use another library. It is only hard to make it go both ways.

The gg_trg_MyTrigger variables are, indeed, auto-generated by wc3 editor. They should not be causing errors unless your editor is messed up or something.

Every trigger in default editor MUST have the InitTrig_MyTrigger function. Removing or renaming that would also give you an error. The gg_trg_MyTrigger variable will also match the trigger name (spaces turn to underscores and it always starts with gg_trg_). Changing those names will definitely break things.

 

[edo494]

You cannot reference code inside normal triggers from map header, because the map header stuff is generated after globals are generated, and triggers are placed only after that, which means that the functions are below the header.

 

[Mercious]

@SAUS You kind of misunderstood what I was trying to achieve.
It was really just one way, not both ways.

I simply tried calling a function that was defined inside of trigger A from Trigger B.
So B -> A.

But I could not get it to work, because it seems that no matter where I placed trigger B, it would always get compiled before trigger A, making the function I was trying to access invisible.

@edo

Yes you are right, that makes sense.
However, there is nothing I can do in the map header. Can't define variables, can't define function, nothing. Whatever I put in there creates an error.

Is execfunc save to call or not?
How does vJass internally solve the problem that I have with trigger A and trigger B? How does it guarantee that it's "libraries" are visible before trigger that has them are interpreted?

 

[WereElf]

ExecuteFunc is safe to use, but it's a bit slower (nothing noticeable ingame), and you can't give values to the function.

 

[edo494]

vJass will take code inside libraries, and paste it after the endglobals keyword, which means that the code is visible from just about anywhere(there are certain exceptions, but these are automatically generated functions, you have no access to them)

 

[SAUS]

You can pass values to a trigger function or function executed by ExecuteFunc by setting globals. Kind of indirect, but a workable solution.

The order of the triggers in WC3 editor is awkward to manipulate.
I actually have gotten it to work how I want after messing around with it, but I can't guarantee it is safe (some people say it will randomly stop working, but so far, I have found consistency in how it works). The order is always top to bottom, except there is an exception. When you make a new trigger, it will ALWAYS appear at the bottom of the map script, no matter where you put it in the list of triggers. The only way to get it to reorder properly is to save the map, close your editor, and reopen everything. Then it will be in the order on the left side of the triggers.

There's two issues that can happen if you do this wrong:
1) You create a new trigger that is your "library" trigger. You try to use it, but it will always be created last in the map script when you save, so it will always get an error when trying to save. You have to comment it out the function calls, save, and reopen your map, then it should work.

2) You create a new trigger that will use your other "library" trigger, and you move it above the library trigger. It will save fine, but when you reopen it and try to save, it will result in error. This is basically an error in coding, but moving the trigger now is unlikely to fix the problem. You'd have to comment the function calls out, move it, save it, reopen the map, uncomment the function calls, and save it again - it should work.

I don't know why your header script is not working. I don't think you can define variables in there, though.

I think vJASS modifies how the map script is generated and just orders everything how it wants. The order is based on key words in the code so users can map it all out nicely (much more like a regular code base).

Learning vJASS is a good idea, regardless. You can save yourself from jumping through the hoops to make triggers work as libraries and also gain the benefits of vJASS at the same time.

 

[Mercious]

Alright then, I kind of thought it's something like this.

I will use vJass library function and that's it.

Not really interested in some fake-OOP stuff, doesn't really change anything in a serious manner so I see no purpose.
The library keyword stuff will help a lot though

 

[Anitarf]

Not really interested in some fake-OOP stuff, doesn't really change anything in a serious manner so I see no purpose.

As someone who uses that "fake-OOP stuff", I just want to say that you are wrong: it changes everything.

 

[edo494]

Higher levels of abstraction make it easier to reason about code and understand it.

If it was useless we would be programming in assembly.

Note: Technically all OOP is pseudo OOP, its just abstraction layer

 

[Mercious]

There is a lot more behind OOP than just forcing classes into a language.

I don't see the purpose of trying to force a script language with such a weak base into concepts of higher programming langues that are built on a solid base.

No matter what effort your put into Jass, it will still be extremely lackluster in many regards.

That's why I take it the way it is and don't really bother with its modifications - cool that someone puts the time into it, it's just not for me.

 

[EdgeOfChaos]

Not really interested in some fake-OOP stuff, doesn't really change anything in a serious manner so I see no purpose.

...What?
There's nothing fake about vJASS OOP. It is a significant addition.
The point of it is that everything eventually needs to become JASS to work with wc3. Making the best out of the language will improve our maps, and OOP is one of those ways.

 

[Mercious]

It's not OOP, it's classes, that's about everything it covers.

You said the exact reason why it's not yourself.

Read above.

I really don't want to make a thing out of this comment now. If you are happy with the OOP in vJass then that's great. I am not though and I have my reasons.

Apology for making that outstanding comment, I should have known that it causes dicisission.

 

[edo494]

Well as I said, there is no real OOP, computer has no notion of objects, only some 0s nad 1s which he can happily chew up and spit some instructions, which at most know integers and floats, so technically, all OOP is integers and floats, so all OOP is fake.

No need to apologize, its a debate, like any other

 

[DracoL1ch]

abstractions costs efficiency and get the control out of your hands. I've never used anything but pure Jass and have no problems at all

 

[edo494]

there are ways to get almost any abstraction at zero cost, like the OOP in modern languages. In vJass there is also zero overhead on OOP, since it uses arrays to access the elements.

 

[SAUS]

abstractions costs efficiency and get the control out of your hands. I've never used anything but pure Jass and have no problems at all

vJASS translates into regular JASS. It can't possibly add new stuff that WC3 won't understand. It might make saving your wc3 map in the editor a little slow, but that's it. That is a pretty tiny cost for what it adds.

Abstractions also add efficiency in another way - you get to think in a higher level manner. This allows a programmer to get more stuff done in a given amount of time.

 

[Mercious]

Nontheless I don't consider putting stuff inside of a class as proper OOP and I would not feel fine doing it.

There is a lot more to OOP than using classes - a lot more than Jass can technically cover.

And using such low end OOP just for the sake of trying to hold up to some hyped programming paradigma is worthless, in my opinion.

There is nothing wrong with procedural programming, especially not in an event based environment and not in such a low complexity scale.

If vJass offered a complete implementation of OOP concepts, then I would use it where I found it necessary, but it's far from that so I'll stick with a procedural style.

 

[edo494]

you have almost everything in vJass that you have in Java when it comes to OOP.

 

[Anitarf]

And using such low end OOP just for the sake of trying to hold up to some hyped programming paradigma is worthless, in my opinion.

It's not about being cool, it's about getting stuff done, getting it done fast and getting it done well. Sure, at the end of the day vJass structs are just parallel arrays, but reading plain JASS code that uses parallel arrays and reading vJass code that uses a struct is like night and day. Same for writing.

Sure, using vJass globals and libraries alone will already eliminate much of the painful verbosity of "udg_" variable arrays, but the implicit "this" of structs goes at least as much further.