I shouldn't think so, simply because of how often it must happen in some maps. If there was a problem I'm sure they either found away around it or didn't have 8 triggers running at the same time.
It depends on how much work each trigger is doing, but in general 8 triggers a second would not be a problem. Most triggers execute so fast that a human will not notice any delay caused by its execution.
Is it a bad thing to have 8 different triggers running every 1 second of gametime?
bad! never ever use timers! there is almost always a event for what you have a timer for, unless you are doing something small like counting game time. if you have 12 players in a game each exciting 8 triggers every 1 second you are going to hit you memory cap of 2.5mb quick. also if the trigger errors for any reason battle net turned it off if its a re-occurring trigger and your trigger will be useless.
Is it a bad thing to have 8 different triggers running every 1 second of gametime?
Not really, 1 second is a very high granularity.
The number of triggers running is less of a deal than the time granularity. A single trigger running every .1 seconds is going to be more performance intensive than 10 triggers running every 1 second.
bad! never ever use timers! there is almost always a event for what you have a timer for, unless you are doing something small like counting game time. if you have 12 players in a game each exciting 8 triggers every 1 second you are going to hit you memory cap of 2.5mb quick. also if the trigger errors for any reason battle net turned it off if its a re-occurring trigger and your trigger will be useless.
Well I would love to not use 1 second triggers. Unfortunately, I don't know of any other way to execute my triggers... You see I'm doing a King of the Hill Variant. And there are 8 "Hills" each updating a leaderboard every second (as to how many units are in the region every gametime second). Anyways, if you have a better Idea please let me know.
bad! never ever use timers! there is almost always a event for what you have a timer for, unless you are doing something small like counting game time. if you have 12 players in a game each exciting 8 triggers every 1 second you are going to hit you memory cap of 2.5mb quick. also if the trigger errors for any reason battle net turned it off if its a re-occurring trigger and your trigger will be useless.
The runtime execution of triggers will not add to the 2.5mb limit in any way. Unless you're making copying the trigger once for every player, so you'd basically have 96 triggers. In this case it's just horrible programming.
Peroidic execution however DOES add to the required memory on runtime (which is a different thing!). A little only, but still. It would be better to merge all 8 triggers into one and only execute this one.
I don't see any reason of having 8 peroidic triggers with the same interval running. Just update all 'hills' in the same trigger.
The runtime execution of triggers will not add to the 2.5mb limit in any way. Unless you're making copying the trigger once for every player, so you'd basically have 96 triggers. In this case it's just horrible programming.
Peroidic execution however DOES add to the required memory on runtime (which is a different thing!). A little only, but still. It would be better to merge all 8 triggers into one and only execute this one.
I don't see any reason of having 8 peroidic triggers with the same interval running. Just update all 'hills' in the same trigger.
Theoretically, isn't it possible that putting to much content into 1 single trigger could be worse than having 8 individual 1 second triggers, especially when there is SOOOOO much content per each trigger? After compiling all triggers into one I now have 1 trigger running every second that has 32 variables and 616 lines of code. Is this going to be worse or better? fi they are broken up then there are 4 variables a piece and 77 lines of code a piece but 8 triggers.
Executing one big bunch at once or several smaller bunches at once is the same.
Also, you should be able to re-use a lot of the local variables. If it really starts lagging (which would be possible, of course), then there's an easy way to get rid of it: Add a very small wait time (like 0.01) in the middle of the trigger. That cuts lag into half and thus gets rid of smaller lags completely.
I also think that you can shrink down the 600 lines of code down to like 200 with proper programming. I'm leaning myself out of the window here, but so large triggers usually indicate inefficient coding.
Is it a bad thing to have 8 different triggers running every 1 second of gametime?
@Etravex: Go
I shouldn't think so, simply because of how often it must happen in some maps. If there was a problem I'm sure they either found away around it or didn't have 8 triggers running at the same time.
@Etravex: Go
It depends on how much work each trigger is doing, but in general 8 triggers a second would not be a problem. Most triggers execute so fast that a human will not notice any delay caused by its execution.
bad! never ever use timers! there is almost always a event for what you have a timer for, unless you are doing something small like counting game time. if you have 12 players in a game each exciting 8 triggers every 1 second you are going to hit you memory cap of 2.5mb quick. also if the trigger errors for any reason battle net turned it off if its a re-occurring trigger and your trigger will be useless.
Not really, 1 second is a very high granularity.
The number of triggers running is less of a deal than the time granularity. A single trigger running every .1 seconds is going to be more performance intensive than 10 triggers running every 1 second.
Well I would love to not use 1 second triggers. Unfortunately, I don't know of any other way to execute my triggers... You see I'm doing a King of the Hill Variant. And there are 8 "Hills" each updating a leaderboard every second (as to how many units are in the region every gametime second). Anyways, if you have a better Idea please let me know.
@Etravex: Go
I wouldn't worry about the timers, but if you wanted to change it, you could have two triggers:
Trigger 1 would be "Unit enters or exits region - HILL" and use that to update the leaderboard
&&
Trigger 2 would be "Any unit dies"
Condition - Triggering Unit is in region - HILL
action - run update leaderboard
But you might very well get more hits from those triggers than from a 1 second periodic.
True... & true
If your updating a leaderboard why is it updating 8 times a second?
I update my leaderboard every second but its only 1 trigger...
The runtime execution of triggers will not add to the 2.5mb limit in any way. Unless you're making copying the trigger once for every player, so you'd basically have 96 triggers. In this case it's just horrible programming.
Peroidic execution however DOES add to the required memory on runtime (which is a different thing!). A little only, but still. It would be better to merge all 8 triggers into one and only execute this one.
I don't see any reason of having 8 peroidic triggers with the same interval running. Just update all 'hills' in the same trigger.
Theoretically, isn't it possible that putting to much content into 1 single trigger could be worse than having 8 individual 1 second triggers, especially when there is SOOOOO much content per each trigger? After compiling all triggers into one I now have 1 trigger running every second that has 32 variables and 616 lines of code. Is this going to be worse or better? fi they are broken up then there are 4 variables a piece and 77 lines of code a piece but 8 triggers.
Well tried to run it and it said my trigger was to big LOL. I broke it down into 2 triggers and it works fine now. Thank you for advice.
@Etravex: Go
Executing one big bunch at once or several smaller bunches at once is the same.
Also, you should be able to re-use a lot of the local variables. If it really starts lagging (which would be possible, of course), then there's an easy way to get rid of it: Add a very small wait time (like 0.01) in the middle of the trigger. That cuts lag into half and thus gets rid of smaller lags completely.
I also think that you can shrink down the 600 lines of code down to like 200 with proper programming. I'm leaning myself out of the window here, but so large triggers usually indicate inefficient coding.
Another GUI issue, I guess..