System GTrigger Event System

[emjlr3]

nor do I

and just because you have a global array(they are all of size 8191, unless you make use of extended arrays, in which case you have size/8191 total globals) does not mean all of there members are pointing some place

 

[Builder Bob]

Who said GTrigger was limited to spells?

If you don't want to limit the system to spells only, you could use a similar method for unit type birth events. Using an additional boolean as input could include preplaced units as well.

 

[Sim]

> What this has to do with spell events?

See for yourself!

[thread=123721]Ultima[/thread]

 

[Jesus4Lyf]

Item 1: Investigate the null boolexpr leak and publish my results here.

As said, I have investigated this. This rumour is an absolute myth, at least for player events like those used to trigger on spell cast (I only tested this). Point is, unless someone prooves this rumour to be true for another type of event for some reason, I deem this absolutely false. Using null as the filter for "TriggerRegisterPlayerUnitEvent" is perfectly valid and leaks nothing. In fact, it is faster. So do it.

Careful what you repeat, Dax!
Let me test it first.

HOWEVER! I would like to note one important discovery, which is indeed in favour of using GTrigger. Always.

When you leak (or more to the point, simply don't destroy, for example leaving it in existance when players leave the game, which happens all the time) a trigger for which you have called TriggerRegisterPlayerUnitEvent, it kicks around in memory some how. It increases the time it takes to call TriggerRegisterPlayerUnitEvent in the future, until WC3 is closed and restarted. Note that it does not leak a handle into other maps! It only leaks the lag involved in calling that function. I repeat, the handle count is not effected in the next map. Also, note that this does not affect triggers that are destroyed and nulled.

So basically the more maps you run that don't use GTrigger, the longer it takes for other maps that don't use GTrigger to initialise, or create dynamic triggers.

Solution? Use GTrigger. No brainer, huh?

To-do:

• Upload a test map for this system's approval.
• Add AnyUnitDies style event.

PS.
>you could use a similar method for unit type birth events
Unit birth? Never heard of it. What's this about?

 

[Kenny]

This is a pretty cool system, makes initialising spells and such so much easier.

Do you think you could add events for TARGET_UNIT and TARGET_POINT or whatever they are. They are used quite frequently in comparison with some of the events you have already.

Also, whats up with saying the alternate interface is not recommended? Is it just because you need to make your functions return false?

> Due to the storage method, only 8191 events are possible at any one time.

Thats not really an issue is it, i can't see that being reached ever, unless im mistaken about what you mean by it.

Overall, this kicks ass, nice work.

 

[Jesus4Lyf]

>This is a pretty cool system
Well thanks, you're a pretty cool person.

>Do you think you could add events for TARGET_UNIT and TARGET_POINT
I assume you mean the events for when unit is issued a target/unit/notarget order. Done. Thanks for the hit of inspiration.

>whats up with saying the alternate interface is not recommended? Is it just because you need to make your functions return false?
Yep. Pretty much. I couldn't be bothered explaining how to use it or why in any more detail. But it's stable and all, perfectly fine to use. Just make sure if you want to remove an action you use GT_RemoveTriggeringAction() to remove actions as opposed to GT_UnregisterTriggeringEvent() to remove events, or it will leak a trigger.

>i can't see that being reached ever
Correct. It means you'd need 8191 triggers or something like that to go with it. But I must mention all issues... But that's why that's in the details, not the cons. :thup:

Thanks again for the encouragement.

Version 1.04 released. Sorry to Daxtreme who will need to switch his calls to GT_AddSpellEffectAction(function DoStuffReturningFalse, 'A00X'). If you have any problems, check the good ol' documentation. I felt compelled to change the syntax (before the system gets too popular, assuming it does) because it feels more intuitive this way.

Demo map is uploaded. Please approve this system!

 

[Kenny]

Just tested it on a spell (Path of Shadows) with a more complicated conditions system (needed 3 different orderid's and an ability with a level > 0) and it still worked fine, and cut down the code by 5-8 lines.

May I suggest adding a GT_AddHeroSkillAction() or GTAddLearnsAbilityAction() for EVENT_PLAYER_HERO_SKILL, as it would come in handy for passives and such.

Also the syntax and naming conventions are easier to remember than i originally thought for this. For naming, if you know your events, its just GT_Add*Event*Action(), and if you dont know your events, i think it would be easier to just remember the functions from GTriggers.

EDIT:

I just took a look the script and realised all the events run off EVENT_PLAYER_UNIT_ while if you added GT_AddHeroSkillAction() it would need EVENT_PLAYER_HERO_.

Could that be fixed by just expanding the macro? like EVENT_PLAYER_$EVENT$ and then having UNIT_SPELL_EFFECT, UNIT_SPELL_CAST and HERO_SKILL. Or is it a little more complicated than that.

 

[Jesus4Lyf]

>needed 3 different orderid's
You can actually even register multiple orderids on one trigger, by attaching more than one event, if you so desire.

>worked fine, and cut down the code by 5-8 lines.
Sweet. :thup:

>May I suggest adding a GT_AddHeroSkillAction() or GTAddLearnsAbilityAction()
Done. Version 1.05. GT_AddLearnsAbilityAction/GT_RegisterLearnsAbilityEvent.

>Also the syntax and naming conventions are easier to remember than i originally thought for this. For naming, if you know your events, its just GT_Add*Event*Action(), and if you dont know your events, i think it would be easier to just remember the functions from GTriggers.

Glad you think so! I actually changed the syntax in version 1.04 to try to acomplish this.
Used to be like... AddActionToXEvent which was lame.

>Could that be fixed by just expanding the macro? like EVENT_PLAYER_$EVENT$ and then having UNIT_SPELL_EFFECT, UNIT_SPELL_CAST and HERO_SKILL.

Yep, that's exactly how I did it. But I only just read this now. Haha...

Thanks for your interest in the system and willingness to test it.

 

[Sim]

> Careful what you repeat, Dax!

Hmm, the guy that told me this did so a while ago, and I was still re-getting into vJASS so I kind of believed him. Also, it seemed pretty logical.

But blizzard's coding isn't logical.

Also, I will get to test this system in my friend's huge map soon, with 400 custom spells (I won't convert them all there...), and so things will be set concerning its stability.

Nice new version! Can't wait to use it in my spells. As of now, I can tell you it looks promising, stable, and yet so simple!

 

[Jesus4Lyf]

Simple, and yet ~500 lines long!

Anyway, let us know how that goes.

PS. I did add the demo map requested for approval.

 

[saw792]

The current 'knowledge' seems to be that null boolexpr leak only in GroupEnums. If you'd like to test that one as well in your own way we can have some more supporting evidence.

 

[Jesus4Lyf]

I find no evidence in favour of "The current 'knowledge'".

Enclosed is my test. Just do call Test() and see for yourself.

function H2I takes handle h returns integer
return h
return 0
endfunction
function Test takes nothing returns nothing
local group eg
loop
call BJDebugMsg("Throw Handle: "+I2S(H2I(CreateGroup())-0x100000))
set eg=CreateGroup()
call GroupEnumUnitsInRect(eg,bj_mapInitialPlayableArea,null)
call DestroyGroup(eg)
set eg=null
call TriggerSleepAction(0.1) // Must wait for handles to be recycled.
endloop
endfunction

If null handle doesn't leak, this should leak exactly one handle per tick, the group created in the Throw Handle line. In other words, the number displayed should count up by 1 if it doesn't leak, and by 2 or more if it does.

The result? It counts up by 1.

So I say this is an absolute myth until someone shows me otherwise.

 

[Azlier]

Just because it doesn't leak a handle doesn't mean it's leakless. Nothing in Jass is watertight. Null boolexprs in group enums are proven to leak. Disproving that null in event registry leaks, I don't think there is any big conclusion. Not yet.

 

[Jesus4Lyf]

Lol, sorry Bob, I did indeed already remove the part of my post that was relevant to. I figured it out. :thup:

May I ask you to spoiler your post or something?

>Just because it doesn't leak a handle doesn't mean it's leakless
Other leaks are very rare. But one such is proven in this thread (event registry on triggers that are never destroyed leaks delay into other maps, but does not leak a handle), and GTrigger helps solve it.

>Null boolexprs in group enums are proven to leak
Then show us the proof, please.

 

[Builder Bob]

May I ask you to spoiler your post or something?

I removed it since it was not needed anymore.

However, when counting handles I'd strongly recommend eliminating as many potential influencing factors as possible. I'm talking about creating handles dynamically such as that group up there. Use globals wherever you can to minimize them affecting the outcome.

In addition, I don't think TriggerSleepAction() is equivalent to letting a function finish running and starting again. It might do many of the same things, but not all.

 

[Jesus4Lyf]

Eh, you're right. But I don't beleive it will change anything, and this is completely off topic now. I'm happy for you to post a new thread with your test in JASS help, discussing the issue, and linking to there from here if you'd like to continue further. This discussion should get back to GTrigger.

 

[Builder Bob]

Eh, you're right. But I don't beleive it will change anything, and this is completely off topic now. I'm happy for you to post a new thread with your test in JASS help, discussing the issue, and linking to there from here if you'd like to continue further. This discussion should get back to GTrigger.

There's no need. Personally I don't think using null as a filter in GroupEnum's leak anyway. None of my tests give any indication that it should.

As far as GTrigger goes, I'd like to see it being expanded to UnitType events as well. I like how this method reduces the number events triggering at any given moment. You may disagree though.

 

[Jesus4Lyf]

>I'd like to see it being expanded to UnitType events as well

It has been. Note the UnitDies event.

I was thinking of adding UnitAttacked, by how often is that used? Usually it's UnitTakesDamage, and but I believe you must specify a specific unit for that. Let me know if you think any others should be added.

 

[Kenny]

Can I just ask what you meant by this:

>needed 3 different orderid's

You can actually even register multiple orderids on one trigger, by attaching more than one event, if you so desire.

I just want to make sure I am using this correctly.

 

[Jesus4Lyf]

You can add multiple GTrigger events to one trigger.

call GT_RegisterXEvent(trigger,case1)
call GT_RegisterXEvent(trigger,case2)
call GT_RegisterXEvent(trigger,case3)

Likewise you can remove these in the same manner later, if you destroy the trigger.

Let me know if you have any problems with that. I didn't actually test it, but I don't believe it does anything special that could break anything. In every way, GTrigger should function exactly like WC3 events (except that you need to unregister them manually if you destroy the trigger).

PS. Is this going to get approved? I know many people are already using it and I've put a lot of work into it, and followed Romek's request for a demo map. Anything else required?