• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

[General] Triggers initialization

Status
Not open for further replies.
Level 5
Joined
Feb 1, 2024
Messages
44
Hi, I see in many custom maps that people use the first trigger to initialize many other part of the game. Does this method help reduce memory loss and increase performance instead of running all triggers that are possibly used at the same time?

My map contains many heroes and I wonder if I should enable their relating triggers only when I pick them.
 
Level 45
Joined
Feb 27, 2007
Messages
5,578
Hi, I see in many custom maps that people use the first trigger to initialize many other part of the game.
Loading a ton of stuff in a Map Initialization event can cause players with weak computers to desynch/disconnect as the map starts. By delaying loading/setting up/doing all of those things until after some elapsed game-time (0.50 seconds is my rule of thumb) you can avoid this issue. There are also some trigger actions that cannot be run on Map Init triggers, and finally if the Map Init thread (which is shared by all triggers that use this event) becomes overloaded it can hit the operation limit and threadcrash before all Init triggers have properly run. That is quite rare but possible.

Finally, using a dedicated non-Map Initalization trigger can make it easy to reset the map and run it again without having to restart or anything. You could do that with a regular Map Init trigger; I include this for completeness of explanation.

None of this has anything to do with turning on triggers.
  • An enabled trigger whose events never fire has 0 performance impact, same as a disabled trigger.
  • An enabled trigger whose events fire constantly but whose conditions are efficient and ultimately prevent the trigger from running at all is almost 0 performance impact (triggerconditions are efficient).
  • A constantly-firing, enabled trigger with inefficient/weird conditions or one whose Actions fire but are basically skipped by an If/Then/Else block have a measurable performance impact, but it will likely never matter.
  • An enabled periodic trigger with inefficient conditions or actions that require a lot of searching/filtering is likely to cause a noticeable drop in performance. The most common example is something like a 0.03s periodic trigger that uses Pick all units in (Units in (Playable Map area) matching...).
  • An enabled periodic trigger with efficient conditions and well-structured actions will not cause issues at all because basically nothing is being run/checked unless it really needs to be. The most common example to fix the issue in the bullet point before this would be to use a Unit Group variable to keep track of all the units you need to check rather than searching across the map to find them all every 0.03 seconds.
The vast majority of triggers should never need to be turned off, but ultimately it depends how each one is structured/built.
 
Last edited:
Level 5
Joined
Feb 1, 2024
Messages
44
Like in almost every single map of Warcraft 3 campaigns I see they use initializing triggers. They must be using it to variable setting purposes only. In fact I'm quite worried about triggers for custom aura, as they will periodically check until game ends.
 

Uncle

Warcraft Moderator
Level 73
Joined
Aug 10, 2018
Messages
7,866
Like in almost every single map of Warcraft 3 campaigns I see they use initializing triggers. They must be using it to variable setting purposes only. In fact I'm quite worried about triggers for custom aura, as they will periodically check until game ends.
Just make your map as best you can, considering efficient methods as you go along but not overdoing it. It's much better to have a finished map that has some poor triggers than an empty map because you can't make up your mind on what to do next. But of course try to maintain solid practices throughout -> clean up memory leaks, use variables properly, manage edge cases. The polish stage can happen at the end once you've got a working product.

Also, get your organization down from the very start and do not get lazy about it. I've helped many people "fix" their maps over the years and it's almost always been a complete mess with triggers and variables named "untitled 001 copy copy", poor use of folders, no comments explaining what anything does, etc. You should be able to come back after a year long break and almost immediately start where you left off. You can actually waste more time by doing things the lazy and "fast way" since it costs time down the road to fix and relearn these things. Also, avoid defining things in a way that only you would understand. Pretend that you're working on a team with other people who will be modifying/working on your triggers.

Then if your aura triggers (which have been done as efficiently as possible) cause noticeable performance issues, simply disable them and move on. But cross that bridge when you come to it.
 
Last edited:
Status
Not open for further replies.
Top