System GTrigger Event System

[SanKakU]

Indeed. Thats why its called SpellEvent. Because it only offers spell event responses.
Consider it considered.
Yes, i (probably) do. And im thankful for that. Makes me think im useful for something.
And here i was, thinking it was the other way 'round. I guess thats normal when arguing and defending your position.
Just say that you cant follow. Or go look it up on wikipedia. He (Jesus4Lyf) seems to understand me.
You missed the point. Read again. It doesnt matter if its not a big deal. Its counter intuitive.

lol. I just discovered a work-around to your pathetic excuse for a post. if i click on quote the nested quotes go away
ok, look, i don't understand why you want a system that does less. that's what you're admitting to about spellevent in regards to gtrigger. you're tellingme that spellevent does less. that's not what i'm interested in.

the other stuff that you are talking about in your post is completely irrelevant, so i'm not responding to it.

the thing about the returning false...as i already explained there's nothing wrong with the fact that he has functions that require you to return false...he has redundant triggers which you can use instead which do not require you to return false.

 

[Deaod]

your pathetic excuse for a post.

. . .
Thank you (i guess).

i don't understand why you want a system that does less.

Because it does what it does in a (subjectively) better way than GTrigger.

there's nothing wrong with the fact that he has functions that require you to return false

You mean, other than that its counter intuitive?

 

[Kenny]

You mean, other than that its counter intuitive?

Honestly, I would agree with you, if we were still like a year in the past. However, now almost everyone these days inlines their conditions and actions for a spell into the conditions function, which must return a boolean.

So for a lot of us, it is actually intuitive to return false in the functions used by GTrigger. I see your statement as being a little too subjective to be considered a decent argument.

@ SanKaKu:

Please try to be civil when writing your posts, Deaod is only trying to discuss his point of view with J4L. There is no need for calling his posts 'pathetic'.

 

[TriggerHappy]

there's nothing wrong with the fact that he has functions that require you to return false

The point is that it requires more work for such a minor speed difference. Yes, adding one new line and changing [ljass]nothing[/ljass] to [ljass]boolean[/ljass] takes all of two seconds but simply forgetting either of those could cause bugs. For example, IIRC it will desync on macs if you don't have the return there.

So it's not really worth it, sooner or later someone is going to forget about the return and franticly search his map for why everyone is desyncing. Usually scripts can't account for user stupidity but it's something that I see that can happen often as a simple mistake.

 

[Azlier]

Jasshelper kinda refuses to let you use codes that don't return booleans as boolexprs. Or is it PJass? Either way, there is accident prevention there.

 

[Deaod]

Its PJASS. And PJASS doesnt do deep code inspection. So it only complains when you directly use code variables of functions that dont return a boolean inside Condition() or Filter() calls.

 

[Jesus4Lyf]

There's a thought. But I could make it inline from func(abil,code) to func(abil,Filter(code)) which would add that detection, and probably at the right phase.

 

[Azlier]

PJass doesn't even let me set a code variable to a function that returns a boolean. Maybe I can try returning a code variable, unless Blizzard broke something that lets you do that.

Or I can invent a function which takes a code variable. But there's no fun in that.

 

[SanKakU]

The point is that it requires more work for such a minor speed difference. Yes, adding one new line and changing [ljass]nothing[/ljass] to [ljass]boolean[/ljass] takes all of two seconds but simply forgetting either of those could cause bugs. For example, IIRC it will desync on macs if you don't have the return there.

So it's not really worth it, sooner or later someone is going to forget about the return and franticly search his map for why everyone is desyncing. Usually scripts can't account for user stupidity but it's something that I see that can happen often as a simple mistake.

ok when you put it like that, it finally makes sense...it's easy for me to follow the instructions though which expressly tell you how to use the functions...although you say you can return a false and change the return to boolean rather than nothing likewise you can do the reverse and change the add to register and the action to event at the bottom of the trigger. that's if you were using the addaction functions to begin with, and if you were, it's your fault if you didn't read the instructions. the only thing counter intuitive here is what's going on in the brain of the man not following the instructions.

