Marrying Triggers; Effective?

Recently i've begun writing my triggers such that i have as few repeat events as possible. For example, all of my triggers that happen when a unit dies are in one trigger in a massive block of if/then/else statements.

Is this effective? Does it have any effect on the amount of memory occupied by triggers or does it just annoy the hell out of anyone trying to edit the map?

For certain things, I do it as well. Generally for 'a unit dies' events, or similar. I have also got into the habit of making trigger arrays, and calling them based on values I can derive from the event. For instance: If a character dies, Run Trigger(x) where x is the point value (Or some such) of the killing unit. Array entries can then be only made for values that I want to work. If I use Point Value, for instance, I could give all vampire units a point value of 50, and have at Index 50 of the trigger array an effect which causes the dying unit to turn into a vamp of its own.

Get it?

I get ya, but isnt it annoying to have to assign the dying unit to a variable then passing this variable to the secondary trigger?

Hmmm I'm a firm believer in writing triggers to maximize understandability, unless there is conclusive proof that doing something weird will give considerable and noticable performance gains.

Monster triggers can be very hard to debug, thats a good reason to steer clear of them.

Also under some imaginable implementations of triggers monster triggers will consume more memory than a bunch of small, specialized triggers.

Zechnophobe advice is very solid, arrays generally result in performance gains and can also makes triggers easier to read & modify. Wherever possible use arrays rather than lots of nested if/then/else.

That is extremely effective. Warcraft 3 uses a polling based event system, meaning that it checks through every even continuously and finds ones being run. So having as few events as possible is a good idea.

While sometimes it is a good idea, you will find that in 99% of cases it is better to have your code easy to debug and read than it is to use a special system that has usually negligable effects.

Sometimes it is cleaner to write one event for many triggers but generally it is not. Just register the dang death event multiple times, it keeps things more manageable.

For a command system, I do have one trigger that runs all of them and calls the appropriate trigger, but that is because I have A LOT of commands, and this way is more managable and easier and faster to implement, not because of the negligable speed increase.

First make the map, if you notice any lag, optimize things. Usually lag is not because of things like too many registered events though, and if the lag is because of a trigger the trigger probably uses a poorly thought out way of doing something. (I saw a city builders map that lagged because it added gold point individually for certain types of units every second, later in the game this could be 5000 total iterations between all the players)

Perhaps its just my training in java programming but I consider it the programmers responsibility to make his program as efficient as possible. After all, the end users NEVER look at your code.

Well maybe i'm just exceptionally anal about this kinda thing :)

effeciency is key.

The less triggers you have, the generally better. In fact try to reduce if then elses and use nested if then elses in place.

Example
Let say you would of had a trigger which runs on the event Unit levels up.

And you would of have had if then elses which read like so...
If (triggering unit==someguy && hislevel is 1) then blah blah
if (triggering unit==someguy && hislevel is 2) then blah blah

Its much better to go
If (triggering unit==sometguy) then
if (hislevel is 1) then blah blah
else if(hislevel is 2) then blah blah

Its more effecient and saves more clocks. In fact if you can use jass and completely cut out all the garbage does for if then else blocks.

Technically, the conditional block is the best place to put sweeping generalization rather then if then elses. As it can make sure that a function never gets a chance to enter memory. At the end of every block use the return/Skip remaining action command, to make sure the function leaves memory as quickly as possible.

It is somehow effective, but it is mostly because triggers take space in memory like an unit, so it is better to have one trigger than a lot of them, but debugging will be a headache. So only do that if the triggers are similar.

HERE'S A GOOD TIP:

You don't have to assign a unit to a variable to use him if you're going to run another trigger... And use him in it. Simply "Pick all units (Event Reponse(Dying Unit))" or something like that, and then run the trigger. You can now use picked unit ;).

Regards
Dead-Inside

I see 2 different kinds of responses to th15's question: one advocating managable code, one effecient (fast) code. Generally speaking, there is a trade-off between the two. The best way to program anything is to make it managable first, and only at the last moment optimize things if you notice lag.

Sometimes you can make your code look better and faster as well. Zechnophobe suggestion is a good example. Here's how it would look like in jass:


35263526 Where did you get the idea war3 uses a polling system? It probably uses some ugly hybrid, but it cannot possibly only use a polling system: that would be waaaaaay too slow. Registering a few events is not going to make a huge difference.

th15 if you are a Java programmer, you should know it's also a programmer responsibility to make his code readable, not just efficient. Especially with JASS and triggers where people are very likely to look at your code some day.

weaaddar you couldn't have a given a more useless optimization suggestion. Changing if blocks like you are suggesting might yield a 0.0000001 % speed increase.

Deat-inside you could also use DyingUnit() directly. Your idea seems useless.

Everybody else on this thread: I agree :)

According to Blizzard, Starcraft used a polling system, and it wasn't slow. I admit I made a logical leap, Blizzard has hinted at using polling in some form, but you are probably right that is a hybrid. But even so, a small difference is still a difference. In AoS: Hordes of Darkness, I have about 20 triggers running when a unit died because of my leveling system, my bounty system, my custom AI, and a load of other things. When I condensed it all to one trigger (when I was optimizing the code), it ran much faster and much less lag was experienced.

Just 20 and it caused lag already? I need to remember that next time I'm writing jass :)

@ jmoritz

Suppose you're right... It's still a good thing to know.

I did this with all of my unit attacked, unit died, unit order object, and unit learns a skill ones.... but the Starts the effect of an ability seems like an awful waste of time, as I have about 50 of those. Will it really make that much of a difference in lag?