Staredit Network > Forums > SC1 UMS Mapmaking Assistance > Topic: "Trigger limit": how many is too many?
"Trigger limit": how many is too many?
Jun 20 2019, 12:12 am
By: Brusilov  

Jun 20 2019, 12:12 am Brusilov Post #1



At what point does a map begin to become "over-saturated" with constantly firing triggers, which can lead to high lag or latency for players?

Right now I'm still working out the kinks for different systems my map requires (economy, spawns, sieges, etc). However, no matter how elegantly I trigger things to reduce the overall numbers (no thanks to missing boolean operators like "or" :rolleyes:), I did some quick calculation and expect my map to probably hit somewhere between 75,000-100,000 lines of triggers in order to achieve a playable beta. Namely, I have around 150 provinces on my map, and the spawn triggers for each province alone are 400 lines apiece (I have to do this per-province because I use EUD's to detect the health of a specific unit in each province for calculations). And this is before I even get to "historical flavor" scripting.

I feel like I'm pushing things pretty far with lots of triggers that are constantly firing every second, but maybe I'm not?

Post has been edited 1 time(s), last time on Jun 20 2019, 9:46 am by Brusilov.



None.

Jun 20 2019, 11:35 am jjf28 Post #2

Cartography Artisan

I don't know that there's so much an amount of triggers that'll immediately cause lag (although some tremendous amount like 20k triggers might) so much as what actions are always firing or what conditions/what condition order you're using, see this thread for such details http://www.staredit.net/topic/15607/



Rs_yes-im4real - Clan Aura - jjf28.net84.net

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

Jun 20 2019, 1:03 pm Brusilov Post #3



Oh man, I'm going to have a lot of 'bring' triggers. Like I say, I've got around 150 provinces on my map that have around 10 bring/location based triggers each. Thankfully there are a lot of switches and death counters involved, so perhaps that will prevent them from constantly firing? When Starcraft goes through a trigger, once it hits a condition that it doesn't satisfy, does it continue to check the rest of the conditions in the trigger or does it simply skip and go to the next one?

Also, does anyone think things have changed at all since Remastered?

I'm worried about getting over my head because I don't understand Starcraft's limits too well.



None.

Jun 20 2019, 1:26 pm Brusilov Post #4



So according to this, it makes sense to swap out "brings" with "commands".

Right now I have a siege trigger: if 'foes' brings 'at least' 8 men to province, AND if 'current player' brings 'at most' 7 --> initiate siege. Could I replace this trigger with simply "foes commands at least 8 men at province" + "foes commands the most men at province", and this would work identically as well as help? I'd actually never even used the "command" function before. I didn't know what it was good for.



None.

Jun 20 2019, 1:56 pm Dem0n Post #5

ᕕ( ᐛ )ᕗ

Command isn't location specific. It's just a general condition checking if the player has x number of units. If you want to check at a location, you have to use bring.



Memes gather, and now my watch begins. It shall not end until my death. I shall take no wife, hold no lands, father no children. I shall wear no crowns and win no glory. I shall live and die at my post. I am the sword in the darkness. I am the memer on the walls. I am the shield that guards the realms of memes. I pledge my life and honor to the Meme's Watch, for this meme and all the memes to come.

Jun 20 2019, 2:03 pm jjf28 Post #6

Cartography Artisan

There are location specific command the most at/command the least at conditions - you should expect those to have the same or slightly greater runtime than brings, but if you were otherwise using a set of multiple bring conditions using the one condition would be better.

There are also non-location specific command/command the most/command the least conditions; if you can use these instead of bring for your purpose these are more efficient.

Quote
- If a trigger specifies "bring to anywhere", replace it with command
- If a trigger's purpose is to measure how many units of type x are on the map (or at the only location they can be at), use command
- If (a) trigger(s) purpose is to compare how many units of type x are on the map, use the appropriate command the most/least condition
- If you are doing comparison between number of units at a location using multiple brings, replace those with the appropriate command the most/least at condition.
- If you need to know specifically whether a unit or units are at a specific location, use bring




Rs_yes-im4real - Clan Aura - jjf28.net84.net

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

Jun 20 2019, 3:33 pm Oh_Man Post #7

Find Me On Discord (Brood War UMS Community & Staredit Network)

My RPG has 41,764 triggers and doesn't lag, but I couldn't tell you how many are running simultaneously though.

Best practice if you are worried about lag is order your conditions so the ones least likely to be met are at the top, because Starcraft stops checking the rest of the conditions if one is false; it skips over them and starts checking the next trigger.

Next best practice is avoid unnecessary use of Always condition and when possible group your Always condition's actions into single triggers. Eg. replace:

Conditions: Always
Actions: Set DC A to X
Conditions: Always
Actions: Set DC B to X

with:

Conditions: Always
Actions: Set DC A to X, Set DC B to X




