In my map Shape Wars, I have heard a lot of complaints on unexplained framerate drops. I looked into how to learn to debug the map better, and stumbled upon the Trigger Debugger in the galaxy editor. To get there, go to:
File
Preferences...
Test Document
Check 'Run Game In A Window'
Check 'Show Trigger Debugging Window'
Now when you test your map, you will see every trigger that is called. Using this tool, I discovered I wasn't properly setting up my events, and within 30 minutes, had reduced my average trigger run during gameplay to 2% of what it was prior. This drastically improved performance, and should be a frequently used tool for any map maker.
EDIT: Well, the debugger led me astray and gave me some false information regarding gameplay performance increases, when dealing with long triggers with multiple if/then/else's that happen to share the same event vs seperate triggers with different conditions. The more threads you have created, the slower the debugger works. That's why I assumed the performance was increasing, but really it was the performance of the trigger debug mode only.
Final result:
Gameplay difference between long trigger with if/elses vs seperate triggers with conditions: None
HOWEVER, if you do the long trigger method, you may experience EXTREME framerate lag when you are using the trigger debugger, since it has to write reports on so many threads. Since there is no difference in gameplay performance, I still feel that seperately conditioned triggers is the better method, for those of us that don't write in script.
I hope this information helps others as much as it helped me, and I hope my information is accurate. The trigger debugger, and my total FPS in-game seem to think so.
When a trigger is called, a thread is being created. For small triggers the thread creation costs more than the execution itself.
Quote:
This part is wrong!
From what Zanam experienced, it looks like the conditions are being run before the thread creation. So if you have an even that runs very often (unit takes damage for example) but you want to take actions only for a small number of cases (a particular unit for example), you want to add that into the condition part and not using an if then else inside the trigger!
For novices like myself, here was the major issue that I never knew. I had assumed that the Condition of an Event was essentially a built in If-Then-Else statement, no different than any other. How wrong I was. Let's say you have a trigger that fires on a unit dying, and you have five different sets of actions you want to do depending on the type of unit. If you have no condition set up for that event, that event fires every time ANY unit dies, as you might expect. If you DO have a condition, and five seperate triggers (one for each unit type), only the proper trigger will fire, reducing your trigger run count by about 80% from your non-conditioned trigger, and thats assuming you only have five different unit types. Imagine how much efficiency you will have gained if you had 30!
Wouldn't it be better to just add an OR-condition including all the unit types used in that trigger? So you would still be able to do everything in one trigger, because redundant triggers are very bad style. Internally it would have to check the conditions anyway, so i am not sure about a serious performance gain, but if you want to be sure, I would recommend doing it this way:
For novices like myself, here was the major issue that I never knew. I had assumed that the Condition of an Event was essentially a built in If-Then-Else statement, no different than any other. How wrong I was. Let's say you have a trigger that fires on a unit dying, and you have five different sets of actions you want to do depending on the type of unit. If you have no condition set up for that event, that event fires every time ANY unit dies, as you might expect. If you DO have a condition, and five seperate triggers (one for each unit type), only the proper trigger will fire, reducing your trigger run count by about 80% from your non-conditioned trigger, and thats assuming you only have five different unit types. Imagine how much efficiency you will have gained if you had 30!
Instead of 5 events in different triggers you could also make one event that handles all the units dying and use switch's and conditions in the trigger to handle them all. Ive found having less events with the same event helps quite a bit as well.
Rollback Post to RevisionRollBack
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
If you have no condition set up for that event, that event fires every time ANY unit dies, as you might expect. If you DO have a condition, and five seperate triggers (one for each unit type), only the proper trigger will fire, reducing your trigger run count by about 80% from your non-conditioned trigger, and thats assuming you only have five different unit types. Imagine how much efficiency you will have gained if you had 30!
From what Zanam experienced, it looks like the conditions are being run before the thread creation. So if you have an even that runs very often (unit takes damage for example) but you want to take actions only for a small number of cases (a particular unit for example), you want to add that into the condition part and not using an if then else inside the trigger!
This is not true. A trigger will ALWAYS fire when it's event is true, no matter it's conditions.
The trigger debugger visciously mislead you there.
boolgt_Unit_dies_Func(booltestConds,boolrunActions){if(testConds){if(UnitGetType(EventUnit())!="Marine"){returnfalse;}}// Actionsif(!runActions){returntrue;}//Here come your actionsreturntrue;}
This is a simple death trigger how it looks in galaxy.
The event would be a normal Unit dies event, the condition is that the dying unit is a Marine.
What happens here is that a trigger always returns a value, either true or false.
If the trigger finished execution it returns true (see last line). If it's condition is not met then it'll return false.
The trigger debugger, however, only counts triggers that return true as executed. So if a trigger returns false it'll completely disregard this.
If you insert another condition somewhere in the actions with a "Skip remaining actions" order, then this'll place a "return true" in the script, so it'll get counted.
So in short: Triggers which conditions are not met do get executed (and properly threaded), but just not counted.
A switch action is only a normal If-Then-Else construct behind the courtains, so it's not the fastest thing in the universe.
But if you have a dozen death triggers with a set of different conditions each it can indeed be more useful to keep it all in one trigger.
PS: VJEUX YOU NEWSED IT ALREADY. OH MY GOSH I CAN'T STAND THE PAIN.
A switch action is only a normal If-Then-Else construct behind the courtains, so it's not the fastest thing in the universe.
But if you have a dozen death triggers with a set of different conditions each it can indeed be more useful to keep it all in one trigger.
I like to set up a catch all event that just handles the different units and from there I launch threaded functions/ actions to do the stuff I actually want done based on the unit that had died. This keeps the Event Trigger simple, smaller memory footprint, more logical. (as well as in the trigger conditions I may add things to prevent it from checking units owned by nutral players or units in a specific region. Or to make sure im not running this when missiles die and what not. That helps make it even more efficiant.
Actually Events that Fail thier conditions get added to the Failed Count for that trigger.
Not likely, ey? This tutorial helps to increase framerate and performance, not reduce latency which is the issue with FPSs.
Gah, I was being too hopeful.
I always thought the event created the thread and avoided using too generic events. Well I am no expert anyway, but it's certainly good to know.
I did notice that the events get added to the fail count in the debugger, but the reason I assumed it increased performance was the thread was never created, and appeared to increase the framerate. However upon further investigation, this is just due to the debugger window itself being open, the more threads it needs to do a small report on, the lower the in-game performance.
Final result:
Gameplay difference between long trigger with if/elses vs seperate triggers with conditions: None
HOWEVER, if you do the long trigger method, you may experience EXTREME framerate lag when you are using the trigger debugger, since it has to write reports on so many threads.
About framerate drops I suggest to not use periodic timers events with low delays.
On my computer it causes a decreasing framerate that goes from 45fps to 4fps after something like 30 seconds.
The problem is solved when I replace the periodic timer with a while loop or a recursive function call.
I think that may cayse framerate problems on other computers too but noone has noticed it, thinking that the problem was caused by the fps camera and not by the periodic timers.
I attached the map I used for tests, download it and try to activate one trigger at once and see if you get framerate decrease (ctrl + alt + F to show FPS)
OMP. I have to thank you a ton load Zanam00. Never had to clue about the debugger until i saw it on the front page. I decided to give it a try and found about 4 sloppy triggers that were runaway trigger hundreds of times for stupid reasons. ^.^
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
In my map Shape Wars, I have heard a lot of complaints on unexplained framerate drops. I looked into how to learn to debug the map better, and stumbled upon the Trigger Debugger in the galaxy editor. To get there, go to:
Now when you test your map, you will see every trigger that is called. Using this tool, I discovered I wasn't properly setting up my events, and within 30 minutes, had reduced my average trigger run during gameplay to 2% of what it was prior. This drastically improved performance, and should be a frequently used tool for any map maker.
EDIT: Well, the debugger led me astray and gave me some false information regarding gameplay performance increases, when dealing with long triggers with multiple if/then/else's that happen to share the same event vs seperate triggers with different conditions. The more threads you have created, the slower the debugger works. That's why I assumed the performance was increasing, but really it was the performance of the trigger debug mode only.
Final result: Gameplay difference between long trigger with if/elses vs seperate triggers with conditions: None
HOWEVER, if you do the long trigger method, you may experience EXTREME framerate lag when you are using the trigger debugger, since it has to write reports on so many threads. Since there is no difference in gameplay performance, I still feel that seperately conditioned triggers is the better method, for those of us that don't write in script.
I hope this information helps others as much as it helped me, and I hope my information is accurate. The trigger debugger, and my total FPS in-game seem to think so.
When a trigger is called, a thread is being created. For small triggers the thread creation costs more than the execution itself.
Not likely, ey? This tutorial helps to increase framerate and performance, not reduce latency which is the issue with FPSs.
Good tutorial though! I've been using the trigger debugger since the beginning myself, it's very informative.
Wouldn't it be better to just add an OR-condition including all the unit types used in that trigger? So you would still be able to do everything in one trigger, because redundant triggers are very bad style. Internally it would have to check the conditions anyway, so i am not sure about a serious performance gain, but if you want to be sure, I would recommend doing it this way:
Instead of 5 events in different triggers you could also make one event that handles all the units dying and use switch's and conditions in the trigger to handle them all. Ive found having less events with the same event helps quite a bit as well.
This is not true. A trigger will ALWAYS fire when it's event is true, no matter it's conditions.
The trigger debugger visciously mislead you there.
This is a simple death trigger how it looks in galaxy.
The event would be a normal Unit dies event, the condition is that the dying unit is a Marine.
What happens here is that a trigger always returns a value, either true or false.
If the trigger finished execution it returns true (see last line). If it's condition is not met then it'll return false.
The trigger debugger, however, only counts triggers that return true as executed. So if a trigger returns false it'll completely disregard this.
If you insert another condition somewhere in the actions with a "Skip remaining actions" order, then this'll place a "return true" in the script, so it'll get counted.
So in short:
Triggers which conditions are not met do get executed (and properly threaded), but just not counted.
@SouLCarveRR: Go
A switch action is only a normal If-Then-Else construct behind the courtains, so it's not the fastest thing in the universe.
But if you have a dozen death triggers with a set of different conditions each it can indeed be more useful to keep it all in one trigger.
PS: VJEUX YOU NEWSED IT ALREADY. OH MY GOSH I CAN'T STAND THE PAIN.
I like to set up a catch all event that just handles the different units and from there I launch threaded functions/ actions to do the stuff I actually want done based on the unit that had died. This keeps the Event Trigger simple, smaller memory footprint, more logical. (as well as in the trigger conditions I may add things to prevent it from checking units owned by nutral players or units in a specific region. Or to make sure im not running this when missiles die and what not. That helps make it even more efficiant.
Actually Events that Fail thier conditions get added to the Failed Count for that trigger.
I did notice that the events get added to the fail count in the debugger, but the reason I assumed it increased performance was the thread was never created, and appeared to increase the framerate. However upon further investigation, this is just due to the debugger window itself being open, the more threads it needs to do a small report on, the lower the in-game performance.
Final result: Gameplay difference between long trigger with if/elses vs seperate triggers with conditions: None HOWEVER, if you do the long trigger method, you may experience EXTREME framerate lag when you are using the trigger debugger, since it has to write reports on so many threads.
Thanks for the replies, and clarification.
About framerate drops I suggest to not use periodic timers events with low delays.
On my computer it causes a decreasing framerate that goes from 45fps to 4fps after something like 30 seconds.
The problem is solved when I replace the periodic timer with a while loop or a recursive function call.
I think that may cayse framerate problems on other computers too but noone has noticed it, thinking that the problem was caused by the fps camera and not by the periodic timers.
I attached the map I used for tests, download it and try to activate one trigger at once and see if you get framerate decrease (ctrl + alt + F to show FPS)
Edit:
I opened a new thread about this problem:
http://forums.sc2mapster.com/development/map-development/11809-timer-periodic-event-lagging-on-some-computers/
OMP. I have to thank you a ton load Zanam00. Never had to clue about the debugger until i saw it on the front page. I decided to give it a try and found about 4 sloppy triggers that were runaway trigger hundreds of times for stupid reasons. ^.^