Ok, so I obviously don't have to run a google search to know that there is 1000 milliseconds in a single second, but for some reason, Starcraft's time seems to be much longer then what I mark it as. (in triggers) If anyone else has a simlar problem, or a solution! Please share.
Thanks. Peace.

http://www.staredit.net/wiki/Wait_Blocks

I would think that you are running multiple waits for 1 player. This causes Wait blocks because every Player can only progress 1 wait at a time.

Sc waits can be entered in milliseconds but the actual time sc waits is rounded to 42ms increments.
E.g. wait(100) waits 84ms whereas wait(110) waits 126ms.
There's no way around it due to sc's engine which has fixed frame durations (unlike modern 3D shooters).

As a side note: Triggers, when using hyper triggers, are checked every 84ms (~12 times a second real time) on speed 7 and 8 times a game second (independent from speed, obviously). The numbers you enter in the wait() are always real time values. If game speed is lowered, less game time passes until the wait is over (e.g. a unit won't run as far in that time). Death counter timers can time only 84ms increments (half accuracy compared to waits) but they're always in synch with game speed.
This is important to keep in mind when you're making single player maps.

To add to what NudeRaider said, when StarCraft comes across a wait in a trigger, it stops reading that trigger then goes through all of the other triggers and then when its finished reading them, it continues reading the rest of the first trigger with the wait. This is why most map makers use Hyper Triggers. There a series of "Wait 0 ms" as the actions of a trigger with a preserve trigger after that. Its usually 62 waits, 1 preserver trigger and 1 comment. If you decide not to use a comment then just add another wait to the mix. The idea is to make these triggers run endlessly, so for the conditions of this Hyper Trigger, you would want to set it for "Always". This will ensure that no matter what, that trigger gets read and then processes other triggers then it goes back to read another wait which again, forces it to read other triggers first. This, like NudeRaider stated, dramatically lowers the time StarCraft reads the triggers, making things happen faster and more accurately.

For the accuracy part, say you have the conditions of a trigger set to "elapsed game time is exactly 3 game seconds". This trigger might not fire because of the time laps from when it was first checked. StarCraft could have checked it at 2 game seconds then again at 4 game seconds, thus the conditions were never met. If you use Hyper Triggers, the triggers would have been read 12 times per second thus that "Exact 3 game seconds" would have been read at its proper timing and then the actions would have been fired as normal.

All of the above is correct, just a clarification:
Hyper triggers make triggers check Triggers 8 times per game second. When using Elapsed scenario time or countdown timer game seconds are relevant, not real time seconds.

You should probably follow me around all of the time and clean up my mistakes when posting... <_<

Well thanks for all of the feedback guys, but hypertriggers I have always been skeptikal of. I remember when I used to play SC about 2/3 years ago I used and for some reason, although my memory has been long-lost to recreational drugs, I just remember bad experiences...or something to the sort of overtriggering. Although now I am much more experienced with Starcraft map making then I was then, I just am not too sure about it.

The only thing that I can say to try and prevent most mishaps with Hyper Triggers is to:

A) Make sure there only for 1 player. EX: no: forces, all players, current player, ect...
B) Make sure the player who owns the Hyper Triggers doesn't have another trigger containing a wait.
OPTIONAL
C) If Hyper Triggers fail you, you can always use Death Counters.

I keep reading about these Death Counters, I'm becoming highly interested. At risk of sounding like a noob, if you would elaborate on some basic functions that I could impliment using this process it would be highly appreciated. Thanks for the alternative idea. (My current map is all triggers, the only thing not created by triggers is the start locations. )

Deathcounter are basically the usage of death counts of units that do not die for the specific player ingame (e.g. mineral field type 1).
You can use it as an variable to count things, to have a status of progress or to store informations. You can use it as a timer, too. Then you just need to decrease 1 of the death count all the time.

Here's a tutorial on death counts that should explain them, they really expand your ability to make maps, without death counts, most of the seriously complex maps would not even be possible.

Accidently posted on wrong forum.
I sort of get the basis now, but what I honestly don't understand is how this way of timing is any more efficient then regular old Switches and Wait commands.
I mean, trust me, it's not in me to doubt someone who i come crying for answers to on a daily basis (hehe) but if you could just elaborate why this is better it would be appreciated.

Hyper triggers are an inexpressible beautify in maps. Without them your possibilities are narrowly limited.

The main disadvantage to them is that it makes recreational use of the wait action unrecommended as it will break up your map triggers and likely most of your systems. Unless of course you are using it to check all other triggers specifically before continuing.

Deaths on the other hand are almost just as beautiful, and can replace your waits with a little more work. Rather than try and explain them I'll give you a possible application for them.

Say you want to make a King of the Hill game and you wanted to know how many players have units in the "Hill" at any given moment.

