Staredit Network

in the map im making... the first half of my map works fine... but then it comes to this part where all my waits become VERY long waits... whether i make the wait a 1millisecond wait or 100 millisecond wait, when u play it it waits at least 20 whole seconds (literally)

anyone know why?

add me on msn if u have it... plz... fhilaci0s@hotmail.com

Don't use wait Triggers use Death Counters instead.
There is a Tutorial about it so go look for it, it isn't very hard to find/undersdtand.

The problem with so many wait triggers is that they tend to add up. So a 1 second wait and a 2 second wait become a 3 second wait. They just tend to add up and not be counted separately.

They don't actually "add up". They stack, and I know for a fact that they don't add. I don't what the stack rate is, but to answer your problem, you have two or more waits running at the same time, as beer said, so if you can get rid of one of them.

Because SaLaCiouS(U) hasn't added the tutorial for death counters:

Death Counters
Death counters. There are many forms of counters. Countdown timers, minerals, custom score, razings... etc. But the one most commonly used is Death. If a unit dies, then that player's death counter for that unit increases by one. Triggers can detect how many deaths a certain unit has and can manipulate the counter to add, subtract, or set to a certain number.

You can use death counters like switches.

Trigger

Actions:

¤ Modify death counts for player*: Set* X for unit*.

You can select which player* you want to set the death for, what unit*, how to set* (add, subtract, or set) for what number (X*).

With this action, you can have conditions that respond accordingly.

Trigger

Conditions:

¤ Player* has suffered quantity* deaths of unit*.

Player* will be the player number, quantity* is at least, exactly, or at most a certain number, and unit* is the unit that you used to set the deaths.

This gives you a huge range of switches. Even more than 256. It is best to have an unused unit so that you don't interfere with the kills and deaths of the unit.

Now there is a death counter timer.
With this trigger

Trigger

Actions:

¤ Modify death counts for player*: Add 1 for unit*.

Without hyper triggers, this will add 1 death to the unit* per second.
With hyper triggers, it will add 12 deaths to the unit* per second.
This allows you to constantly add while having something to reset it when it reaches a certain number, or let it countdown to 0 and set it up again.

I hope this isn't too off topic, but is that also how people make bounds where multiple obstacles fire at once?

thx, that death counter sounds good, man... now i gotta go thru my rpg and change all the waits to death counter trigs

edit: wait a sec... does a death counter work like a wait?
edit: nvm i figured it out... thanks for ur help

When a wait is running no other waits owned by the same player can start. So what they do is delay one another hence the term 'wait block'. If you have a trigger with a 2 second wait followed by one with a 1 second wait then they don't both wait 3 seconds. The first trigger will fire normally and wait 2 seconds. The second trigger on the other hand can't run its wait because the one before it already is. So therefore it must wait 2 seconds before it can run it's wait of one second. This is why people think they "add together"



They can do several differant things

• A. They make multiple obsticals in the same trigger such as solars bound tournament
• B. They can use death counts or some other form of alternative waits.
• C. They make sure that the obsticals are exicuted by differant players so the waits don't interfer with eachother. (i did this in time up bound)

Okay all... can I sorta clairfy on the whole "WHY THE F*CK IS THE [WAIT]S SO LONG?" problem?...


okay firstly... lets look at the 'problem'....

[Wait] Command...

the wait command is a command in a trigger that causes for all actions below it to "stop" working for a brief amount of miliseconds... well... apparently, each player has the ability to hold a pause.... other pauses/stopping triggers include [Transmission], [Pause Game], [Center View]...

All of these triggers are what I call "Priority Triggers", meaning they are triggers that MUST finish first, and ALWAYS have priority over any trigger below it... as triggers are written top to bottom, so are priorities.

So the problem you are having, as well as ALL other people with this situation is that, you are putting these priority triggers in a row with each other which run at the exact same time.

Thus causes the game to start "Stacking" actions on top of each other. Because the actions start stacking, it keeps taking into account other waits, and waits for a wait to end before another wait can start.... this causes for the map to become "confused" and start the whole wait problem...

Lets look at this example...
ever wonder how a hyper trigger works? Hyper Triggers are a great example to this:

A) Hyper Trigger1.
B) Hyper Trigger2.
C) Hyper Trigger3.

here are 3 Hyper Triggers you placed in your map.

When run in a map, the triggers notice there are other waits so it starts action stacking... so the triggers run the waits according to this:

A,B,C,B,C,A,B,C,B,C,[B+C Hits Preserve],A,B,C,B,C,[A Hits preserve],B,C,A,B,C,A... etc...

or something like that... I forget... but the triggers start stacking on each other in that manner... and creates the semi-infinite loop that we all love... but we forget to realize that waits can hurt...

lets look at how they can hurt...

Player1,

