Hey all! This is my first post on here; haven't really used sc2mapster much till now. Sorry if there is another more general thread or something for this, but I have a question that I really want answered. I'm quite proficient with custom map editing, and my experience stems back to the start of wc3 editor - however, I haven't actually published a map in SC2 yet. I've been working on one for quite a while now (it's changed drastically many times), but before I go much further on its current incarnation I'd like to find out if it's going to lag up a storm or not in multiplayer. Basically my I need advice from anyone who has experience designing a map that uses periodic triggers. My current map is an fps. I've managed to reduce, in theory, the amount of network traffic going on in-game to a minimum. At the moment, it only has one trigger that fires quite quickly and consistently (in this case, every 0.0625 seconds), and that trigger really only controls unit facing, and is therefor quite short. What I want to know from people with similar map concepts is whether this one trigger is liable to lag up the game in multiplayer, especially when combined with everything else going on. I really don't know how much lag a trigger that fires every game tick can create. I'm paranoid it simply won't work out, no matter how short the trigger is. Soo yeah, if anyone has had enough experience in this matter to answer my question, or has had similar issues, please get back to me!! I can provide more specific details of my map if needed. Feel free to pm me as well!
Yes, it can and probably will cause lag. Use a repeating loop instead. Every time the game calls an event, a little bit of lag is generated. Normally it isn't noticeable but when you have a periodic event firing so often, the lag builds up. If you call the trigger actions once and repeat them with a loop, this problem can be avoided.
I dont know who brought up the myth of lagging triggers in multiplayer or "bad" periodic triggers, but its most likely bogus.
You should be much more worried about terrain (Especially alot of doodads) or actors.
However, to get back to your original question, nobody can tell without knowing your exact code. In general, events that fire more often are for sure more dangerous than triggers that get run very rarely, however it depends on the code attached to this events if it causes lag or not. If you have optimized code it will most likely be alright.
As a hint: Try to optimize all code thats connected with events that fire alot, like periodic triggers < 0.5s interval or stuff like "Mouse moved". The more aggressive the event is the more careful you need to be with the attached code.
In general you should also try to design your code so that you avoid this kind of events, for example except for using "Unit life changes" you could use a periodic trigger, but then again it depends on the usecase.
In general you have to ask yourself questions like "Does the UI really need to refresh all 0.065 seconds?" and design your code around that.
In conclusion, i could talk hours about code design and optimizing, the point im trying to make is, keep performance in the back of your head when coding, however, dont focus to much on it and make sure you code stays readable and flexible.
In the end you will have to make tests in multiplayer, also try to use the trigger debug window to find performance problems and fix them. Make sure to optimize code in the right spots and dont overthink it.
Thanks guys for the responses. I admit I do fall victim to over-worrying about aesthetics in a finished product before I'm even there. BasharTeg, that's good advice. Given that I don't have very many actions running in that periodic trigger, it should really help later on if I change it to a one-shot event and just have the actions run in a periodic loop indefinitely. Thanks again!
The periodic trigger issues are not bogus as I've personally tested them myself. I believe the thought behind it is god forbid the actions in a periodic trigger take longer to execute then the difference in time from the event, then the computer has problem pushing something to go fastest than it can be done and thus forces the computer to slow done. As Basher has said do actions are the regularly looped is better do in like an action definition as a loop and a wait at the end so that everything finishes and then restart orderly instead of possibly skipping an important action because the computer lagged behind. Certain events too like key presses alone will cause lag or delay.
Terrain too can cause issue especially in an fps like maps with lots of water (easily solved) or skyboxes being used to help visuals from presenting everything unimportant.
Create a multiplayer map. Have several rapid periodic triggers with no actions. Lag ensues.
I just did that and tested with 3 people.
Zero lag with 60 (yep, 60!) 0.0625s real-time loops. 0 fps difference (280fps+), 0 unit control delay, 0 camera lag, 0 stutter.
No difference to 60 while loops with 0.0625s wait firing at 0 game time. Confirmed by 3 testers.
One thing that will cause pretty massive lag is if you have no wait times in your whiles. They will fire in a single loop causing massive lag then break. I'm hoping this isn't your issue.
Hey all! This is my first post on here; haven't really used sc2mapster much till now. Sorry if there is another more general thread or something for this, but I have a question that I really want answered. I'm quite proficient with custom map editing, and my experience stems back to the start of wc3 editor - however, I haven't actually published a map in SC2 yet. I've been working on one for quite a while now (it's changed drastically many times), but before I go much further on its current incarnation I'd like to find out if it's going to lag up a storm or not in multiplayer. Basically my I need advice from anyone who has experience designing a map that uses periodic triggers. My current map is an fps. I've managed to reduce, in theory, the amount of network traffic going on in-game to a minimum. At the moment, it only has one trigger that fires quite quickly and consistently (in this case, every 0.0625 seconds), and that trigger really only controls unit facing, and is therefor quite short. What I want to know from people with similar map concepts is whether this one trigger is liable to lag up the game in multiplayer, especially when combined with everything else going on. I really don't know how much lag a trigger that fires every game tick can create. I'm paranoid it simply won't work out, no matter how short the trigger is. Soo yeah, if anyone has had enough experience in this matter to answer my question, or has had similar issues, please get back to me!! I can provide more specific details of my map if needed. Feel free to pm me as well!
Yes, it can and probably will cause lag. Use a repeating loop instead. Every time the game calls an event, a little bit of lag is generated. Normally it isn't noticeable but when you have a periodic event firing so often, the lag builds up. If you call the trigger actions once and repeat them with a loop, this problem can be avoided.
I dont know who brought up the myth of lagging triggers in multiplayer or "bad" periodic triggers, but its most likely bogus.
You should be much more worried about terrain (Especially alot of doodads) or actors.
However, to get back to your original question, nobody can tell without knowing your exact code. In general, events that fire more often are for sure more dangerous than triggers that get run very rarely, however it depends on the code attached to this events if it causes lag or not. If you have optimized code it will most likely be alright. As a hint: Try to optimize all code thats connected with events that fire alot, like periodic triggers < 0.5s interval or stuff like "Mouse moved". The more aggressive the event is the more careful you need to be with the attached code.
In general you should also try to design your code so that you avoid this kind of events, for example except for using "Unit life changes" you could use a periodic trigger, but then again it depends on the usecase.
In general you have to ask yourself questions like "Does the UI really need to refresh all 0.065 seconds?" and design your code around that.
In conclusion, i could talk hours about code design and optimizing, the point im trying to make is, keep performance in the back of your head when coding, however, dont focus to much on it and make sure you code stays readable and flexible. In the end you will have to make tests in multiplayer, also try to use the trigger debug window to find performance problems and fix them. Make sure to optimize code in the right spots and dont overthink it.
Thanks guys for the responses. I admit I do fall victim to over-worrying about aesthetics in a finished product before I'm even there. BasharTeg, that's good advice. Given that I don't have very many actions running in that periodic trigger, it should really help later on if I change it to a one-shot event and just have the actions run in a periodic loop indefinitely. Thanks again!
The periodic trigger issues are not bogus as I've personally tested them myself. I believe the thought behind it is god forbid the actions in a periodic trigger take longer to execute then the difference in time from the event, then the computer has problem pushing something to go fastest than it can be done and thus forces the computer to slow done. As Basher has said do actions are the regularly looped is better do in like an action definition as a loop and a wait at the end so that everything finishes and then restart orderly instead of possibly skipping an important action because the computer lagged behind. Certain events too like key presses alone will cause lag or delay.
Terrain too can cause issue especially in an fps like maps with lots of water (easily solved) or skyboxes being used to help visuals from presenting everything unimportant.
@hobbidude: Go
So, how did you "test" this? I would really like to see your testing methods.
@Mille25: Go
Create a multiplayer map. Have several rapid periodic triggers with no actions. Lag ensues.
I just did that and tested with 3 people.
Zero lag with 60 (yep, 60!) 0.0625s real-time loops. 0 fps difference (280fps+), 0 unit control delay, 0 camera lag, 0 stutter. No difference to 60 while loops with 0.0625s wait firing at 0 game time. Confirmed by 3 testers.
Still waiting for evidence. :D
Verified ^
One thing that will cause pretty massive lag is if you have no wait times in your whiles. They will fire in a single loop causing massive lag then break. I'm hoping this isn't your issue.
Hmm any one play war of helms deep, at the beginning there is always lag. Cased closed. Trigger related lag.