I have a trigger heavy map. My question is, if I add conditions to an existing trigger that would restrict it's use at a certain point, would it increase performance?
Put simply: if a trigger fires when a hero dies, would adding condition herolvl is < 10, cause my map to perform better after the hero is lvl 10?
Do you only want this trigger to fire while the hero is under level 10? If that's the case and you're also looking to save CPU then in what ever function that manages your leveling have an action to turn off this trigger when the 10th level is reached. That way the event handler won't even poll unit deaths vs trigger events after that point (at least for this trigger).
Ed: I also wanted to mention something though that even without knowing how many triggers you have going on I imagine the CPU time devoted to testing triggers each time a unit dies is probably very small compared to many other aspects of maps and displaying 3d graphics...I don't think you'd notice a difference unless you have literally thousands of units dying per second as a standard feature of the map.
Actually I have no heroes in my map, that was just a crude example of what I was asking. But I think you answered my question so I just want clarification;
if Make a trigger to set obselete triggers to 'off', then the event handler won't process them? Clearing up memory and increasing performance?
This is especially useful for player specific triggers if say, player 3 didn't exist. So a map initialization trigger would be helpful to say if player3 inactive turn play3init off.
Absolutely, the less events and things listening for events the better for sure. But really I don't have a solid idea of how much CPU time is eaten by triggers and map related scripting vs what it takes to run the starcraft 2 engine and all the animations etc that go with it. From my limited experience programing games several years ago the activities involved with displaying a game's graphics usually outweighed the game play logic/AI engine by a long shot. There are extremes though of course, I suppose a trigger that fires every .001 second that does a 'pick all units in group (entire map)' and then a few other nested loops for each of those would probably put a big dent in CPU time too.
But yah, minimizing how many triggers are listening at any given time is a good start for sure.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I have a trigger heavy map. My question is, if I add conditions to an existing trigger that would restrict it's use at a certain point, would it increase performance?
Put simply: if a trigger fires when a hero dies, would adding condition herolvl is < 10, cause my map to perform better after the hero is lvl 10?
Do you only want this trigger to fire while the hero is under level 10? If that's the case and you're also looking to save CPU then in what ever function that manages your leveling have an action to turn off this trigger when the 10th level is reached. That way the event handler won't even poll unit deaths vs trigger events after that point (at least for this trigger).
Ed: I also wanted to mention something though that even without knowing how many triggers you have going on I imagine the CPU time devoted to testing triggers each time a unit dies is probably very small compared to many other aspects of maps and displaying 3d graphics...I don't think you'd notice a difference unless you have literally thousands of units dying per second as a standard feature of the map.
@BumpInTheNight: Go
Actually I have no heroes in my map, that was just a crude example of what I was asking. But I think you answered my question so I just want clarification;
if Make a trigger to set obselete triggers to 'off', then the event handler won't process them? Clearing up memory and increasing performance? This is especially useful for player specific triggers if say, player 3 didn't exist. So a map initialization trigger would be helpful to say if player3 inactive turn play3init off.
Absolutely, the less events and things listening for events the better for sure. But really I don't have a solid idea of how much CPU time is eaten by triggers and map related scripting vs what it takes to run the starcraft 2 engine and all the animations etc that go with it. From my limited experience programing games several years ago the activities involved with displaying a game's graphics usually outweighed the game play logic/AI engine by a long shot. There are extremes though of course, I suppose a trigger that fires every .001 second that does a 'pick all units in group (entire map)' and then a few other nested loops for each of those would probably put a big dent in CPU time too.
But yah, minimizing how many triggers are listening at any given time is a good start for sure.