Trigger1: {Always}/[Wait 500ms],[Create 1 Zergling at "Location"], [Preserve Trigger].

Trigger2: {Always}/[Play Wav],[Wait 12500ms],[Preserve Trigger].



Yikes....
as we can see this is how a trigger can go wrong...

it would look like this:

Trigger1,Trigger2--------wait 12500,Trigger1...

causing for the long delays...



How to remedy this?

Easy....
here are a few ways to do it...

firstly we must play by the rules of waits:

1) ALWAYS have only 1 Priority trigger for a player at a time within 1 trigger box, Multiple Priority triggers can occur within the same box, but not together.
2) ALWAYS keep hyper triggers on computer players.
3) NEVER use excessive hyper triggers.... (doesn't really matter but is annoying to see 1000 hyper triggers in a map...) =P

Okay... now we must look at waits...

as said, waits cannot be within two other triggers... theres an exception apparently...

Waits can work together if you use the SAME wait times in each trigger...

meaning if your hyper trigger is set to 15 ms instead of 0, you can set all triggers you want to do within 15ms intervals... like, creating a Zergling, Zergling, Hydralisk combination in a certain order with actions happening first...

"Waits LOVE to wait together" =P

soooo.....
goes to my next solution...

"Wait Slicing"
If you slice your waits to smaller wait times, you can avoid this problem... like your VERY VERY long music file, like 10000ms... if you slice the music file down you can avoid wait stacking... like this:

Player 1
[Always]
----------
[Play Wav]
[Wait 1000ms]
[Wait 1000ms]
[Wait 1000ms]
[Wait 1000ms]
[Wait 1000ms]
[Wait 1000ms]
[Wait 1000ms]
[Wait 1000ms]
[Wait 1000ms]
[Wait 1000ms]
[Preserve Trigger]



by making a music trigger like this... the wait stack will only be 1000ms before it can continue to commence with waits... so it would look like this:

[MusicTrigger1000ms],[HyperTrigger],[MusicTrigger1000ms],[HyperTrigger]...

THIS IS the solution to all your problems... just do this and you will be alright... the problem is that, because of the priority... all other triggers will start occuring at 1000ms intervals... meaning you should slice your music triggers to a universal number like 100, or 500... those are safe numbers to use, and easy to remember...

this will also solve your "ETERNAL CENTER VIEWS", yea I know you've seen this at least once in your mapping careers...

and blahblahblah

have fun with this...

Well at least you tried to understand waits.

I particulary like the part about "causing the map to be confused".

Oh yeah in your last example, unless player 1 owns the hyper triggers the hyper trigger will not be effected. This is because as you put it "well... apparently, each player has the ability to hold a pause". Thus the pauses don't interfer.

Lastly hyper triggers don't fire in whole like you implied. Waits from one will fire then waits from another.

Waits are really really confusing. It seems the easiest thing is to have hyper trigger owned by a computer and be done with it... right, or am I very wrong....

Yeah, if the computer player doesn't have any other waits the hyper trigger will cause all the triggers to fire, but won't be suject to wait blocks or blocking other waits.

One thing about the death count timer. If you want it to add every second but you have hyper triggers in use, then make it so that one trigger says "add 1 death of unit1" and another trigger says "unit1 death atleast 12, subtract 12 unit1 death, add 1 unit2 death".
Question though: if you have more than 3 hyper trigger blocks, then does it fire faster than 12x a second? And how do you make the "trigger" box here? is it just "code"?

no, 3 is the standard because any less will result in less than 12x
any more will just result in longer time the hypers work.

for trigger box, do an normal add reply and you can see the little box thingy there.

OK, need to delete some hyper triggers now. And Thanks

Yes yes I know... you need at least 3 hyper triggers to create a sucessful semi-infinite hyper loop....

(so don't delete all of them...)

I think because you might have activated to much triggers at the same time which use alot of waits, cause that can screw up triggers sometimes..

The amount of hyper triggers does not effect how fast they fire. It effects how long the effect last.

And you worked that out, if my memory serves me correct...

Yeah, its quite complicated to figure out exactly how long they will last without testing it but i can do it.

So they have like an expiration date? like, after half hour of the game, it stops using them?

It's just an amount of time that the hypers run, they don't 'expire,' they actually just finish the repetition of the wait 0 milliseconds. 3 hypers run for around 3 and 1/2 hours.
So it should be enough for most games

No... Turnin...
about the duration was that it would stop doing the loop at a certain time... and if you put a preserve trigger in the trigger actions... it repeats the actions once again when ALL the hyper triggers stop...


so say you got hyper triggers that work for 30 minutes,
at the 30 minute mark, it STOPS for a duration of a trigger going through a preserve trigger without a hyper trigger (approx 1.5-2 seconds), then after that it goes again for 30 more minutes... etc...

Ok. New understanding of how they work. Need to go and defrag my brain now.