Marrying Triggers; Effective?

Could warcraft III really be programmed so bad that it doesn't use what I would think to be common sense? I haven't seen good evidence that that is the case.

I don't believe that every single trigger is run through, checked if the event happened, and then executed if so. The smarter thing to do would have an event occur then send a signal to its event handler, and then executes all triggers grouped with that event.

The reason I ask is because, I use the event Generic Unit Dies over and over and over again in one of my maps, with different conditions. Rather than one trigger that handles all death events. It seems to run fine.

If there is a speed gain, I would think it would be so little that it simply wouldn't be worth the pain of disorganization.

Anyone have more conclusive evidence of this than the polling speculation?

Funny, just tested and works fine for me. Guess cable can't compensate for your video card :)

It is my belief that this is how it works. Try generating 1000, or 10000 do-nothing periodic triggers. The only lag is when the periodics actually fire, and then there is big lag spike, if WC3 is using some sort of moronic polled system then it would lag constantly.

I speculate that the event system is a combination of event queue (for timed), callbacks (for things like unit dies) and polled (for things like value of real variable). It's also possible that even when a trigger is turned off it's still registered for it's event, only destroying the trigger stops that.

The performance benefit of marrying triggers is minor. If you have N triggers firing on an event (say unit dies) but only one of there conditions actually evaulates to true. If you use nested if/then/else (note: must be nested) then it will, on average, only evaulate half the conditions before finding the true condition and running the appropriate actions. That performance benefit is guaranteed, there may be other benefits from reducing the number of callbacks (or whatever). In any case there are far more effective methods to improve performance, why settle for O(N/2) when you can have O(1)?
Using trigger Arrays. (Example, you have a lot of type of summoned temporary units for things like missiles, each ones actions can be put in a seperate trigger, then in the "Unit summons a summoned unit" call TriggerArray[Point value of summoned unit])
Using hashtables. (Example: Your map has hundreds of triggered abilities, use a trigger array and generate the index using a hash function)
Eliminating memory leaks.
Just plain more effecient actions, if you have a giant for-loop, and a condition inside it, and the condition never changes inside the forloop, move the condition to outside the forloop. Pre-calculate commonly used things, like if you use "Position of casting unit" a lot inside the loop, assign it to a variable outside the loop. That sort of stuff.

I dont have a problem with any other map. My card isnt terrible; I admit it's not good, though. Geforce 3 Ti 200. I've never had problems with any map, with the exception of those ridiculous no gold no limit maps where everyone ends up having over 100 units at the same time...

On top of that, it wasnt ME lagging. I was the host. I was having a dandy time, but nobody else seemed to be sharing the experience. Four to five, sometimes all 11 others, were lagging at the same time. Finally, about 4 reached 0 and were dropped. At first, I thought it was due to their slow connections. I told them to invest in something better than 56k. To my surprise... they informed me of their DSL and Cable modems, including one T1 (a shared college T1, I'm sure).

So please data, dont use petty insults...

You still didn't answer what version you were using.

Why did you have to unbury this? It was growing mold..
I was using whatever version was recent at the time, I dont remember.. there's no version marker on the game name.

Um, Data I think Battledome 3 has been beaten for complexity....

Grater why settle for trigger arrays when you just don't need them period.

For instance almost all spells that are target unit ussually make the same assertions and same initial calls. If you wanted to be a stickler for effeicency you would make a function that would do the whole process for you.
Since you already have it running from a trigger it can get the damaged unit and the unit who casted it and then you'd just need to make a call asking effects of this spell.
call SpellDamage(int amount, bool stun, bool dizzy,bool freeze, bool instagib)

your spell damage function should have another function it uses to create the bounty and give you xp if you killed that unit.

Instead of having a hundred some threads being opened by the event being called and then only hope that the condition kills the thread more then conditionals nested if. (unsure noones really tested the effeciency of triggers conditions vs If then blocks).