System Trigger Utils v1.00

[Jesus4Lyf]

>and then add some Conditions dynamicly.
Sounds like something Event would be useful for.

 

[Viikuna]

Event is cool, but I might also use Cassiels EventArrays or something similiar. ( I kinda like your struct usage, though, so I dont really know. Either way, Event is real nice. )

edit. EventArrays has RegisterPriorityEvents, though..

 

[emjlr3]

well I completely disagree with just about everything you said Jes - but explaining myself isn’t going to get me anywhere with you - so go ahead and make your own system, and call it a day

**or perhaps I will, just for shits and giggles

ExecCount attaching

no idea how that works, sorry

Furthermore, the usage section doesn't even document the set/get data functions.

script documentation does clearly, I neglected to update the first post adequately in my haste before I went to bed, so sorry

If a map using this system lasts longer than the mapper expected, core functions of the map would suddenly fail for not one but TWO reasons - the offset may not be set high enough, and the maximum number of triggers may not be set high enough. What if a map has a high turn-around on triggers?

Exactly why they are user specified, he can make it faster, if his map has few handles, or slower if it has more - its quite simple and effective

Worst of all, you haven't documented ANY of these downsides! A moderator, posting an unstable system, naming it after a stable and well founded and used system (TimerUtils) is really quite misleading. Calling it TriggerUtils is a misnomer.

it works identical to timerutils blue you SPED, with relation to attaching - the downside are clearly displayed as error messages internally to the system - perhaps better documentation is required - however, these downsides are well documented over the past few years...I love how you call this unstable, then praise timerutils, an identical system

And why name this after TimerUtils anyway? This doesn't support NewTrigger/ReleaseTrigger recycling, which the name suggests it might.

who ever said utils implied recycling? - seen the new armor utils, it doesn’t recycle armor... i named it such because none exists

Your set/get data functions don't inline. What's the point of using H2I in a way that's both slow AND unstable?

speed is probably the least important aspect of attachment systems, you just haven’t realized this yet

Jass:
set Time=Time+1
set r = TimerGetElapsed(Tim)+Time*TimeoutTime should represent the total time passed in the game. This is actually inefficient anyway, you should just use TimerUtils or something.

you are joking right? - please say you are, you may have just lost all credibility in my eyes

At very least, I would like to see a name change.

to what point and purpose?

This system will work when you implement ExecCount attaching, name DestroyTriggerEx ReleaseTrigger instead, make it still destroy the trigger after time, but also in the mean time generate a new trigger with the same ExecCount number, and make the get/set data functions inline. Until then I would not use this system.

recycling triggers is impractical for two reasons - events leak and clearing triggers does not work - this system is not intended for you, clearly, you're enamored with execount and hell bent on speed

ReleaseTrigger would be silly, it in no ways describes what is happening

I can’t adequately defend H2I against execount because, like I said, im not sure how it works - care to explain?

 

[Waaaaagh]

I think it's really great how you are encouraging terrible coding practice. I would have expected better from you; you are apparently one of the go-to Jassers around here.

 

[emjlr3]

wtf is that supposed to mean? Where is this terrible coding practice of which you speak? I think I may just neg rep you for a useless, derogatory post...expplain yourself or be gone

 

[Jesus4Lyf]

My system would do something different, and is off topic.

In this thread, I'm more concerned with improving yours if possible. ExecCount attaching is actually useless here (because you allow trigger actions), but the H2I is still unprotected. You might as well do a simple Mod hash, and discard colliding handles. Implement Release and make it simply do your delayed destroy and add another trigger to the track that has an unused slot.

