I disagree with some of that, here is my reasoning:
1. X Deaths of X remains constant for the entire game based on which character is selected. This condition is always true.
2. Accumulates at least X gas is also easily met, especially with weaker spells having a low gas requirement (gas regens constantly)
The Command / Bring would be the conditions met the least frequently (rarely met).
Completely agree, but people who posted above you haven't known this additional info.
I personally don't distinct deaths/accumulate from each other, neither do I distinct command/bring much (yes I know they may have little lag distinctions but I found it impractical).
A good idea which none have pointed out so far is to
precache the bring/command conditions. The basic idea is the following. I don't know, but let's say all these triggers have to check Brings X to Y where X and Y are constant in a given trigger block (which contains 500 triggers in your case). Then you do like this:
Trigger0 (This one goes somewhere on top)
Conditions:
Actions:
1. Clear switch S
(...)
Trigger1
Conditions:
1. Bring X to X
Actions:
1. Set switch S
Trigger 2 (This one copied 500 times)
Conditions:
1. Switch S is set
2. Commands X
3. Has exactly X deaths of X
4. Accumulates at least X gas.
Believe me, this method applied consistently to all trigger-consuming subsystems will save you much lag.
EDIT:Also,
1. Always try to store the game state info in a switch or a death counter. Let's say the Command condition in your trigger checks whether hero is alive or dead. If this condition is checked in many triggers it's probably not very wise to check the condition in it's pristine form. What you do is
Trigger1
Conditions:
1. Has exactly 0 deaths of dcIsAlive
2. Commands at least 1 uHero
Actions:
1. Set deaths dcIsAlive to 1
Trigger2
Conditions:
1. Has exactly 1 deaths of dcIsAlive
2. Commands at most 0 uHero
Actions:
1. Set deaths dcIsAlive to 0
Then you obviously check the deaths condition everywhere. As you can see, this is another variant of precaching technique. You store a game environment state in a DC state machine and specify all the transitions between it's states, then you check the state of the machine fast instead checking all the hard-weight "environmental" conditions. In the example the state machine got only two states, but obviously you can accommodate the idea to something more complex.
2. Don't miss the opportunity to add additional light-weight conditions (switches/deaths/accumulate/score and such) above to eliminate the necessity of checking a hard-weight condition. For example, if you can add something like
Trigger1
Conditions:
0. Has exactly Y deaths of Y
1. Bring X to X
2. Commands X
3. Has exactly X deaths of X
4. Accumulates at least X gas,
which eliminates half of the cases then do it! Combine this with the first method. When you have enough "environmental" conditions precached in DCs this allows to guard all the bring conditions with lightweight ones in most cases.
EDIT2:Actions are the source of most lag.
No doubt in small maps this is yes. In large maps however conditions start to become a big problem.
Post has been edited 4 time(s), last time on Jun 30 2010, 8:02 pm by Wormer.
Some.