System TriggerGroups

[Romek]

In any case, yeah, I guess a large merit of this system is the friendly, intuitive syntax it implements (just like the unit group vs unit array interface), which could be useful in a situation where large numbers of large arrays would be managed as the alternative.

Thanks

@ Romek/Flare

That should error - that's not how .execute() is used. .execute() and .evaluate() are used on function interfaces.

Maybe you'd want to switch to using function interfaces, Romek? Then you could make the trigger Enum function take arguments and remove the need for GetEnumTrigger() calls. It would all be less error-prone (no ExecuteFunc() crashes) and more friendly, not requiring users to use those scope prefixes.

The code argument has already been implemented

function RefreshTriggerGroup takes triggergroup tg returns nothing

Requiring users to call this function seems like a bit of a regression, especially in a system that's supposed to automate things. Destroying dynamic triggers is bad practice anyway. Maybe the check could be omitted (unneeded), or done periodically?

UnitGroups have this problem too.
Also, refreshing automatically gives the user less control over the system

Finally, why not make the extension code part of the system? Packaging it all together doesn't seem like a bad idea.

Well, I split them up because the 'extension' could be easily made using the main system. Those are just the most common tasks.

 

[Darius34]

The code argument has already been implemented

Yeah, I know, but function interfaces and code arguments are different (JassHelper manual, under "Functions as Objects"). The former were practically made for situations like yours, and another thing: you can't pass arguments easily with code variables, and so need function calls like GetEnumTrigger().

You don't really have to use them, but IMO they make everything more functional.

UnitGroups have this problem too.
Also, refreshing automatically gives the user less control over the system

Well, yeah, but removing units is different from destroying triggers - the former is a problem that could arise and that should be fixed, while the latter doesn't need to be fixed, in that it should be avoided as much as possible (or so lots of people at WC3C say). That's why the check could be omitted (a periodic check is not a good idea, on hindsight); that'd just take out support for a method that shouldn't be used.

But yeah, I'm not pressing you, just giving suggestions.

 

[TheDamien]

The code argument has already been implemented

TriggerClearActions is, sadly, bugged. Use TriggerRemoveAction to fully remove trigger actions.

UnitGroups have this problem too.
Also, refreshing automatically gives the user less control over the system

There should not be the need for a refresh at all, it is a problem that comes from using arrays internally. Another problem is the massive wastage of space and hence the size restrictions.

Replace the arrays with linked lists.

 

[Flare]

Well, yeah, but removing units is different from destroying triggers - the former is a problem that could arise and that should be fixed, while the latter doesn't need to be fixed, in that it should be avoided as much as possible (or so lots of people at WC3C say). That's why the check could be omitted (a periodic check is not a good idea, on hindsight); that'd just take out support for a method that shouldn't be used.

It probably wouldn't be used for a situation where you need to destroy triggers. Can't really think of a great example, except perhaps something like guaranteed income triggers (i.e. you get X gold, wood, <other resources> every Y seconds, and there's nothing that'll change that) and you may want to have those disabled until the game actually begins (if, say, there's a game-mode selection at the start, or some form of introduction)

That should error - that's not how .execute() is used. .execute() and .evaluate() are used on function interfaces.

IIRC, .execute/.evaluate don't require you to use a function interface (I remember using it in a [failed] spell, due to a situation where I had mutual recursion)

 

[Romek]

TriggerClearActions is, sadly, bugged. Use TriggerRemoveAction to fully remove trigger actions.

I'll fix that then.

Replace the arrays with linked lists.

I still don't know how to use them with Wc3.. I'll read over the article though. It should tell me about what they are, and why I should use them

Thanks for the comments anyway

 

[Darius34]

It probably wouldn't be used for a situation where you need to destroy triggers.
...

My point was that since that was the case, the whole refresh function could be left out, but whatever.

IIRC, .execute/.evaluate don't require you to use a function interface (I remember using it in a [failed] spell, due to a situation where I had mutual recursion)

Yeah, you're right, and I was mistaken about that earlier. However, .evaluate() and .execute() still can't be used on code variables - they're used on either function interfaces or function names. Checked it out in the JH manual.

 

[Dr.Jack]

Pretty cool! I think a nice addition to the system however would be using indexes.

function GetTriggerByIndex take triggergroup tg, integer index returns trigger
    if tg.trig[index] =! null then
        return tg.trig[index]
    endif
    call BJDebugMsg ("Error! Trigger not in TriggerGroup!")
    return null
endfunction

function GetTriggerIndex takes triggergroup tg, trigger t returns integer
    local integer i = 0
    loop
        exitwhen i > 200
        if tg.trig<i> == t then
            return tg.trig<i>
        endif
        set i = i + 1
    endloop
    call BJDebugMsg (&quot;Error! Trigger not in TriggerGroup!&quot;)
    return 201 // Or whatever you system uses as null...
endfunction</i></i>

:thup:

 

[SerraAvenger]

I still don't know how to use them with Wc3.. I'll read over the article though. It should tell me about what they are, and why I should use them

Thanks for the comments anyway

Look at the end of my last post...

 

[Romek]

Look at the end of my last post...

Still don't get it

Is it really that much better than what is currently being used?

I'll add the TriggerByIndex thing btw.

 

[SerraAvenger]

Still don't get it

Is it really that much better than what is currently being used?

I'll add the TriggerByIndex thing btw.

It is better as you don't have size restrictions anymore. It might be slower, though.

Basically, you have not a single array, but rather than that you have a class that represents an array slot, has a following and a preceeding item.

That class ( In the following, named tg_trig ) has a field called NEXT that "points" to the next tg_trig ( initially none ), and optionally one called LAST that "points" to the previous tg_trig. So what you get is a long list where each item links to the next and the last item, until you come to an endpoint.

Insertion is quite easy: You save your last item in you base class ( triggergroup ) and then go to your last item, create the new item and link it to the last one; Now you save this item to your "last" field.

Deletion is quite easy, too: You just loop through your linked list and once you find the item you
1. link the item's 'next' to the item's 'last' as 'next'
2. link the item's 'last' to the item's 'next' as 'last
3. remove the item

Performing something on the group is really easy:
Just loop through your linked list until your current item is none.

That's it.

 

[SerraAvenger]

Buhp!

Hey...
Your first index to be used is -1
You are, however, referring to index 0 as the first one.
That might lead to unexpected behaviour.

    struct triggergroup [163820] // 819 * 200 (So 819 total groups, with up to 200 triggers in each)
        trigger array trig [200][B]
        integer total = 0[/B]
        .
        .
        .
    endstruct
    
    .
    .
    .

    function TriggerGroupAdd takes triggergroup tg, trigger t returns nothing
[B]        set tg.total = tg.total + 1[/B] // 1 now!
        if tg.total > 200 then
            set tg.total = tg.total - 1
            debug call BJDebugMsg("|cff995500TriggerGroup Error: No more space in TriggerGroup|r")
            return
        endif
        set tg.trig[tg.total] = t
    endfunction
    
    .
    .
    .
    
    function TriggerGroupRemove takes triggergroup tg, trigger t returns nothing[B]
        local integer a = 0[/B]
        loop
            exitwhen a > tg.total[B]
                if tg.trig[a] == t then[/B] // 0 !
                    set tg.trig[a] = tg.trig[tg.total]
                    set tg.total = tg.total - 1
                    return
                endif
            set a = a + 1
        endloop
        debug call BJDebugMsg("|cff995500TriggerGroup Error: Attempt to remove a trigger not in group|r")
    endfunction