but i guess that's just my opinion. maybe i'm an idiot for assuming the guy who wrote a system and the instructions for it needs to be paid attention to if you wanted to use the system.

BUT SERIOUSLY...GETTING BACK ON TOPIC...
in regards to suggesting something about the system for it to be improved, i suggest an option to detect a unit is trained events and unit is sold events...other than that...i don't really got any complaints. with further options it would look nicer and nicer, i suppose.

Jasshelper kinda refuses to let you use codes that don't return booleans as boolexprs. Or is it PJass? Either way, there is accident prevention there.

yeah, that's what i thought. which sortof makes triggerhappy's defense a little pointless.

edit: just wanted to add that i'm sorry if i seemed hostile, i was after all responding to his insult of my request with an insult of my own.

 

[GoGo-Boy]

Got a question. Speed-wise...
if i have the standard UnitDies trigger with some condition function that returns true for 15 out of 20 units.
Would it be (again speed-wise) better if I instead use 15 times this
GT_AddUnitDiesAction(func, unittypeid) function with the 15 corresponding Unit Ids?

Because I have a map where lot's of units die frequently and I have more than 3 triggers using on death triggers... And this way I could save a lot unnecessary Condition runs or?

 

[Jesus4Lyf]

Would it be (again speed-wise) better if I instead use 15 times this
GT_AddUnitDiesAction(func, unittypeid) function with the 15 corresponding Unit Ids?

Probably makes no difference. But if it is checking 15 units with x "or" y etc, than the GTrigger evaluation is probably simpler.
The fastest way to do this is one trigger and GetUnitTypeId(..)<'xxxx' with some careful rawcode manipulation.

 

[GoGo-Boy]

Hmm okay, will try it with GT then as I have some or stuff as well...
Will make the code clearer as well :>

 

[tooltiperror]

    set gg_trg_Untitled_Trigger_002 = CreateTrigger(  ) // _002
    call GT_RegisterStartsEffectEvent(gg_trg_Untitled_Trigger_001,'A000') // 001

 

[Bribe]

Some triggers should just fire no matter what, as many triggered-events just happen to launch when no specific spell is cast. Is there support (or, can there be support?) to do something like put zero for the rawcode so it just always fires?

 

[Jesus4Lyf]

I was thinking of adding something where you can add boolexprs to a trigger...
I dunno, that's the correct way to handle this, isn't it?

 

[Bribe]

So you mean just attach by Boolexpr and not use the rawcode at all?

 

[Jesus4Lyf]

What the point of the rawcode if you're not using it? You're asking for a feature to trigger on any rawcode, right? Not the point of this system... o.o

 

[Bribe]

The system has a lot of uses that I've seen, one of them is the ability to minimalize handle count. You have a lot of great systems and the hashing work you've put into this is outstanding, so I feel it's not my place to pop up and ask for implementations, but using that efficient data-to-trigger attaching system you mentioned would be great for some projects I work on (GetTriggerId()?)

 

[SanKakU]

sounds interesting, Bribe, maybe you could explain further what you hope to acheive.

 

[Bribe]

Adding this to the interface would be as simple as changing this:

//
    //! textmacro AddSpecialAllPlayersWrapper takes EVENT
        public function Add$EVENT$Action takes code func, integer special returns nothing
            call TriggerAddCondition(Register$EVENT$Event(CreateTrigger(),special),Condition(func))
        endfunction
    //! endtextmacro

to this:

//
    //! textmacro AddSpecialAllPlayersWrapper takes EVENT
        public function Add$EVENT$Action takes code func, integer special returns nothing
            call TriggerAddCondition(Register$EVENT$Event(CreateTrigger(),special),Condition(func))
        endfunction
        // new
        public function Add$EVENT$Condition takes code func returns nothing
            call TriggerAddCondition($EVENT$Trigger,Condition(func))
        endfunction
    //! endtextmacro