Your system currently fails the H2I test (I haven't actually tried it, but it should, or at least be dependent on the order the libraries init) - http://tinyurl.com/TestH2I

You can solve it by removing the offset, and making the id ModuloInteger(t2i(trig),8191) instead. That alone is already 100% stable for trigs created on init (and you can inline the modulo for kicks).

Then, when a trigger is "released" you can do this simple loop:

set Taken[ModuloInteger(t2i(destroyedTrig),8191)]=false
loop
set newTrig=CreateTrigger()
exitwhen not Taken[ModuloInteger(t2i(newTrig),8191)]
call DestroyTrigger(newTrig)
endloop

Because handles are not freed until a wait is called.

Then your system will no longer have a map-wide limit of dynamic triggers, and neither will it fail the H2I test, nor require an offset specified.

Powerful stuff!

Edit for edit: (emjlr3 edited after I'd brought up the post)
>then praise timerutils, an identical system
I don't praise it. It's just appropriate for this.

>you are joking right? - please say you are, you may have just lost all credibility in my eyes
Nope. Using a timer system for this is good. TU just seems to be the leading system.
Um. You do realise the timer variable thing is a REALLY good idea, if you don't go for a timer system?

>recycling triggers is impractical for two reasons - events leak and clearing triggers does not work - this system is not intended for you, clearly, you're enamored with execount and hell bent on speed
Read the above posts between my big one and your response.
And I'm hell bent on stability. YOU'RE hell bent on speed by not using protection on H2I.

 

[emjlr3]

i dont get what you mean by protecting H2I

and i dont get what your script there does at all

 

[Waaaaagh]

wtf is that supposed to mean? Where is this terrible coding practice of which you speak? I think I may just neg rep you for a useless, derogatory post...expplain yourself or be gone

Why should you have N triggers when you could just have 1? There is no difference, other than the whole leaking events thing. TimerUtils has a valid claim to its existence; we use timers for precision, thus one timer rounding off periods and such is just not good enough for things which require such exactness. But for triggers?


-[1]- (one unit event to a local, dynamic trigger) x (instances of your spell)

-[2]- (one unit event to a global, static trigger) x (instances of your spell)

-[3]- (one any unit event to one trigger) x (1)


Notice how they are all the same thing, ranked from worst efficiency (both of processing power and in time taken to write the code) to best. You are enabling the creation of level 1 code here. Keep in mind that level 1 coding in this case is TERRIBLE. See? Right there. That was my point. You are asking people to use this and go write TERRIBLE code with it.

-

Why? So you can say, "I made this system and people use it! Yay! I am a god!" Seriously? Come on:

I would have expected better from you

 

[Tyrande_ma3x]

Sure they are, mostly Waagh. EDIT: Okay, ninja deleting your post Daxtreme is not fun.

Is there any way you could inline this thing:

function GetTriggerData takes trigger t returns integer
    local integer id = t2i(t)-Offset
    
    debug if t==null then
        debug call BJDebugMsg("|c00ff0303GetTriggerData error: null triggers cannot have retrievable data.")
    debug elseif id<0 then
        debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger id is too small, reduce Offset value.")
    debug elseif id>RealArraySize then
        debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger id is too large, increase ArraySize value.")
    debug elseif TriggerData[id]<=0 then
        debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger has no attached data.")
    debug endif
    return TriggerData[id]
endfunction

to something like:

function GetTriggerData takes trigger t returns integer
    return TriggerData[t2i(t)-Offset]
endfunction

but still keep the debug messages? This way it's going to get as fast as possible when attaching and such (assuming set function is done the same way). Still, it may need some extra safety like a gamecache backup since you never know what the user can do.

 

[Viikuna]

I would have expected better from you

I lolled.

I dont use dynamic triggers either, but that doesnt mean that someone can use them without bugs. And yes I think they evil and everything, but I still realize that they can be used without bugs so they there must be something good in them too.

I just dont believe anymore that there is only one and the only way to code things and all the other ways suck. ( Thats Jesu4Lyfs fault actually. He makes so damn weird systems that I had to question my old beliefs. )

Pretty funny actually. I never expected anything from you Waaaagh, but you still managed to amuse me.

Still, it may need some extra safety like a gamecache backup since you never know what the user can do.

( funny thread ) User can do anything and no matter what you do they still find some way to fuck up everything. Just have good error messages in your system and you are fine.


And about TriggerExecuteCount attaching. Doesnt TriggerExecuteCount attaching require you to call shitloads of TriggerExecutes to get different indexes for all triggers? Seems lil bit weird method to me, since H2I works too..

 

[emjlr3]

Why should you have N triggers when you could just have 1? There is no difference, other than the whole leaking events thing. TimerUtils has a valid claim to its existence; we use timers for precision, thus one timer rounding off periods and such is just not good enough for things which require such exactness. But for triggers?


-[1]- (one unit event to a local, dynamic trigger) x (instances of your spell)

-[2]- (one unit event to a global, static trigger) x (instances of your spell)

-[3]- (one any unit event to one trigger) x (1)


Notice how they are all the same thing, ranked from worst efficiency (both of processing power and in time taken to write the code) to best. You are enabling the creation of level 1 code here. Keep in mind that level 1 coding in this case is TERRIBLE. See? Right there. That was my point. You are asking people to use this and go write TERRIBLE code with it.

-

Why? So you can say, "I made this system and people use it! Yay! I am a god!" Seriously? Come on:

there are instances when coding with a dynamic trigger shortens code, makes it more efficient, and much easier to script to begin with, I have stated such possibilities before - if you take certain precautions this can be done safely

ex. - caster grabs units in area, for X seconds, when they take damage, the caster deals bonus damage and some stacking effect
but what if you have multiple of this unit/player - now you have to attach your group to your caster (and any other info), and loop through O(n) when a unit takes damage to grab all damage groups its in, and deal those specific stacking effects - or one dynamic trigger per cast, with data attached to it - smaller, easier, faster

Sure they are, mostly Waagh.

Is there any way you could inline this thing:

function GetTriggerData takes trigger t returns integer
    local integer id = t2i(t)-Offset
    
    debug if t==null then
        debug call BJDebugMsg("|c00ff0303GetTriggerData error: null triggers cannot have retrievable data.")
    debug elseif id<0 then
        debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger id is too small, reduce Offset value.")
    debug elseif id>RealArraySize then
        debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger id is too large, increase ArraySize value.")
    debug elseif TriggerData[id]<=0 then
        debug call BJDebugMsg("|c00ff0303GetTriggerData error: trigger has no attached data.")
    debug endif
    return TriggerData[id]
endfunction

to something like:

function GetTriggerData takes trigger t returns integer
    return TriggerData[t2i(t)-Offset]
endfunction

but still keep the debug messages? This way it's going to get as fast as possible when attaching and such (assuming set function is done the same way). Still, it may need some extra safety like a gamecache backup since you never know what the user can do.

I could remove the local integer call - it would be slower in debug mode, but inlined when optimized - if I can ever understand what Jes was saying I amy switch my id method - but his just plum did not make any sense

I lolled.

I dont use dynamic triggers either, but that doesnt mean that someone can use them without bugs. And yes I think they evil and everything, but I still realize that they can be used without bugs so they there must be something good in them too.

I just dont believe anymore that there is only one and the only way to code things and all the other ways suck. ( Thats Jesu4Lyfs fault actually. He makes so damn weird systems that I had to question my old beliefs. )

Pretty funny actually. I never expected anything from you Waaaagh, but you still managed to amuse me.



( funny thread ) User can do anything and no matter what you do they still find some way to fuck up everything. Just have good error messages in your system and you are fine.


And about TriggerExecuteCount attaching. Doesnt TriggerExecuteCount attaching require you to call shitloads of TriggerExecutes to get different indexes for all triggers? Seems lil bit weird method to me, since H2I works too..

that is what I thought - I figured there is not way someone would go through such overhead just to use an alternate attachment method....that is no faster or safer

 

[Azlier]

ExecCount attaching takes much more processing power to initialize, true, but it is much, much safer than H2I. In fact, ExecCount cannot fail providing you use conditions instead of actions.

 

[Romek]

What's with all the talk about H2I being unsafe?
It's fine if it's used properly.
It's perfectly stable as a function too.

In the case of H2I - Offset, it's still perfectly fine. J4L, your 'test script' isn't anything new. We've all known that H2I - offset will fail after 8191 handles.

No good map will have 8191 handles at any one time though.

> Is there any way you could inline this thing... .. ..
Call t2i(t) - offset twice? Sure, it'd suck for debug mode.
But, debug mode isn't for playing anyway.

debug local integer id = t2i(t) - offset

// all the tests, ifs, safety, etc.

return TriggerData[t2i(t)-Offset]

It beats replacing all the 'id' with t2i(t) - offset anyway.

 

[emjlr3]

good idea

h2i will not fail given you provide an adequate array size or your map does not suck (way to many handles)

 

[Jesus4Lyf]

>No good map will have 8191 handles at any one time though.
>h2i will not fail given you provide an adequate array size or your map does not suck (way to many handles)

I resent that.

Please stop making stupid assumptions about high and fluctuating numbers of handles being invalid. And yes, with gaps in the handle count, too. I don't actually just say these things for fun.

 

[emjlr3]

you are the exception, not the rule - but still, a 16382 size array (8191*2) fixes that little problem

I didn't mean to imply that >8191 handles means your map sucks, I meant that if your map does have that many handles, and you are not aware of it, it sucks

just as an example, any of the hero arenas I have made have never exceed 3,000 handles at any given time

anyway, that still does not help me discern what it is you were trying to show me

 

[Tyrande_ma3x]

> just as an example, any of the hero arenas I have made have never exceed 3,000 handles at any given time
Totally wrong, I had a game of your Mini Element Arena with 21k handles just before the end.
Anyway, high handle count does not mean absolutely anything (mostly for the part where your map "sucks"). I wouldn't even care if I had 100k handles as long as my map worked and had no lag issues (assuming the problem couldn't be fixed but I doubt such a situation can happen)...

 

[Jesus4Lyf]

>still, a 16382 size array (8191*2) fixes that little problem
Fair enough.

>if your map does have that many handles, and you are not aware of it, it sucks
This system was born out of the philosophy that "bad practise" can be used, as long as it works. So I wouldn't be too concerned as to which bad practises users are using along with this system. But this isn't really relevant anymore anyway...

However, if you're supporting and even encouraging people to use TriggerActions in dynamic triggers, which the entire sum of what this system is useful for (because DTS is better if you don't use them), then you should really be helping people remove the triggeraction leak. Just to make this system cover appropriate ground, add a TriggerAddActionEx function that attaches the triggeraction returned to the trigger, and make the DestroyTriggerEx function destroy all attached triggeractions.