Jun 20 2019, 3:43 pm Dem0n Post #8

ᕕ( ᐛ )ᕗ

Quote from jjf28
There are location specific command the most at/command the least at conditions - you should expect those to have the same or slightly greater runtime than brings, but if you were otherwise using a set of multiple bring conditions using the one condition would be better.
Oh yeah, completely forgot about those. I don't think I've ever used them. Always used Bring instead.



Memes gather, and now my watch begins. It shall not end until my death. I shall take no wife, hold no lands, father no children. I shall wear no crowns and win no glory. I shall live and die at my post. I am the sword in the darkness. I am the memer on the walls. I am the shield that guards the realms of memes. I pledge my life and honor to the Meme's Watch, for this meme and all the memes to come.

Jun 20 2019, 7:02 pm Brusilov Post #9



Quote from Oh_Man
My RPG has 41,764 triggers and doesn't lag, but I couldn't tell you how many are running simultaneously though.

Best practice if you are worried about lag is order your conditions so the ones least likely to be met are at the top, because Starcraft stops checking the rest of the conditions if one is false; it skips over them and starts checking the next trigger.

Perfect, that's just what I needed to hear. Every given trigger has like five or six death counters and switches, so moving the bring/location triggers to the end of the stack is no problem. I had never considered that order of operations was actually important before.



None.

Jun 20 2019, 7:25 pm Suicidal Insanity Post #10

I see you !

Depending on how likely it is that the player has N units of a type, you could also do "commands at least 10 marines" followed by "commands/brings 10 marines at location"




Jun 21 2019, 11:39 am Moose Post #11



Quote from Brusilov
At what point does a map begin to become "over-saturated" with constantly firing triggers, which can lead to high lag or latency for players?
This will depend on the CPU speed of the players, or more specifically the slowest CPU speed among the players.


Quote from Brusilov
When Starcraft goes through a trigger, once it hits a condition that it doesn't satisfy, does it continue to check the rest of the conditions in the trigger or does it simply skip and go to the next one?
Correct, trigger conditions are a logical and, which includes short-circuiting. (given a AND b, no need to look at b if a is false)


Quote from Oh_Man
Best practice if you are worried about lag is order your conditions so the ones least likely to be met are at the top
This is not strictly true if the condition least likely to be true still takes a long time to evaluate. Mathematically speaking, optimal trigger condition ordering will minimize average evaluation time, or expected value of evaluation time, which is the probability of the condition being false multiplied by the time it takes to evaluate the condition.

For example, if a Bring condition is 20% likely to be true but a Deaths condition is 90% likely to be true, you would still want the Deaths condition to be first if the Bring condition takes more than 8 times as long to evaluate versus the Deaths condition.

This is likely the case, since something like a Deaths condition is just doing some arithmetic to find a location and memory and look it up, whereas a Bring has to iterate over every unit and check its location boundaries, which is relatively speaking a lot more to do.

In practice, this is probably difficult to quantify given you need to know ratios of evaluation speeds of conditions to one another and have accurate estimates of the probability of your conditions being true.


Quote from Oh_Man
Next best practice is avoid unnecessary use of Always condition and when possible group your Always condition's actions into single triggers.
While this certainly is a best practice, it's not for execution speed unless you have extraordinarily large numbers of always triggers. Assuming that that the always condition is implemented reasonably (and the optimization you described is not made under the hood for you), it should just be checking "if (true)". If your CPU gets bogged down evaluating "if (true)" a hundred times, then it's absolutely hopeless to loop over a thousand units to evaluate a bring condition. You should still do this, but for readability and more organized triggers.


Depending on how likely it is that the player has N units of a type, you could also do "commands at least 10 marines" followed by "commands/brings 10 marines at location"
This sounds like a dubious practice for similar reasons from my response to Oh_Man. You would need to know the ratio of evaluation speed of Bring to Commands. Which is the ratio of iterating over every unit and just checking what it is versus iterating over every unit, checking what it is and if it is a specific unit, checking its location coordinates. If the former is not fast enough compared to the latter, then the average evaluation time will be longer with this method.

This will also suffer in the worst case performance; that is, if the command condition is true, then the bring condition still has to be evaluated. Which means after looping over every unit to check what it is for the Command condition, now we have to loop over every unit again to check what it is (ie, information that has already been checked) and check its location boundaries for the Bring condition.

For this to be a good recommendation, you would need Command to be significantly faster than Bring and you would want that Command condition to be false most of the time. When the Commands condition is true, the conditions don't short-circuit and no evaluation time is saved, so you're in the worst performance case.




Jun 21 2019, 12:23 pm jjf28 Post #12

Cartography Artisan