[CONDITIONS]
*Player 1 brings at least 1 [men] to "Hill"
*Switch "Player1_unit_in_Hill" is cleared
[ACTIONS]
*Set "Player1_Unit_in_Hill" (Switch)
*Modify deaths for player 8: Add 1 for 'Contestant Counter'
*Preserve trigger


Deaths for player 8 is random, it doesn't really matter as long as it's consistent.
And conversely:

[CONDITIONS]
*Player 1 brings at exactly 0 [men] to "Hill"
*Switch "Player1_unit_in_Hill" is set
[ACTIONS]
*Clear "Player1_Unit_in_Hill" (Switch)
*Modify deaths for player 8: Subtract 1 for 'Contestant Counter'
*Preserve trigger


If we make these triggers for all the different players, than whatever amount of deaths "Contestant Counter" has is the number of people with units in the "Hill". This could come in handy for many different things, as well as possibly allowing you to easily inform the players the status of the Hill, contested, controlled or vacant. Otherwise you would have to write out a trigger for each of the different combinations of player status.

In the same playing field, you could ulitize death counters to make a nice "Gained the lead" system, to inform the players they whether they have gained or lost the lead.

If player 1 has the highest score of custom
And switch "HighestScorePlayer1" is cleared
-----------Then
Set "HighestScorePlayer1"
Preserve Trigger
(Do for all players playing)

Then for our non player computer player 8
Write a trigger for each player who might have the lead, I.E

"GaintheleadPlayer1" is cleared
"HighestScorePlayer1" is set
"HighestScorePlayer2" is cleared
"HighestScorePlayer3" is cleared
"HighestScorePlayer4" is cleared
---------Actions
Set Deaths for Player 8 of "New Lead Counter" to 1
Preserve Trigger

"GaintheleadPlayer2" is cleared
"HighestScorePlayer1" is cleared
"HighestScorePlayer2" is set
"HighestScorePlayer3" is cleared
"HighestScorePlayer4" is cleared
---------Actions
Set Deaths for Player 8 of "New Lead Counter" to 2
Preserve Trigger

ETC ETC.

Also for player 8 and after these triggers:
always
--------then
Clear "HighestScorePlayer1"
Clear "HighestScorePlayer2"
Clear"HighestScorePlayer3"
ETC. ETC.
Preserve

For each player:
Player 8 has suffered exactly 1 deaths of "New Lead Counter"
"GainedtheLeadPLayer1" is cleared
--------Then
Set "GainedtheLeadPlayer1"
Display "You gained the lead"
Play "Goodjobyou'reawesomeeveryonelovesyou.wav"

Player 8 has suffered exactly 2 deaths of "New Lead Counter"
"GainedtheLeadPLayer1" is set
--------Then
Display "You lost the lead"
Play "omgyou'reterrible.wav"
preserve


Wow seems like a lot of work for some dumb display crap but it's a nice effect for a clean map. Note that if people are tied for the lead they both have the greatest score, as this works around that whereas most careless conventional methods would be caught in a loop hole because of this.

The idea is the important part though, using a Death Counter where each number represents a possibility.

Death counters are also useful for things like steps in process. Like an option menu where the counter represents the stage or progression though, you've achieved.

Its like tiberium, the possibilities they're are endless! (Mobius)

I hope this is useful/understandable

Post has been edited 1 time(s), last time on Jun 17 2008, 3:55 pm by Kaias.

Death counts are useful in comparison to switches because you can 1) set for current player and 2) make it not just Set or Cleared.

The set for "current player" has obvious uses; if 6 players need to have their own death counts or switches, it would take 6 different triggers (set switch1, switch2, etc.) instead of just having a trigger for all of the players and doing "set for current player." This of course goes in hand with current player suffers x amount of deaths. Even if a system required just 30 triggers, that could be the difference between 30 and 180.

And like I said, the other difference is that switches are basically either 0 or 1, cleared or set. You can set death counts to extremely high numbers, allowing you to do "player suffers 14 deaths" instead of "switch 1 is set, switch 2 is set, switch 3 is cleared, switch 4 is cleared" binary stuff. My monopoly map right now probably has just as many switches as death counts, so they are definitely both valuable.. death counts, basically an excuse of where to store variables, just are capable of much more.

So if you could please give me a little piece of advise. I have a sort of 4/5 step initialization process for my map right now. In between pretty much each spawn (beacons/heroes/ect) I used a Wait 100ms trigger to sort of make it easier on people online, but from what I'm getting out of this lesson, I'm pretty much better off having all of my map loading at once? If you wouldn't mind I'd like to show you the map via USEast, please respond. :-\

[not important now]

Post has been edited 1 time(s), last time on Jun 17 2008, 7:06 pm by Kaias.

can u paste a link on a tutorial of hyper triggers too?

Why don't you look into the wiki yourself next time?