Hello again,

I having a really weird issue regarding 'wait.' I have several triggers that rely on 'wait', in order to determine unit respawn and such. However, I only have one major trigger that it is always running that uses wait: Adding 2 gas/second to the players. Now the issue lies in the fact that none of these 'wait' triggers occur when they are supposed to. For example, I have a zerg queen that should die in 5 game seconds (from wait), but ends up living for around 15 before it is finally killed.
Even if I set the wait to 0 seconds, it still takes forever to proceed. If I take the wait commands out, the triggers proceed just like they should. (not they way I want them too, (since endless gas was not really the idea) but the way one would expect.)

I understand that I may have to use Hyper-Triggers, and I am looking into the simple Hyper trigger example for use. The issue is that, even with the simple hyper trigger (3 of those condition always, wait 0 (63X)), the gas accumulation and unit kills still take a long time. How can I make it so that these wait times are exactly as I type them?

Thanks for any help you can provide, and if you need any more information, please let me know!

With Hyper triggers, you are limited to one wait per player. Constantly running a wait is not a good idea, you'll need to use death counters.
http://www.staredit.net/wiki/Death_Counters
They're basically like waits, but do not impede the map progress. They take a little longer to set up, but they are much more versatile.

Read up. It will tell you everything that is happening, why it is happening, and how to prevent it from happening.

Even without hyper triggers, you are still limited to one wait per player. If two triggers run which have waits, the waits are added together to a timer (IDK where the timer is) which counts down at a constant rate. It's common for war type maps to have a heal -> wait 60000, and a spawn -> wait 60000 trigger. If you spawn and heal, you can't heal or spawn for 120000 ms.

Alright, So I will use death count timers in place of the waits then. The one followup question I have is the following:

Suppose I initialize Player 7's terran marine Death Counter to have a certain of counters on it, let's say 100.
I then create another trigger that continually subtracts 1 from the death total, until the Death total is one.
Then A third trigger with the condition of "When Player 7's Marine Death total is one" activates and pulls off an effect, and then resets the Death countdown.

My question is: Without Hyper triggers, how many death counters are removed per second?
Also: Would Hyper Triggers be logical to use in an AOS style map?

One death count would be removed every two seconds without HT. With them, it's 11.8 DCs per second.

Hyper triggers are logical in EVERY map.

Alright.

Thanks for all of your help, Everyone!

Hyper triggers run every other frame, so long as the waits in hyper triggers are 0-42 ms. If you use 43 ms, hyper triggers will run every third frame. the number increases every 42 ms wait. Fastest runs at 24 frames per second.

If HT run every 2nd frame, and fastest has 24 fps, why do we get 11.8 HT/s instead of 12 HT/s?

Good question, and honestly, I don't know for certain, but I think it has something to do with the normal 2 second trigger intervals still running behind the hypertriggers.

How was 11.8 determined? Was a 10 second period started with create unit on each hyper trigger, with the final result being 118 (and not 120) units created?

I actually did the math on this with wavs and I got about 11.95 seconds. I had to approximate, of course. The way I did this, was with really long wavs. If I used a conversion factor of 12 seconds, I ended up with a slight overlap.

So to solve it, you set up your conversion factor resulting in a value of seconds as an integer (so you can use deathcounts to loop), make a wav exactly that length, and then loop it. If you hear an overlap, or gap, then your conversion factor is off. The longer the wav, the more accurate your guess as to the correct conversion factor is likely to be.

Or just use a stopwatch and make a "add 1 mineral for current player" trigger. Preserve, wait a while, then # minerals/time elapsed. voila.

24 frames per second isn't exact. 11.8 isn't really exact either. It's best to use "they run every 84 ms" than "11.8 times per second". The best way to know is to just manually guess/check.

Just use it in game seconds. SC runs at 16 frames per game second on fastest. It is, however, much easier to think of things in terms of 12 regarding mathematics.

Post has been edited 1 time(s), last time on Feb 17 2010, 4:22 am by Sacrieur.

Uh, I definitely think it is faster than 16. How do you know that? I would assume it is at least 25.

SC runs at 16 game seconds regardless of speed. When you use "at least 1 game second", that means 8 hyper triggers have passed. That number is exact. It's also important to note that normal is 15 fps, so no speed will ever be the same speed as game seconds (ie, a time on SC will never match up perfectly to real time).

Every 2nd frame the HT executes. A HT will run exactly 8 times in one game second. So by simple mathematics 2*8 = 16 frames.

Frames does not directly equal gameplay mechanics. It is a VERY bad idea to make both of those synchronized, and is frowned upon while programming games. You make the game processes independent from the framerate, to allow framerate fluctuation all the while maintaining constant mechanics and calculation processes. This is a bit limited though during extreme lag, which is why that timer shows up for dropping people.

This isn't some 3d shooter. This is starcraft. frames equal gameplay mechanics. Everything is linked through the framerate except wait. Certainly you're not suggesting we use wait for the mechanics?

This is an old single-threaded game that simply goes through basically a Sleep() between frames, that's how almost every old game works, they didn't multithread anything back then.

So what I got out of this is that the 24 FPS on Fastest is just an estimation, not an exact number. The most exact way is to simply remember that 84 milliseconds per trigger cycle on Fastest is how SC works(slightly slower on lesser speeds, due to slower normal trigger checking speed, not change in Wait times, because Waits are the same between speeds), which is mathematically 11.90476 frames per second.