Quote from Moose
Depending on how likely it is that the player has N units of a type, you could also do "commands at least 10 marines" followed by "commands/brings 10 marines at location"
This sounds like a dubious practice for similar reasons from my response to Oh_Man. You would need to know the ratio of evaluation speed of Bring to Commands. Which is the ratio of iterating over every unit and just checking what it is versus iterating over every unit, checking what it is and if it is a specific unit, checking its location coordinates. If the former is not fast enough compared to the latter, then the average evaluation time will be longer with this method.

There's no need for the non-location based commands to loop through units, all the unit statistics are cached in tables next to the death table, command is presumably about as fast as a death check.



Rs_yes-im4real - Clan Aura - jjf28.net84.net

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

Jun 21 2019, 2:14 pm Moose Post #13



My implementation was naive, but I also don't have actual code. Since the implementation of Command is just a lookup of a cached value, then we do know the ratio of evaluation in speed of Bring to Commands is very favorable. You would take a small hit in worst-case performance but it's negligible compared to the savings in the average case. Sounds like it can be worth it to put a Bring in front of Command. (unless there's also some smart caching and optimizations behind Bring, but it sounds like that's not the case.)




Jun 21 2019, 3:57 pm Suicidal Insanity Post #14

I see you !

Ya I am working under the assumption that cache misses (to access table data) are trivial, while searching for units in a box (even though that is implemented in a much more optimized way than looping over all units) is still orders of magnitude slower.

Although if blizzard had been very clever when implementing triggers, they would do the same thing in the bring condition. Its unlikely though that they worried about performance issues here, since hyper triggers aren't by design.




Jun 21 2019, 6:29 pm NudeRaider Post #15

We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch

Ya I am working under the assumption that cache misses (to access table data) are trivial, while searching for units in a box (even though that is implemented in a much more optimized way than looping over all units) is still orders of magnitude slower.

Although if blizzard had been very clever when implementing triggers, they would do the same thing in the bring condition. Its unlikely though that they worried about performance issues here, since hyper triggers aren't by design.
It doesn't matter (much) if you use hyper triggers when considering lag. You will get lag as soon as the trigger evaluation takes longer than the frame rate (42ms on fastest). You just don't get it as often without hypers, but if your game stutters slightly every 1.5s will still be annoying enough to be avoided. Intermittent lags might even be worse for timing critical maps like bounds than a constant slow-down.

Also, both brings and commands are cached and thus checked pretty fast, making them on par with dc or switch checks. Anything with least/most is pretty costly and should be on the bottom of the condition list. I can't say for certain, but I'd expect Accumulate, Elapsed Time, Score, Opponents and Kills to be pretty fast as well.




Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[06:06 am]
NudeRaider -- KrayZee
KrayZee shouted: Voyager7456 Somehow I misread your shout. "Glad I can entertain you in Nude" as if you sent a racy photo, video or something.
nah, he just made a comment that had us laughing very hard.
[06:02 am]
NudeRaider -- Zoan
Zoan shouted: sraw531 you can’t move buildings afaik
yes you can.
[2019-10-16. : 10:03 pm]
Dem0n -- no
[2019-10-16. : 8:26 pm]
GGmano -- Is here a forum only for temple siege?
[2019-10-16. : 4:20 pm]
KrayZee -- Voyager7456
Voyager7456 shouted: Glad I can entertain you Nude
Somehow I misread your shout. "Glad I can entertain you in Nude" as if you sent a racy photo, video or something.
[2019-10-16. : 2:26 pm]
martosss -- Moose
Moose shouted: martosss IIRC, the plan was to go 64-bit only eventually so they're interested in differences between the versions
well I might have found 1 bug for them to fix - some maps load on 32 bit, but not on 64 bit game version
[2019-10-16. : 2:19 pm]
Zoan -- sraw531
sraw531 shouted: I'm pretty sure you would move the building away at some point. When you do so, you can give it to someone else. I was thinking nexi because its possible you could encourage the computer to expand to a specific spot
you can’t move buildings afaik
[2019-10-16. : 10:10 am]
Moose -- martosss
martosss shouted: jjf28 OK, I have 1 more question - are you using 32 bit SC:R or 64 bit ? In game settings there's an option to switch to 32, is it checked? I just tried hosting the map with 64-bit SC:R and it failed... I ticked the option to use 32 bit SC:R => it worked and map was hosted. So I guess the issue still exists for 64 bit SC:R ? I also tried calling a friend and he couldn't see the map when he entered the lobby. Weird, I might have to report this to Blizzard?
IIRC, the plan was to go 64-bit only eventually so they're interested in differences between the versions
[2019-10-16. : 5:27 am]
O)FaRTy1billion[MM] -- or a magic box :(
[2019-10-16. : 3:31 am]
martosss -- FaRTy1billion
FaRTy1billion shouted: how about 5 minerals
you can't even get a scarab with those!
Please log in to shout.


Members Online: Roy, izujaxuc, jjf28