In the map i've been developing, there's turns out to be EXTREME lag in the later half of the game. However the only reason i found this out so late is because when i test the map in single player i get zero lag. This map is a wave based survival system with a shared income system. I'd also like to know if disabling the trigger will help optimize the game, as i want to be able to test optimizing the game without having to delete the triggers. I dont know how demanding multiple triggers with the same event can be so ill state what i think can be possible lag causing triggers:
- There are 9 triggers that activate when a unit dies, then conditions filter down to one specific unit. These are all for the shared income system, 8 of these triggers could be crunched down into 2 triggers though if that would help.
- There are 18 triggers that activate when any unit is selected, then conditions filter down to one specific unit. These can easily be removed as they are all just triggers that create a tip.
- My wave system uses triggers that spawn a group of units, wait, then spawn more. The reason for the wait is because as the waves get harder, new units
spawn, and these units spawn further back. So the wait timer is used to help synchronize all units getting to their target at the same time. Though i would not like to do this, i could fix this by simply spawning ONLY the new unit and buffing it. This would make the many wait timers unnecessary and potentially reduce lag.
- There are also 21 triggers with Chat Message events.
in general i would always have only one trigger with the same event and then filter with switch or if else constructs. i am pretty sure this will address the lag if there is none in single player.
i would just test the map with disabled triggers.
what's the name of your map?
what kind of complexity adds a player? (more units, more health?)
The name of the map is "Guardians Of The Obelisk".
The only complexity i think an additional player would add is that the triggers for controlling shared buildings will fire more often, and maybe the shared income system since it changes based on how many players are in-game.
I've disabled the 18 tip triggers and the 21 chat message triggers. The thing is that the game is actually very difficult and i rarely get far enough into the game to the point where it does lag. Due to the lack of feedback to the few people who play it i have no idea what goes on when im not playing the game. I'm still thinking its the wave triggers because the late-game wave triggers can take a few minutes to execute, and they run on periodic timers for every minute. I do have a way that im sure will fully optimize the waves, but it will really dampen the diversity in the game.
I've gotten some lag from triggers using "Effect Used" as the event. It usually takes a lot of persistent effects happening in order to create noticeable lag, though.
But I've found it more common to have problems with actors not disappearing. I've had a couple of projects that lagged late-game until I found which actors weren't being destroyed properly. If you're interested in going down that route, here's some advice:
I'd suggest playing a game into the late stages via Test Document, and then typing "actordumplive" into chat. This will give you a list of actors that are still currently alive, deposited into the "alerts" folder for SC2. It's kind of dull to sift through, but if you find large numbers of actors that shouldn't be there, that may be your problem.
I'd also recommend before you do that, that you create a version of your map with all the doodads deleted. That way the only actors that should show up are the ones related to units that are alive.
The problem I had in my map was in sound actors. Some of them were missing an event to destroy the sound once it was done playing, and over the course of the game they stacked up until the game couldn't handle it. I also had a problem with attachment actors, specifically when I tried to use Beam models.
There's just so many different actors in a game, especially if you make your own abilities and units. Actors for models, sounds, attachment points, visual effects, etc., and if any of them are missing an event to destroy them when they're no longer needed, they can build up to huge numbers over the course of a game. Until I found out that this could happen, most of my games couldn't be played past the 30 min mark over Bnet, but now they perform just fine!
I recommend using the "actordumplive" command just to know, 100%, if any actors at all are not being destroyed properly. You can check through all the actors' events in the Editor, but I always found actor events unintuitive, so I'd probably have a hard time spotting errors just by looking at them. But whatever works for you!
Well every single one of my actors was duplicated from a parent actor. I hate creating actors from scratch so i duplicate them all, the only actors i dont duplicate are Range and One Shot sounds, which have a "destroy when done" event in them by default. There is one thing im curious about, it seems some of my units dont have a Unit Death - Destroy events. They do have Unit Death - Death Customize. I think the customize death is for calling certain death animations such as fire or disintegrate.
I've determined that the actors are properly getting destroyed, when i removed all of the "Unit Death Customize" events in a unit's actor, the death animation turns into a weird puff which i assume is the null death animation. When i add a "Unit Death - Destroy" event, the death is also the null animation. This really bums me out because this would've been a easy problem to solve. I also doubt its the wait timers on the wave triggers because i played a round with two others, we killed the spawning buildings before the higher tier waves could come. Even if the units were dead the triggers would still run so i don't think the wave trigger is the problem either.
Something I've found is that printing a lot to the screen or to a bank file slows things down a LOT. So for instance if you have a debugging string printed to the screen every 5 seconds while you test something and leave it running for 10 minutes it will slow down the system more and more as time goes on. Same with a bank file which gets larger and larger.
What FunkyUserNarr said will help too. Instead of having 9 triggers that fire when a unit dies it might be better to have 1 trigger which does all 9 things.
The Any Unit dies is almost certainly causing part of the lag. It CAN be rectified, in that you can dynamically register units for use in events, but there is no (built in) GUI way to do this. I created Action versions of the native functions to do this, but it can get complicated, many issues and concern arise that you have to be careful of (using variables vs units for event registration, variable scope, etc.).
If you wish, I created a public Utility Library, that you can search/find on B.net (through the editor) that has some of the natives as actions. I have not documented how one would use them however, since I originally created them for my own use, and it requires an understanding of how they work and how GUI translates into actual script code.
The lag is rooted in the amount of units in the game. In few lobbies I've played in my team pushed out of our defensive area early, and managed to destroy some pawning structures as the newer waves came. In some games the lag was gone, while in other games where my team didn't push out at all the lag got too bad to play in near the end.
I crunched the triggers down and the game did run a bit better.
I am not using banks in my map.
I don't know anything about script or even the GUI.
how do your units find their way? pathfinding is a great part of the lag having many units. you could add a global unit group where every enemy is in. if it is above a certain value no more new units will spawn.
The units find their path immediately after they spawn, they are told to attack targeting a random point within a small region(the defending area). I'd rather reduce the number of units that spawn rather than limit their population, reason being that the waves are supposed to arrive every 60 seconds and if some waves suddenly were cut in half or simply didn't spawn it would alter the difficulty of the game or just make the game look broken.
if there are alot of units pathfinding might become complicated if there is a bottleneck a.k.a units stack somewhere. you might test and try the AI global suicide trigger in order to reduce complexity (it's impl. different).
The issue with suicide is that there are some units that i dont want to have running towards units, such as bosses that wait at the end. I can't make the bosses owned by another AI either because there are certain units that provide benefits to the boss and the wave units.
have 2 different players and set them to allied. then adjust your effects to allied, i see no problem. just test it once to see if the lag becomes better
Ill try finding a way to fix it, but that way wont work either because these ai's are in a team of 3, each of those 3 have bosses too. Allied would give the buff to all 3 ai's and that would lead to some major trouble. Ill probably just buff bosses a bit and move them to a different player slot.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
In the map i've been developing, there's turns out to be EXTREME lag in the later half of the game. However the only reason i found this out so late is because when i test the map in single player i get zero lag. This map is a wave based survival system with a shared income system. I'd also like to know if disabling the trigger will help optimize the game, as i want to be able to test optimizing the game without having to delete the triggers. I dont know how demanding multiple triggers with the same event can be so ill state what i think can be possible lag causing triggers:
- There are 9 triggers that activate when a unit dies, then conditions filter down to one specific unit. These are all for the shared income system, 8 of these triggers could be crunched down into 2 triggers though if that would help.
- There are 18 triggers that activate when any unit is selected, then conditions filter down to one specific unit. These can easily be removed as they are all just triggers that create a tip.
- My wave system uses triggers that spawn a group of units, wait, then spawn more. The reason for the wait is because as the waves get harder, new units spawn, and these units spawn further back. So the wait timer is used to help synchronize all units getting to their target at the same time. Though i would not like to do this, i could fix this by simply spawning ONLY the new unit and buffing it. This would make the many wait timers unnecessary and potentially reduce lag.
- There are also 21 triggers with Chat Message events.
in general i would always have only one trigger with the same event and then filter with switch or if else constructs. i am pretty sure this will address the lag if there is none in single player.
i would just test the map with disabled triggers.
what's the name of your map?
what kind of complexity adds a player? (more units, more health?)
The name of the map is "Guardians Of The Obelisk".
The only complexity i think an additional player would add is that the triggers for controlling shared buildings will fire more often, and maybe the shared income system since it changes based on how many players are in-game.
I've disabled the 18 tip triggers and the 21 chat message triggers. The thing is that the game is actually very difficult and i rarely get far enough into the game to the point where it does lag. Due to the lack of feedback to the few people who play it i have no idea what goes on when im not playing the game. I'm still thinking its the wave triggers because the late-game wave triggers can take a few minutes to execute, and they run on periodic timers for every minute. I do have a way that im sure will fully optimize the waves, but it will really dampen the diversity in the game.
repeat forever's generally cause me problems if I don't restrict them enough
check actor data as well
Hi Project_06,
I've gotten some lag from triggers using "Effect Used" as the event. It usually takes a lot of persistent effects happening in order to create noticeable lag, though.
But I've found it more common to have problems with actors not disappearing. I've had a couple of projects that lagged late-game until I found which actors weren't being destroyed properly. If you're interested in going down that route, here's some advice:
I'd suggest playing a game into the late stages via Test Document, and then typing "actordumplive" into chat. This will give you a list of actors that are still currently alive, deposited into the "alerts" folder for SC2. It's kind of dull to sift through, but if you find large numbers of actors that shouldn't be there, that may be your problem.
I'd also recommend before you do that, that you create a version of your map with all the doodads deleted. That way the only actors that should show up are the ones related to units that are alive.
Good luck!
How would actor not be destroyed properly? Seems like it would be easier to go through the actors of units and check for a missing event.
The problem I had in my map was in sound actors. Some of them were missing an event to destroy the sound once it was done playing, and over the course of the game they stacked up until the game couldn't handle it. I also had a problem with attachment actors, specifically when I tried to use Beam models.
There's just so many different actors in a game, especially if you make your own abilities and units. Actors for models, sounds, attachment points, visual effects, etc., and if any of them are missing an event to destroy them when they're no longer needed, they can build up to huge numbers over the course of a game. Until I found out that this could happen, most of my games couldn't be played past the 30 min mark over Bnet, but now they perform just fine!
I recommend using the "actordumplive" command just to know, 100%, if any actors at all are not being destroyed properly. You can check through all the actors' events in the Editor, but I always found actor events unintuitive, so I'd probably have a hard time spotting errors just by looking at them. But whatever works for you!
Well every single one of my actors was duplicated from a parent actor. I hate creating actors from scratch so i duplicate them all, the only actors i dont duplicate are Range and One Shot sounds, which have a "destroy when done" event in them by default. There is one thing im curious about, it seems some of my units dont have a Unit Death - Destroy events. They do have Unit Death - Death Customize. I think the customize death is for calling certain death animations such as fire or disintegrate.
I've determined that the actors are properly getting destroyed, when i removed all of the "Unit Death Customize" events in a unit's actor, the death animation turns into a weird puff which i assume is the null death animation. When i add a "Unit Death - Destroy" event, the death is also the null animation. This really bums me out because this would've been a easy problem to solve. I also doubt its the wait timers on the wave triggers because i played a round with two others, we killed the spawning buildings before the higher tier waves could come. Even if the units were dead the triggers would still run so i don't think the wave trigger is the problem either.
Something I've found is that printing a lot to the screen or to a bank file slows things down a LOT. So for instance if you have a debugging string printed to the screen every 5 seconds while you test something and leave it running for 10 minutes it will slow down the system more and more as time goes on. Same with a bank file which gets larger and larger.
What FunkyUserNarr said will help too. Instead of having 9 triggers that fire when a unit dies it might be better to have 1 trigger which does all 9 things.
omg it's spreading
-
View User Profile
-
View Posts
-
Send Message
Curse Premium@FunkyUserName: Go
(pats) There there FunkyUserNarr
The Any Unit dies is almost certainly causing part of the lag. It CAN be rectified, in that you can dynamically register units for use in events, but there is no (built in) GUI way to do this. I created Action versions of the native functions to do this, but it can get complicated, many issues and concern arise that you have to be careful of (using variables vs units for event registration, variable scope, etc.).
If you wish, I created a public Utility Library, that you can search/find on B.net (through the editor) that has some of the natives as actions. I have not documented how one would use them however, since I originally created them for my own use, and it requires an understanding of how they work and how GUI translates into actual script code.
The lag is rooted in the amount of units in the game. In few lobbies I've played in my team pushed out of our defensive area early, and managed to destroy some pawning structures as the newer waves came. In some games the lag was gone, while in other games where my team didn't push out at all the lag got too bad to play in near the end.
I crunched the triggers down and the game did run a bit better.
I am not using banks in my map.
I don't know anything about script or even the GUI.
how do your units find their way? pathfinding is a great part of the lag having many units. you could add a global unit group where every enemy is in. if it is above a certain value no more new units will spawn.
The units find their path immediately after they spawn, they are told to attack targeting a random point within a small region(the defending area). I'd rather reduce the number of units that spawn rather than limit their population, reason being that the waves are supposed to arrive every 60 seconds and if some waves suddenly were cut in half or simply didn't spawn it would alter the difficulty of the game or just make the game look broken.
if there are alot of units pathfinding might become complicated if there is a bottleneck a.k.a units stack somewhere. you might test and try the AI global suicide trigger in order to reduce complexity (it's impl. different).
The issue with suicide is that there are some units that i dont want to have running towards units, such as bosses that wait at the end. I can't make the bosses owned by another AI either because there are certain units that provide benefits to the boss and the wave units.
have 2 different players and set them to allied. then adjust your effects to allied, i see no problem. just test it once to see if the lag becomes better
Ill try finding a way to fix it, but that way wont work either because these ai's are in a team of 3, each of those 3 have bosses too. Allied would give the buff to all 3 ai's and that would lead to some major trouble. Ill probably just buff bosses a bit and move them to a different player slot.