I've noticed a rather odd problem with waiting for short time periods that doesn't seem to occur with longer time periods, and I'm wondering if anyone knows what the problem is and how to fix it/work around it.

Basically I've got a very simple trigger that has a wait time in it of 500 or 1500 milliseconds (or any time in between) and it seems to fire at uneven intervals. That is, every 2nd interval will be too short (or possibly too long) compared to what it should be.

The easiest way to replicate this to see what I mean is to create a trigger like this:
Conditions: Always
Actions: Wait for 500 milliseconds
Play sound (your choice)
Preserve Trigger

When you run this in-game, what seems to happen is it waits .5 seconds and plays the sound, then waits .3 seconds and plays the sound, then .5 seconds, then .3 seconds, .5 seconds etc....

It's possible that it is actually .5 seconds / .7 seconds, I don't have a stop watch so I haven't timed it exactly, but there is definitely an inconsistent interval happening here.

If I try with longer waits, like 10 seconds or 4 seconds, there doesn't seem to be any problem. I think I also tried 2 seconds but don't remember if there seemed to be a problem with that or not.

Anyone got any idea what's going on, and how to avoid it?

I realise the minimal resolution of SC waits is 84 milliseconds, but I don't think that can explain all of the inconsistencies here, as 84 milliseconds shouldn't be very noticeable, and this really is.

Maybe you're getting Wait Blocks?

Or you're not using hyper triggers.
Without them triggers are checked every 2s. Having waits screws with that because when the wait is done it reruns every trigger below it in the trigger list.

Game lag/slowdowns can contribute. Since sounds are played in a separate thread, not even pausing the game can interrupt them.

I should have mentioned this in the original post, but forgot.

I am using hypertriggers on player 8, while this sound loop trigger is on player 1. There should be no other wait actions occurring for player 1 (I only use waits for players when they use particular kinds of units, so when they control a kakaru only the kakaru wait actions will occur for that player) so wait blocks shouldn't be an issue.

So far Heinermann's suggestion seems most plausible. I will create a blank test map tonight that contains just this sound trigger and the hyper triggers and see if it happens on that map. If it doesn't happen, then it shows that it is something peculiar about my map, possibly an overlooked wait action or simple trigger lag (I do have a lot of triggers being run each loop, with a lot of 'bring at least 1' conditions), and if it does happen it'll show that there is something odd going on with SC.

In the meantime, anyone else have any ideas?

Yeah, the best solution would be to not use waits in your triggers. Waits are more complicated in actuality than deathcounts, and are much much more limited than deathcounts. If you're just playing a wav, then use deathcounts to do this and you won't have this sort of problem. If you need a more detailed explanation, you should check out this: http://www.staredit.net/?p=tutorials&tut=20
Let us know if you need more help.

I was originally using deathcounts for this, under a belief that waits would screw up my hypertriggers. But upon further reading I now understand that waits only cause issues with hyper triggers if they are on the same player with the hypertriggers. In my case P8 has the hypertriggers, so it lets me use waits for players 1-7 without any hypertrigger issues, correct?

Anyway, I switched from deathcounts to using wait timers as a way to free up units for myself. The map I'm making is here http://www.staredit.net/topic/9655/ and it's gameplay is a bit different from most UMS maps. Most UMS maps use only a small subset of units, often very large numbers of them, or they use particular units only in particular well-defined scenarios, or only for particular players. In my map, almost all moveable units can be used by all players 1-7 at any time. This greatly restricts the number of 'unused' or 'inconsequential' death counters that I can use for players - I can't go messing around with the zergling death count as a player may spawn a zergling naturally and get it killed, which could mess up my use of that death counter. So this means I'm restricted to using death counters only of units and buildings that players would not normally control, of which there are not a huge number in my map. I am currently utilising 30 units' death counts for the hero system I have in place (mostly buildings that the player cannot build), which doesn't leave a whole lot over for other uses, of which I have several, so I'm trying to use wait timers where possible.

Also I think wait timers are simpler to understand and easier to debug - if you've got a wait timer of 500 milliseconds, and know for sure that the player won't have any other wait timers running at the same time, then inspecting the trigger that contains the wait is enough to ensure it is working correctly. Death counters can obviously be altered from all over the place (essentially they're global variables), so it can be trickier to track down what is going wrong, and easy to make a mistake where you forget to increment/decrement it at the proper moment and end up causing problems for yourself, or make a typo and increment/decrement by too much.

Less complicated, but more limited.

Have a death counter (Cantina is my favorite) always add 84 to it every trigger run.

In your wait triggers, use "at least xxxx deaths" where xxxx is the wait in MS. Set deaths to 0 in that trigger.

If you're using 30 DCs already, you still have 15 units which can't die:

Waits are simpler, but you've got wait blocks going on, no question.

The 84 deaths and "at least" is a good idea. I might use that for some of my triggers that are already using DCs.

I'm using more than 30 DCs, it's just that I know the heroes use up 30 off the top of my head, 1 each for each hero. There are probably about another 10 DCs in use, + another 5 or 6 that I have replaced with timers. So as you can see, I am starting to run out of DCs that I can use in an unequivocal fashion without worrying about what's going on in the map.


Also are you sure there are wait blocks here? If I set the wait for 4 seconds, or 10 seconds, then it happens at exactly that time interval without any strangeness. Wouldn't wait blocks affect all other waits by the same amount?

Post has been edited 1 time(s), last time on Jan 20 2010, 3:19 am by Lanthanide.

Well, you can also use the same DC type for different players. You can also use buildings for DCs that you know won't be included in your map. While making my RPG, I actually set aside like 4 players for DCs and burrowed units, and it turned out that I really needed them. You just have to be a little clever in juggling everything. Whenever you can, use something like deaths of player 6, instead of deaths of current player, that way you can individualize between deaths of terran marine for player 6 and player 1.

Yeah, although in my map P1-7 are all playable and need their own unique stateful information.

P8 is the CPU and retains a little stateful information, but to use DCs from P8 for the other players, I'd need to use 7 separate DCs from P8 to represent the same state for each p1-7.

Actually after replying to rockz post I think I know what the problem is. I'm at work so I can't check it now, but will when I get home.

I have a terran civilian placed for testing out the hero stuff I'm implementing, and the civilian is one of the units that has a periodic wait (of I believe 600 ms) attached to it. The trigger for it is probably "commands at least 1 civilian". When the map is finished, the hero phase will be distinctly separate from the race stage, so it won't be an issue then, but at the moment the phases are concurrent (for testing purposes). I'm 90% sure this is the cause of the problem, but I'll update this thread later.

Even so, the 84 DC increment rockz suggested will be very useful for one of my other triggers, so this thread has been useful.

Yip, it was the civilian doing it. If the civilian had been placed on the main playing field (center location on civilian at main playing field), the rest of the actions would have had an effect, but because I had it in the hero zone the location wasn't centered and I didn't get the extra effects, so it wasn't obvious that that wait was still going off.

So I guess this can be locked now. Thanks for everyone's help.