[General] Maximum size of 1 trigger

[Kusanagi Kuro]

I've read somewhere that trigger has a limit of how long they could be. If u makes the trigger's length passes that limit, it will skip the remaining action. So I would like to ask that what is the limit of 1 trigger? And when necessary, is there anything I can do to bypass that limit?

 

[WaterKnight]

You are probably referring to the oplimit. There is only a limited amount of instructions a thread can handle before it terminates. A thread can be a trigger execution, timer callback, ForGroup-iteration etc. They are kinda independent from each other, so if one collapses, it does not affect the others, only returns.

The amount is that high that you cannot practically reach it without big loops or recursions. You can reset the counter by inserting Waits or you outsource into a new thread.

 

[Kusanagi Kuro]

Not quite get it ==. I get the first part but what do u mean "outsource into a new thread"? My trigger is really long (contains about 2 big unit group loop, and each of them has 2 more smaller unit group inside it). And somehow my spell doesnt work although I've checked over and over again. So I can only think the most possible problem in this case would be its length.

 

[DivineLight]

If u makes the trigger's length passes that limit, it will skip the remaining action

it's not the trigger's length, but the variable array

 

[WaterKnight]

Insert test messages to analyze up to which point your trigger runs.

 

[Arhowk]

Highly unlikely. The op limit is 300k processes, and each line is about 1-6 (probably much more for GUI)

WaterKnight is correct to place debugs to see where its going wrong. An example of doing this would be like

Game - Print "1"
Set Tx = 1
Game - Print "2"

if it printed 1 and not 2, you'd know set tx = 1 is the issue because the trigger stops after that. (SC2 does this much better.... alike Java and alot of other advanced langs)

you can also put them before, after, and in a loop to see how the loop is running

 

[Dr Super Good]

There is an op-limit to JASS threads that was added to try and prevent bad script code from freezing the game. Once the op limit is reached the thread is killed no mater the state of execution. It is unclear how it is measured but more complex code will expend the limit faster than simple code. TriggerSleepAction will reset the op-limit at the cost of a noticeable delay.

Threads can be killed for other reasons as well. Division by 0 for example.

 

[WaterKnight]

There was a wc3jass article once that listed the prices for different operations.

 

[deathismyfriend]

Try to make your trigger more efficient. If you can't post it on here so we can help to make it more efficient.

 

[Vinz]

I have a trigger with over 15k words (probably some 1.8k lines) and it still works.

Not quite get it ==. I get the first part but what do u mean "outsource into a new thread"? My trigger is really long (contains about 2 big unit group loop, and each of them has 2 more smaller unit group inside it). And somehow my spell doesnt work although I've checked over and over again. So I can only think the most possible problem in this case would be its length.

How big are the loops? I have an initial cast trigger which takes care of all abilities, and it still seems to work.

 

[deathismyfriend]

I have a trigger with over 15k words (probably some 1.8k lines) and it still works.



How big are the loops? I have an initial cast trigger which takes care of all abilities, and it still seems to work.

it has to be very big or inefficient like GUI is. Jass is efficient if done right.

 

[UngThanhNhan]

I think a trigger has an... infinite length! :|
I just think this. in fact, I have never make a trigger has a full length! (just because... I can't do it )
but, I have ever seen a trigger (Jass) has about 10000 lines to develop for all a map!
---
ah... may be a trigger will have a maximum length when the map which contains it reach a maximum size (about 9000 KB = 9 MB), I think if you make a trigger is bigger than 9 MB, you won't be able to save it. but, in fact, you can still write it more, but saving is... impossible!
and, just I think that

 

[Maker]

I think a trigger has an... infinite length! :|
I just think this. in fact, I have never make a trigger has a full length! (just because... I can't do it )
but, I have ever seen a trigger (Jass) has about 10000 lines to develop for all a map!

You can exceed the operation limit with just a few lines of code.

 

[DivineLight]

i don't think trigger length has anything to do with this

 

[Daffa]

The amount of operation for each thing are different, some may cause OP Limit to be hit faster than others, just like others say.
Using TriggerSleepAction will reset the counters as everybody said.
Also, Jass can be made efficient (as DIMF said) and Jass can reduce the operation to areas which can't be done via GUI.

 

[WaterKnight]

But jass users have higher expectations and actually strive for some quality in their maps, so things get often more complex for them.

 

[deathismyfriend]

But jass users have higher expectations and actually strive for some quality in their maps, so things get often more complex for them.

More complex yes but a ton more efficient as well.
Just take multiboards for example. I have 4 of them in my map. Each showing stats for different things. Up to 13 stats i believe. With triggers that update the stats.
I think it's only about 2000 lines of code but in GUI it would be about 4000 or more.

 

[WaterKnight]

The amount of lines does not exactly determine the amount of operations or execution time.

 

[deathismyfriend]

The amount of lines does not exactly determine the amount of operations or execution time.

I know this it is the function calls and setting of variables that count towards the limit.
I just said it as an example of efficiency. But i should've said that the amount of function calls are a lot greater when using multiboards in GUI. Same with the amount of leaks in GUIs multiboards.

 

[WaterKnight]

The GUI multiboard cell-setting functions are crazy anyway.

function MultiboardSetItemValueBJ takes multiboard mb, integer col, integer row, string val returns nothing
    local integer curRow = 0
    local integer curCol = 0
    local integer numRows = MultiboardGetRowCount(mb)
    local integer numCols = MultiboardGetColumnCount(mb)
    local multiboarditem mbitem = null

    // Loop over rows, using 1-based index
    loop
        set curRow = curRow + 1
        exitwhen curRow > numRows

        // Apply setting to the requested row, or all rows (if row is 0)
        if (row == 0 or row == curRow) then
            // Loop over columns, using 1-based index
            set curCol = 0
            loop
                set curCol = curCol + 1
                exitwhen curCol > numCols

                // Apply setting to the requested column, or all columns (if col is 0)
                if (col == 0 or col == curCol) then
                    set mbitem = MultiboardGetItem(mb, curRow - 1, curCol - 1)
                    call MultiboardSetItemValue(mbitem, val)
                    call MultiboardReleaseItem(mbitem)
                endif
            endloop
        endif
    endloop
endfunction

 

[deathismyfriend]

The GUI multiboard cell-setting functions are crazy anyway.

Yes that was my point of how GUI uses more of the bytecode limit than jass does.
There are plenty of other examples but that is one of the easiest to see.

 

[Kusanagi Kuro]

:|. The fact is I'm a GUI user, not JASS user ==. I've solved the problems with my trigger. But I'm curious about oplimit so I'll ask what thing I can do to separate a long long trigger so that it wont exceed the oplimit.

 

[Dr Super Good]

It has nothing to do with trigger length, only trigger complexity. You could probably make a function >10,000 lines long and not hit the op limit as long as you only execute a small part of it at any call.

Here are the main ways to get around the op-limit.
- TriggerSleepAction: Calling this function resets the thread op-limit by re-scheduling it for execution later. Locals are retained (obviously) but a noticeable delay occurs which is dependant on host latency.
- Various trigger running natives: If one thread op-limit is not enough then why not use two? Starting new immediate threads will give them a clean op-limit so you will be able to perform more operations. All that is left is for you to use a global to coordinate the threads (remember, only 1 can run at any given time and they execute until finished or blocked) and you can do more work. However you can do too much work, forcing the game to drop frames and possibly become unresponsive for considerable time if you do something computationally expensive.
- Optimize: Instead of making the op-limit larger, make the operations required smaller. More efficient code will mean less operations used. This has the advantage of improving game performance as it will spend less time executing the same procedure compared to breaking a less efficient procedure across multiple threads. Only problem is there is a limit to how optimized something can be.