I'm pretty sure you will need to use linked lists for this if you don't wish to incur other terrible limits on your system. Users should be able to add multiple triggeractions (or no triggeractions) to one dynamic trigger, because it's possible.

And although all you did was mock at this last time, I'll bring this up again:

set Time=Time+1    
set r = TimerGetElapsed(Tim)+Time*Timeout

Time should represent the total time passed in the game. This is actually inefficient anyway, you should just use TimerUtils or something.

If time represents the total time passed, the local real r isn't required.

Another idea which I strongly recommend but assume you won't implement is that you could keep the triggers in the destruction queue in order of their ExpirationTime. This actually isn't hard. It just means you don't recycle any of the queue indexes until all the triggers are destroyed. This means

exitwhen i>Count
if ExpirationTime<i>&lt;=r then</i>

becomes

exitwhen ExpirationTime<i>&gt;Time</i>

and you remove a lot of complexity from your loop! Then this would be more efficient than TimerUtils for this application. Each trigger in the queue would be looped over exactly once (instead of RecycleTimeLimit/Timeout times, so ~75% efficiency save on your periodic function).

These things would make this system really quite cool.

PS.
>Totally wrong, I had a game of your Mini Element Arena with 21k handles just before the end.
>I meant that if your map does have that many handles, and you are not aware of it, it sucks
Would this be saying that his very own map "sucks"? (By the way, that's more than the H2I Test AND Savage Creed... o.o)

 

[emjlr3]

> just as an example, any of the hero arenas I have made have never exceed 3,000 handles at any given time
Totally wrong, I had a game of your Mini Element Arena with 21k handles just before the end.
Anyway, high handle count does not mean absolutely anything (mostly for the part where your map "sucks"). I wouldn't even care if I had 100k handles as long as my map worked and had no lag issues (assuming the problem couldn't be fixed but I doubt such a situation can happen)...

that handle counter was bugged

unfortunetly, I never really ran extensive handle count tests on that map (the counter would have been sufficient for that) - and that was also before I noticed you needed to release multiboard items, therefore I was probably leaking 20 or so handles a second - was still a pretty fun game though, no?

 

[Tyrande_ma3x]

It still is, I really wanted you to continue making it since it was a really nice map... I guess you'll keep your promise and not work on it any more - pretty sad.