Right now, I seem to be having some lag issues when certain triggers fire, especially for the first time, and also when many fire at once. I'm just wondering the best way to reduce that lag.
For example, say there are two game modes A and B, would it be better to have 2 triggers, one for A, one for B, and when turn one of them off during the game depending on the game mode, or is it better to have one trigger with a if/then/else of "Game mode A == True", and put both in the one trigger?
Also, I'm using a trigger like this to spawn a random unit:
Variable - Set Random Integer = (Random integer between 1 and 59)
General - Switch (Actions) depending on Current Sprint[p]
Cases
General - If (1)
Actions
Unit - Create 1 Unit Bank[Random Integer] for player p at Spawn 1 using default facing (No Options)
Etc, Etc, Etc
Would the size of Unit Bank [*] (The pool of random units, at the moment 59) be affecting it too?
Everything affects the speed of triggers. Recoding them more efficiently is a great way to reduce lag. Also note that it may be your computer that is causing the lag, and not the actual game.
I dare say recoding your triggers has little to no effect on gameplay lag. What has a huge effect are what conditions and events your triggers use.
Avoid "Unit takes damage" or any other trigger that will fire a lot. 240 triggers within a second (easily doable if you have a few of these "Unit takes damage" events) will quickly clog up the game and even cause some triggers to become unresponsive until the congestion is gone.
Roll up triggers that use similar events into one trigger. For example, if you have a trigger event that fires when a unit dies, where the condition is that the unit's type is x, then a separate trigger that also fires when a unit dies, of type y, combine these. I honestly don't care what any code savvy person says, this is the defacto best way to code in the GUI. Single, huge triggers with plenty of "if then else" statements (don't put if then else statements inside other if then else statements though). I've had my map go from unplayable to lag free by rolling my triggers up into long monsters rather than neat little ones.
Lasty, and I touched on this earlier, just avoid at all costs events that fire a lot. "Unit dies", "Unit takes damage", "Mouse click", "Keyboard event", "Unit uses ability (where the fields are set to any)", anything that is going to proc more than once per second. When you have 10 players and a few triggers that proc more than once per second, it's very, very easy for your triggers to just stall during combat or intense events.
Solutions include the data editor and dummy events. I mentioned this in your other thread, but if you want to know when a specific unit dies, give it a behaviour that fires a dummy effect off under Damage Responce under Fatal -> Handled, then make a trigger that has the event corresponding to your dummy event. There, instead of a trigger that fires every time a unit dies while you try to find the correct unit, you have a system that will only fire when the unit you want dies. There's always an alternative, be creative.
Quote from Eiviyn:
Solutions include the data editor and dummy events. I mentioned this in your other thread, but if you want to know when a specific unit dies, give it a behaviour that fires a dummy effect off under Damage Responce under Fatal -> Handled, then make a trigger that has the event corresponding to your dummy event. There, instead of a trigger that fires every time a unit dies while you try to find the correct unit, you have a system that will only fire when the unit you want dies.
That's a good idea, I'd never considered that. Nice!
I'm still getting my head around the data editor, which is why I've stuck with triggers at the moment. I just flicked through the create effects area, and was wondering if the Event Type mattered for a dummy event? Can it just be anything?
Also, thanks a lot for all the help Eiviyn! Your advice is much appreciated =)
Placing conditions in your triggers to narrow it to a certain point, instead of If-then statements will greatly reduce lag instead of Unit Takes damage with no condition putting to check if unit is hero will reduce lag a lot.
Solutions include the data editor and dummy events. I mentioned this in your other thread, but if you want to know when a specific unit dies, give it a behaviour that fires a dummy effect off under Damage Responce under Fatal -> Handled, then make a trigger that has the event corresponding to your dummy event. There, instead of a trigger that fires every time a unit dies while you try to find the correct unit, you have a system that will only fire when the unit you want dies. There's always an alternative, be creative.
Does damage response only trigger when the unit takes fatale damage? Because I have a trigger that kills a unit, and that doesn't seem to cause the effect to trigger. If so, is there a way around this?
Also, I'm having difficulty with it at the moment, where in some instances it will trigger twice for some reason, while at other times it won't trigger at all, especially if a lot of the units are dying at once (eg: to a nuke)
Placing conditions in your triggers to narrow it to a certain point, instead of If-then statements will greatly reduce lag instead of Unit Takes damage with no condition putting to check if unit is hero will reduce lag a lot.
Not at all. Internally a condition is nothing more than a normal if-then-statement.
And events, no matter which, shouldn't really bother you much unless you have like 20x a highly generic event (like Any Unit Takes Damage) and a million units on your map.
If your triggers lag it's usually one out of two reasons:
There are special effects (or new doodads/units) being spawned which make it lag (this lag is especially high when you run the trigger for the first time, so it fits your description).
Your triggers are very very long, might contain long loops or any other cpu intensive processes (maybe picking each unit on the map and running half a dozen conditions / actions on it).
Also, narrowing down events can help. I know i had triggers "Any unit acquires target", "Any unit is attacked", "Any unit dies" and "Any unit is issued an attack order".
Instead of "Any unit" i put in variables with the appropriate unit, and just added one event for each unit into the trigger. "Hero[1] dies, Hero[2] dies..." or "(Phase Assasin) is issued an attack order", "Beacon[1] is attacked" etc. That way i narrowed it down to 8 units per trigger, and not the up to 200 which are on the map at the same time.
If you can specify the event using a variable, you probably wont even need conditions and have it fire a lot less.
Also, one thing i was wondering as well about trigger lag... What's better, using a custom action or "Run trigger", and if i have multiple triggers doing basically the same thing but with different parameters (but which i cant merge), would making a custom action increase performance?
I'm also thinking of making an RPG, so i'll probably have way more questions and open up my own thread for those... (again, mostly performance based or what is a better way to do this and that...)
Right now, I seem to be having some lag issues when certain triggers fire, especially for the first time, and also when many fire at once. I'm just wondering the best way to reduce that lag.
For example, say there are two game modes A and B, would it be better to have 2 triggers, one for A, one for B, and when turn one of them off during the game depending on the game mode, or is it better to have one trigger with a if/then/else of "Game mode A == True", and put both in the one trigger?
Also, I'm using a trigger like this to spawn a random unit:
Variable - Set Random Integer = (Random integer between 1 and 59) General - Switch (Actions) depending on Current Sprint[p] Cases General - If (1) Actions Unit - Create 1 Unit Bank[Random Integer] for player p at Spawn 1 using default facing (No Options) Etc, Etc, Etc
Would the size of Unit Bank [*] (The pool of random units, at the moment 59) be affecting it too?
Everything affects the speed of triggers. Recoding them more efficiently is a great way to reduce lag. Also note that it may be your computer that is causing the lag, and not the actual game.
I dare say recoding your triggers has little to no effect on gameplay lag. What has a huge effect are what conditions and events your triggers use.
Avoid "Unit takes damage" or any other trigger that will fire a lot. 240 triggers within a second (easily doable if you have a few of these "Unit takes damage" events) will quickly clog up the game and even cause some triggers to become unresponsive until the congestion is gone.
Roll up triggers that use similar events into one trigger. For example, if you have a trigger event that fires when a unit dies, where the condition is that the unit's type is x, then a separate trigger that also fires when a unit dies, of type y, combine these. I honestly don't care what any code savvy person says, this is the defacto best way to code in the GUI. Single, huge triggers with plenty of "if then else" statements (don't put if then else statements inside other if then else statements though). I've had my map go from unplayable to lag free by rolling my triggers up into long monsters rather than neat little ones.
Lasty, and I touched on this earlier, just avoid at all costs events that fire a lot. "Unit dies", "Unit takes damage", "Mouse click", "Keyboard event", "Unit uses ability (where the fields are set to any)", anything that is going to proc more than once per second. When you have 10 players and a few triggers that proc more than once per second, it's very, very easy for your triggers to just stall during combat or intense events.
Solutions include the data editor and dummy events. I mentioned this in your other thread, but if you want to know when a specific unit dies, give it a behaviour that fires a dummy effect off under Damage Responce under Fatal -> Handled, then make a trigger that has the event corresponding to your dummy event. There, instead of a trigger that fires every time a unit dies while you try to find the correct unit, you have a system that will only fire when the unit you want dies. There's always an alternative, be creative.
Quote from Eiviyn: Solutions include the data editor and dummy events. I mentioned this in your other thread, but if you want to know when a specific unit dies, give it a behaviour that fires a dummy effect off under Damage Responce under Fatal -> Handled, then make a trigger that has the event corresponding to your dummy event. There, instead of a trigger that fires every time a unit dies while you try to find the correct unit, you have a system that will only fire when the unit you want dies.
That's a good idea, I'd never considered that. Nice!
I'm still getting my head around the data editor, which is why I've stuck with triggers at the moment. I just flicked through the create effects area, and was wondering if the Event Type mattered for a dummy event? Can it just be anything?
Also, thanks a lot for all the help Eiviyn! Your advice is much appreciated =)
Placing conditions in your triggers to narrow it to a certain point, instead of If-then statements will greatly reduce lag instead of Unit Takes damage with no condition putting to check if unit is hero will reduce lag a lot.
Does damage response only trigger when the unit takes fatale damage? Because I have a trigger that kills a unit, and that doesn't seem to cause the effect to trigger. If so, is there a way around this?
Also, I'm having difficulty with it at the moment, where in some instances it will trigger twice for some reason, while at other times it won't trigger at all, especially if a lot of the units are dying at once (eg: to a nuke)
Not at all. Internally a condition is nothing more than a normal if-then-statement.
And events, no matter which, shouldn't really bother you much unless you have like 20x a highly generic event (like Any Unit Takes Damage) and a million units on your map.
If your triggers lag it's usually one out of two reasons:
Also, narrowing down events can help. I know i had triggers "Any unit acquires target", "Any unit is attacked", "Any unit dies" and "Any unit is issued an attack order".
Instead of "Any unit" i put in variables with the appropriate unit, and just added one event for each unit into the trigger. "Hero[1] dies, Hero[2] dies..." or "(Phase Assasin) is issued an attack order", "Beacon[1] is attacked" etc. That way i narrowed it down to 8 units per trigger, and not the up to 200 which are on the map at the same time.
If you can specify the event using a variable, you probably wont even need conditions and have it fire a lot less.
Also, one thing i was wondering as well about trigger lag... What's better, using a custom action or "Run trigger", and if i have multiple triggers doing basically the same thing but with different parameters (but which i cant merge), would making a custom action increase performance?
I'm also thinking of making an RPG, so i'll probably have way more questions and open up my own thread for those... (again, mostly performance based or what is a better way to do this and that...)
Keep in mind that if your testing with the trigger debugger window running it will be about 10 times laggier then just playing on bnet