I cannot find the reason for a strange delay in my map. There is a central item that moves among 6 player slots. When it comes to an empty slot, it moves to the next one, but that always takes about 4 seconds, whereas I have the wait delay set at 125 ms.

Hypertriggers are under p7. There are 4 exactly the same, with 63 waits of 0 ms in each one. There are no other triggers under p7, which is a computer.

The check triggers are under force 3, which holds only p6, a computer player:

conditions:
p7 brings exactly 1 main_item to location main_p1
force1 brings exactly 0 civilian to main_p1
actions:
preserve trigger
wait 125 ms
set swtich advance_turn

There are 5 other triggers like that, for each other player.
The actual advance trigger is owned by force3 as well, and looks like this:

conditions:
switch advance_turn is set
p7 brings at least 1 main_item to location main_p1
actions:
preserve trigger
clear advance_turn
move all main_item for p7 at anywhere to main_p2

Again, there are 5 other triggers like that for each other slot.

Now here's the thing. If i disable to wait action, it advances very fast. That's what makes me think its a conflict in hypertirggers. Could it be that both p7 and p6 are computers? I've also tried modifying the wait time from 125 ms to 25 ms, but there was only a marginal decrease in the delay.

So, any thoughts?

Each player can only run 1 Wait() action at a time. If P7 has some of those triggers, AND the hypertriggers, that might be your problem.

To get around this, try using a Death Count timer. The basic idea behind a death count timer, is that if you subtract 1 death count/trigger cycle, and you know there are approximately 12 trigger cycles per second, you can set the DC to any time you want (in multiples of 1/12th second of course) instead of using waits. Then when the DC is down to 0 deaths, have a condition to check for that and then run your actions. Something like this:

Conditions:
Event Occurs where we want something to happen later
ACtions:
set death counter to 12 (thats 1 second with hyper triggers)

Conditions:
Death counter is exactly 0
Actions:
Stuff Happens

Conditions:
Player suffered at least 1 deaths of Death COunter
Actions:
Subtract 1 death for current player
preserve trigger.

Interesting, but that can't be it, because the only triggers for p7 are the 4 duplicate hypertriggers. There are absolute no other triggers for p7, and p7 is in force 2, which also has no triggers at all.

Also, I checked p6/force 3, which has a lot of trigger, but i'm pretty sure there's no other ones there with a wait action at all. [EDIT]: that was wrong, there were some. I fixed that now.

Post has been edited 2 time(s), last time on Oct 10 2010, 9:56 pm by DrZygote214.

Well delays like this basically only have 1 explanation: Wait blocks.
If you're using hyper triggers it's not recommended (and not necessary) to use waits. Use death counters instead, as Vrael suggested, and your problems will be gone. Promise.

Post has been edited 1 time(s), last time on Oct 10 2010, 10:09 am by NudeRaider.

copy/paste the trigger from trigedit in SCMDraft into notepad(++) and press ctrl+F. then you can find all the waits in the map (press f3 to find again). As everyone else has said, please don't use waits.

I am not sure I understand all this adversity to waits. As I understand it, only 1 wait can be active at any one time, but that's per player. So really as many as 8 waits can be active at any one time. My hyper triggers are under computer player 7, and there are no other triggers for p7 at all. Even another computer player can have waits.

However, do you perhaps mean that a wait block can still happen between 2 players, even tho its not conflicting with the hypertriggers?

BTW I finally discovered the problem. P6 did have other triggers with waits in them, that could activate at any time. I did some rearranging under individual players and all works now. I suppose this means that there were wait blocks in p6 conflicting with other waits in p6, instead of p7.

Yeah hypers are waits, so they'll always cause a wait block when a wait fires because they are always running, but if two other waits coincide to run at that same time you'll also get wait blocks. They are not hyper trigger specific. Just replace any wait you can (which should be every single one) with a death counter.

Death counts are much easier to use than Waits for anything even semi-complex, and are a lot more flexible in general.

Death counts >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Waits.

It should be noted that death counters are affected by the game speed. You'll need people to play your map on Fastest in order to accurately convert Waits to DCs. Virtually everyone plays on Fastest anyway, but if you want to be sure, you may want to specify that in the map description.

More information on wait blocks can be found in the appropriate article in our StarCraft 1 wiki.

It's also possible to detect game speed and adjust death counter triggers accordingly (you'd need 7 copies of each trigger containing a dc, 1 for each speed setting). But that's really overkill.

That's really all that matters in the end-- that your map works. It's really irrelevant whether you do it in a way that others consider "better" or "worse" so long as it functions properly, so if it already works with waits and you're not going to need to do it with death counters, then there's no reason to change it. It's good to know about death-count timing for the future, sure, but just because waits can cause problems doesn't mean that you must remove them in a situation where they're working fine. And there are plenty of situations where a wait can save you a whole bunch of triggers (and hence time), so long as you don't mess up and create wait blocks. A lot of people are scared of waits because a lot of people screw them up...but that doesn't mean that it is impossible to use them in situations where problems will not arise.

Not saying he should go back and change them, but there's no reason to use Waits over Death Counts.

If replacing a Wait with a Death Count timer ever involves "a whole bunch of triggers" then ur doin it wrong.

If you can't save on triggers with the occasional use of a wait, you're probably not using the waits efficiently. WIth waits, you can consolidate actions that go before a delay, the delay itself, and actions that occur after the delay into one trigger...and you're not limited to just one delay per trigger, either. This consolidation means they have a higher inherent efficiency in terms of trigger count than death counts (and if you can avoid any disadvantage, even saving one trigger would be superior to saving none...and it's not at all hard to save more than one trigger on a single occasion, let alone in your map as a whole). Personally, I find that a well-placed Wait 0 is often the easiest way to solve problems relating to the different update rates of Starcraft conditions...just put it in the right spot and the problem is gone, with no other changes required.

Death counts may be the most suitable system to use as your main method of timing, but that does not mean that you should neglect other systems. For instance, suppose you have a map where the player can buy multiple reuseable healing items that will repair him, and you want to set up your map such that each one has its own independent cooldown (so for instance, if the cooldown is 10 seconds, and the player has purchased 40 of the healing item, he should be able to heal four per second continuously, because the cooldown for the first one will finish 1/4th of a second after he uses the 40th one, the cooldown for the second one will finish 1/4th of a second after that, and so on. Of course, because the effect that you are trying to simulate is each item having its own cooldown, there's no reason why the player should have to use his 40 healing items in nice, neat 1/4th-second intervals.) Now, that's just one item type: suppose your map has not one but 10 types of item, each of which allows each example thereof to recharge independently of each other item that you own. If you were to handle the timing in this situation with death counts, the fact that each healer, each exploder, each teleporter, each whatever is recharging based on a timer that is only answerable to when it was used, independently of others of its kind, you'd wind up with a mess, especially if there's no limit to how many items of each type the person can buy. On the other hand, if you were to do things the way it used to be commonly done, with each different item's recharge based on a unit (usually air) moving along a track of set length, you could handle hundreds of different independent rechargings with just a handful of triggers.

What I'm trying to get at is that you should always try and use what is best for your situation, not necessarily what is best 99.9999999% of the time, even if the system that is better 99.9999999% of the time is only 0.00001% worse in this particular case. Death counts are the best timing system most of the time, but sometimes you can get slightly more efficiency with a wait, or a moving unit, or some other alternative form of timing. Don't be afraid of doing something the "wrong" way if that way is right for your map.

I use this system occasionally in some situations, usually with a P9 unit. I would still never have reason to use Waits.