Are there any statistics on the speed at wich units are moved from location to location when useing hyper triggers? i'm asking because i had to put a 6 millisecond wait in a trigger made to move scvs to a second location. the wait slows the scv down enought for a second regulator trigger to cetch it if the second location is full and move it to a third location. now the same regulation trigger WITHOUT the wait, dose the same but for meds and work without fail.. without the wait in the scv trigger. the scv passes through it's regulation triger before the trigger can cetch it.. again. are there any unit statistics on this with hyper triggers?

edit: i still want to know if there r stats on this but i moved the reg triggs above the rest and it works fine. but before that both med and scv triggs where right next to each other and about their reg triggs...

edit: edit: and can some point me in the right direction. useing creat unit with properties. (w/ Invince) i set scvs to 1 % hp and they appear 3/4 yellow and 1/4 red. i want them all red. and probes all yellow.

Post has been edited 1 time(s), last time on Jan 1 2008, 10:38 pm by shadow.wraith.

It's not about unit statistics nor is it about teleportation speed.

Its more about the properties of waits (hypers are waits too) and about trigger firing order.
It's bit hard to explain in detail but I will give you some important facts:

Whenever a wait is executed all triggers are checked again the next game tick. This is the reason why hypertriggers work.

With hyper triggers running triggers are checked every 83ms which is the speed of a game tick in starcraft. All calculations from triggers and their results are done within this period and are happening - for all intends and purposes - at the same time.

This is where trigger order comes into play. Triggers are checked by player (NOT primarily by the order in the trigger list!). That means first are ALL triggers by player 1 checked (in the order you see in P1's trigger list), then Player 2's and so on.
This also applies for forces and all players where the groups are split into the explicit players and then ordered into the trigger list of the respective player. This is done during runtime of the map when it is known which player slots are filled and which not.
So don't forget that when you mark multiple players in ScmD2 and see P2's first trigger on top of the list but still P1's triggers fire first in game. That's confusing, but that's the way it is.

Using the above information you should be able to fix the problem. But if you need more details on something, ask ahead.

However to give you a practical answer:
You must make sure that when you move a unit from A to B and then want to check (in the same triggerloop) if it has arrived (and do actions depending on the result) that the checking trigger is BELOW the teleportation trigger and under the SAME player or a player with a higher number.

Hope it answers your problem. If not pls restate what you are trying to do (and not what you did to achieve it).

Setting to 1% hp always results in the "reddest" wire frame possible.

However if you set some weird (low) hp values or even use the box beneath the hp you change the wire frame appearance which leads to varying results.
Set the SCV's max hp to 10+, don't use the box and create them with 1% hp and you should get the desired result.

Here you find more info on "weird" wire frames.

They are moved as soon as the trigger runs. If you want the moved units to affect future triggers (ie, brings), make sure the move trigger executes BEFORE the conditions that the unit will affect.

On a side note, a 6ms wait does not exist. All waits occur in the nearest interval of a trigger cycle. (83ms, was it?) There is no such thing as a 6ms wait.

Well, it stays the same up until 42, so 42 actually is the answer to the universe But every 42 milliseconds the actual time it waits changes.

Now, I think your main problem is Bring. It takes an additional trigger loop before Bring is updated, so if you move a unit from one location to another, then you have a conditon afterwords that it's in the second location, the game with still think it is in the first location until the next trigger loop, so what you really want to do is use Deaths, or switches so you instantly know when it was moved, and the game will still move it, even if it doesn't think it's there yet.