Is there a downside to many events?

[afisakov]

Is there any downside to having many events run from a single trigger?

In this case I am working on a map and the previous developer has a bunch of triggers that read

Event: A unit enters region X
condition: unit type equal to maze runner
action: remove entering unit from the game

I was thinking I could save space by making it one big trigger like

Events: a unit enters region x
a unit enters region y
a unit enters region z
a unit enters region x1
etc...
condition: unit type equal to maze runner
action: remove entering unit from the game

I know doing this should save a bit on mapsize and seems easier to look at, but is there any downside? Will it somehow take longer to process?

 

[xtian07]

Nope. No Downsides

 

[GFreak45]

its actually prefered as long as you dont have 1 trigger with a million if statements and every event in the book... a good example of this would be PlayerUnitEvent by Magtheridon96, in which you can just do a simple call with each function adding all triggers to be run into one event (actually creates one trigger but puts all the actions into it), there is a GUI version, if you would like to search for it, it is on thehive

 

[afisakov]

Thank you.
I changed it now

P.S. Is "like" the new +rep system?

 

[GFreak45]

yes

 

[KaerfNomekop]

1 Like = 1 rep. It's the same increase for everyone now; you don't add more rep for having more rep.

 

[Accname]

Of course there is.
Any additional events in your map will add slightly to the processing time of game actions.
I think you can very well imagine that if i have 100 triggers all with the event "a unit dies" compared to only a single trigger with that event, that if a unit actually dies in the game it will take slightly longer to activate all the triggers associated with the 100 events then it would for only a single trigger.

This overhead, however, is so minor that it is not really important and can be ignored if not done to ridiculous levels.

 

[GFreak45]

you are right accname, but the biggest issue that is fixed by doing this is execute count, the higher the execute count the harder the system will lag, this was tested in the forum for Magtheridon96's Library by, i believe, nestharus and bribe, could be wrong on that though.

Every execute = a new thread opened, more threads = more lag, 1 no-wait thread = less lag

 

[Accname]

I dont think triggers are handeled in separate threads.

 

[GFreak45]

yes they are or waits would cause issues, thats why the execute count is so important, essentially it is calling ExecuteFunction(function Trg_Somefunc), though i believe it is called using an underlying function not actually available in the editor. There is no way 2 instances of the same trigger can be run at the same time in the same thread if there are waits

 

[afisakov]

There is no way 2 instances of the same trigger can be run at the same time in the same thread if there are waits

What happens if there is a "wait until" in a trigger that runs every 2 seconds?
will new instances activate and give orders or will the entire trigger be useless until the wait until function if fulfilled?

 

[Imp Midna]

What happens if there is a "wait until" in a trigger that runs every 2 seconds?
will new instances activate and give orders or will the entire trigger be useless until the wait until function if fulfilled?

afaik, the trigger will be executet every 2 seconds, no matter what happens at the wait. evvery trigger gets its own "instance". I doubt though that every "instance" has its own actual thread, no real programm would ever allocate 20 threads just to do some calculations...

Also there is a side effect (at least a side effect i can think off), though a rather practical one: you can turn triggers off. If you have 2 triggers with the same event and you only need one, you can turn it off. If you, however, only have 1 trigger that goes through a few ifs emulating the conditions of the 2 seperate triggers, you could not turn them off. Well, you could make a boolean to skip those conditions, but i think a jass comparision will take longer then the evaluation if a trigger is off (which is done in hard code).

 

[chukky-jr]

i'm not quite sure if i understand correctly, but does that mean if i want to create a triggered spell, it is better if all of triggered spell is fitted into one trigger that holds the event 'Unit - Starts the effect of an ability', rather having individual trigger for each triggered spell?

 

[Accname]

yes they are or waits would cause issues, thats why the execute count is so important, essentially it is calling ExecuteFunction(function Trg_Somefunc), though i believe it is called using an underlying function not actually available in the editor. There is no way 2 instances of the same trigger can be run at the same time in the same thread if there are waits

Do you have an actual idea how a thread in an OS actually works?
If that would be true the performance of wc3 would drop down below 0.
What might be is that blizzard is simulating a similar condition then threads for triggers but i can not believe they would actually create separate threads for ingame triggers. Alone the synching problems would kill any bigger custom map, not speaking about the context switching which would appear in thousands.

 

[GFreak45]

yes I understand how a thread in an os actually works, and i know that, i do believe they are simulating a thread system, but thats what i was meaning, that with "their thread system" thats how they create triggers that run properly with multiple instances, even event systems in C++, Java, Python, and many many more work like this, creating new threads for each instance of a function (trigger) ran off an event (C++ uses delegates which create new threads in and of themselves, in most cases)

I believe they would make their own version of a thread because thats just what blizzard does, take sc2 editor for example, it is a C language, but classes are severely limited to the point of being between C and C++, this is just one perfect example of this, while there are many others