If there is no event, dont use a trigger, use an action...
What is the reason behind this? Are triggers somehow inherently less efficient than making your own action? Or is it just better organization?
each trigger creates a variable and a function just for being a trigger (in galaxy), so it takes away space, but more important than that is the better organization, having only triggers with events shows you right away where to go in your code and what will run (assumming it's bigger than 1 week work)
In general events should be used as less as possible to maintain clear code and good performance.
I don't get this - aren't events necessary to make your trigger run? How do you eliminate them? What are some common examples of excessive/redundant event usage?
2 things here, group your events, meaninig instead of using X triggers with unit dies event, use one trigger with that event and use a Switch or If THen Else to check every case. 2nd thing is, think about it first, do you really NEED an event and do you really NEED this one, or isnt there a more specific event that you could use.
One thing i see again and again is the use of the MapInit event more than once. There should be only ONE entry point to your map.
Why is this? The only reason I ever do it is if I need something with a wait in it to run at the start of the map (so I want other things to be not waiting on the wait) but I'm not sure why its better to have it under a time elapsed 0.001 rather than multiple MapInit. Maybe its because I don't really get what MapInit is doing, I always just think of it as the same thing as time elapsed 0.001 except without that tiny bit of delay. Quote:
Do ONE trigger with MapInit, then call actions in this trigger which must be executed on map start, add a wait and call the actions that must be called later. if you ever leave the map and come back half a year later, you wont have to check/find all triggers with mapInit event to see whats going on on mapstart
Avoid the use of periodic events, they cost too much performance, instead call an custom action (instead of turning your former trigger on) :
I REALLY don't understand this one. Why do periodic events cause more lag than doing it this way? Plus I don't get how your workarounds work; the While loop will stop at one failure to meet conditions but for many periodic event triggers you want them to continue to keep going even if they do fail a condition check once. Quote:
periodic events really behave with low performance, a while loop is way more effient. the conditions for the while loop are ther ones that would have turned off your former periodic trigger and you call the loop action when turninig your former trigger on. it's not a replacement for the content of the trigger (which might contain conditions that are allowed to fail)
Instead of ANY X (i.e. any unit being killed) you should use dynamic Event adding with one specific unit; anyway there is another "trick": use a variable in the event, but be carefully with i.e "no unit"
Lost me again, not sure how to do Dynamic Events (Do you mean using custom script to add events?) but also I'm not sure what you mean by the other "trick" you can use. Also, I'm presuming this is only applicable if you are using "any x" when you actually want it to be a specific unit, just one not on the map yet. Because I don't see how its any better to add hundreds of events to one trigger dynamically, especially when you said to avoid using events earlier.
yes, i mean that. the other trick is to use instead of any unit a unit variable and set it during the game. this allows dynamic event units too and doesnt require custom script.
Take care what conditions you are using. There are several which costs alot of performance (pathing costs between 2 points, etc).
Wondering if you could be more specific and say what other conditions cost a lot of performance besides pathing costs between 2 points?
anything that has to calculate something, or go through a list of things. having lots of units on the map, you might think about unit groups. use a local variable to calculate the unit group once, instead of calling the action (unit group in region with cond i.e.) again and again.
DialogUsed Event needs special treatment. if you dont disable the button at the start of execution you can queue the button pressed event resulting in more than one executions.
One exception is the mouse moved event. It should be used only in combination with a certain player (not any player). Have a look in my signature and check the map "banshee fight" if you want to know more.
Key pressed event shouldn't be used at all (not even on a per player basis) because it will lag in multiplayer games.
Instead of ANY X (i.e. any unit being killed) you should use dynamic Event adding with one specific unit; anyway there is another "trick": use a variable in the event, but be carefully with i.e "no unit".
Conditions:
Take care what conditions you are using. There are several which costs alot of performance (pathing costs between 2 points, etc).
Having the same conditions again and again, you should consider making a custom function which checks the conditions and returns a boolean.
Actions & Functions:
functions should be used to calculate things and return the result. for example i am using functions to return the index of an array which is basically "search within a list".
functions always have to return something (and galaxy checks if every branch of your code will do so), do that at the very end of that function with a variable you have set during the functions execution.
When you combine functions with generic events (this is typically for libraries that you'll distribute to others) you can use them to return (typically from a variable) info about the triggering items and causes.
Never use Pick Each Integer / Pick whatever inside a function or action
Variables:
Use constants for constant values (capt obvious), i.e Number of max players
Use records whenever you have to group variables, for example:
instead of using a variable heroes[player], use a record
players[player].hero, you will most likely group more variables for the players.
put your variables (in the folder) where they are used, if used at several places, put them where they are initialized
custom values on units : alway make a index list of the custom values and what they mean (i.e. 1 = Status, 2 = reached target, 3 = X-coordinate , etc)
Dialogs:
Only create dialogs on a per player basis unless you need to resize the whole dialog (not the dialog item), because that's not possible on a per player basis.
Create a custom action/function to create dialog items like pulldown. etc (you always have to set height,width, anchor)
Special stuff:
Global attack is implement best with triggers, there is no data solution that performs well. In my map TRD, i need all zombies to attack the heroes from any place of the map. In wc3 it was possible to set aquisition range to 500 and just give full vision to enemy to achieve that. Doing that in sc2 will not perform well. Also all other options i have tried didnt perform well, only a periodic action that checks direct distance is able to perform okish. (check trd map in my signature)
each trigger creates a variable and a function just for being a trigger (in galaxy), so it takes away space, but more important than that is the better organization, having only triggers with events shows you right away where to go in your code and what will run (assumming it's bigger than 1 week work)
2 things here, group your events, meaninig instead of using X triggers with unit dies event, use one trigger with that event and use a Switch or If THen Else to check every case. 2nd thing is, think about it first, do you really NEED an event and do you really NEED this one, or isnt there a more specific event that you could use.
Do ONE trigger with MapInit, then call actions in this trigger which must be executed on map start, add a wait and call the actions that must be called later. if you ever leave the map and come back half a year later, you wont have to check/find all triggers with mapInit event to see whats going on on mapstart
periodic events really behave with low performance, a while loop is way more effient. the conditions for the while loop are ther ones that would have turned off your former periodic trigger and you call the loop action when turninig your former trigger on. it's not a replacement for the content of the trigger (which might contain conditions that are allowed to fail)
yes, i mean that. the other trick is to use instead of any unit a unit variable and set it during the game. this allows dynamic event units too and doesnt require custom script.
anything that has to calculate something, or go through a list of things. having lots of units on the map, you might think about unit groups. use a local variable to calculate the unit group once, instead of calling the action (unit group in region with cond i.e.) again and again.
Here another list by Funky. List will be updated. The following is a personal opinion:
General:
Events:
Conditions:
Actions & Functions:
Variables:
instead of using a variable heroes[player], use a record
players[player].hero, you will most likely group more variables for the players.
Dialogs:
Special stuff: