I'm having an issue where an important transmission isn't playing because of a short wait timer that happens to activate just before the transmission fires.

Is there a way to cancel all wait's or set them to 0 prior to firing the cut-scene?

You can't stop a wait once it has started. Only thing you can do is add a condition to make sure the wait never activates in the first place.

Or you simply replace the wait with a DC timer instead.

This is the solution.

There's ways around wait blocks, but they're all just that: Workarounds.

So I was planning a map that would use the escape key to make a certain event happen, (by having a preserved trigger with an enormous wait followed by the event).
I knew I wouldn't be able to sue any other waits on that map but I did not realize that transmissions would also be interrupted, regardless if they pause the game or not.

I guess I'll have to throw that idea out then.

A possible "work around" other than DC may involve having the transmission trigger be a first priority. What I mean is (hopefully) the player for the transmission is Player 1 and that you move the trigger to the top of the trigger list. This way it has priority over other wait triggers occurring. If you have multiple wait triggers running (especially with perserve trigger), the first ones read down said list (Top to Bottom, from Player 1 to Player 8).

I never really use transmissions so its interesting that they would share the wait trigger timer (but it makes sense since the transmission must finish before the next wait triggers)

Transmissions are a combination of several actions in one. For example show portrait, and as you noticed a wait. The only thing you can't (easily) emulate is the selection circle. So technically a transmission IS a wait.

The mentioned workaround only works if both events start at the same time. And it forces the second trigger to be blocked, so it's not really helping, because if you don't need it to fire, you could just remove it.

There's no reason you can't time the described scenario with death counters rather than waits.

In general it is considered poor mapping practice to use waits to delay triggers as only one can be run at a time without causing trigger interference. As Nude and Oh_Man say, DCs are the way.

Also, to achieve the ESC key triggering an event, you could use EUD Editor 2 with the MSQC plugin enabled to allow for keypress detection and then just make whatever triggers you need in the trigger editor. Bit of a learning curve, but well worth the effort.

Funny ive been asked to fix a map which use wait blocks in +500 triggers and it cause faults/crash when players play em so players wanted me to fix the map but 500+ of wait block triggers takes more less the same time to fix this into dc triggers, as making the full map from scratch. so sad when some one actaully made a good map and than used wait blocks in all hes triggers to end up with a map that crashes more than often.

My main issue is that I didn't expect a transmission given a duration of 0 would be added to the wait stack. Otherwise my map would only have 1 wait.


I'll have to look into this, would this require mods to run the map? I know a bit about modding from long ago, but I was trying to avoid making maps that require mods.

Consider that hyper triggers use stacks of wait(0) and wait blocks are still an issue here.


No, in my opinion, this is one of the greatest beauties of EE2: it gives drastically expanded capabilities at the small expense of disabling the ability to have extended unit limits. Everyone on SC:R battle.net will still be able to freely play your map, no additional downloads required.

Check out these links for some examples of what can be done with EUDs: EUD Documentation Thread, Impossible Ultraviolet & Spark of Ean'lu

Post has been edited 1 time(s), last time on Dec 17 2021, 3:18 am by Ultraviolet.

In this case workarounds are useful and effective. Easiest way is to give them to a computer player.
If that's not possible there's even more (more complex) ways to setup hypers. Just ask if you need that.

Out of curiosity, when can waits cause a crash?

One thing that may help you is each player has their own waits. Eg. player 1's waits can't cause a wait block on player 2's triggers. You may be able to put your big wait timer on a AI player instead of a human one that way it won't mess up the transmissions.

as far as i know wait blocks can cause desync which result in crash for players disconnection. i tryid it with one map where i deleted all the wait blocks in triggers than asked the players to test the map now.. ofcourse the map dosent work the same way many things dosent work cause of deleted wait blocks but the map was actually play able but didnt crash any more.. (players didnt disconnect)

so players reported to me that deleting wait blocks resulted in no desyncs. cant say 100% that it was the wait blocks causing it but definately is an option