I just have a quick question and a problem that really isn't a problem but very annoying.
I have a skill that apply a behavior for 5 seconds and want to make a custom ui (dialog) of it so I put a variable to 5 (real) and every 0.1 gametime I substract the number 0.1 to make a image become smaller and smaller until it reaches 0. However as I do this the behaivor will wear off exactly 25 % faster than the variable reaches 0. With behaivor 5 sec it will wear off when the variable is 1 sec and at 10 sec behaivor it will wear off when the variable number reaches 2. I have normal game time locked as game variant and in a trigger in the trigger editor.
My problem thus lies within the graphics and not the actual game mechanics (I simply have a larger number than 0 and a longer image than 0 when the behaivor runs out). Why it aint a real problem is because I can just put the number that substracts each 0.1 sec to 0.125 (25 % more) and it will look alright but I would like to know why this is happening).
Can anybody explain this? I have looked at how game speed affect the game but it seems unlikly as for it to be possible the game speed and dialog ui update speed must then be 2 different timelines (which it shouldn't be). I also timed a skill that should be 10 sec cooldown but in real time it had approx 13 (prob 12.5 sec).
That's because Starcraft works with game ticks. A game tick is 1/32th of a second. But for some reason the Wait system skips every second game tick, turning it into 16 ticks per second instead of 32.
The Wait command actually will not wait exactly 0.1 seconds if you ask it to, but it can only wait a number of game ticks, thus it's a multiple of 16.
So when you want it to wait for 0.1 it'll round the number up to the next multiple of 16, which is 0.125 (2/16th).
Because of this you're actually waiting 0.125 seconds but subtract 0.1 from your variable, which results in an exactly 25% longer total wait time.
And that is also why it worked so well with 0.125 wait instead - this is exactly one game tick. No inaccuracies there. That's also the only way to "fix" this, you have to use multiples of 16 everywhere you need accuracy.
I just have a quick question and a problem that really isn't a problem but very annoying.
I have a skill that apply a behavior for 5 seconds and want to make a custom ui (dialog) of it so I put a variable to 5 (real) and every 0.1 gametime I substract the number 0.1 to make a image become smaller and smaller until it reaches 0. However as I do this the behaivor will wear off exactly 25 % faster than the variable reaches 0. With behaivor 5 sec it will wear off when the variable is 1 sec and at 10 sec behaivor it will wear off when the variable number reaches 2. I have normal game time locked as game variant and in a trigger in the trigger editor.
My problem thus lies within the graphics and not the actual game mechanics (I simply have a larger number than 0 and a longer image than 0 when the behaivor runs out). Why it aint a real problem is because I can just put the number that substracts each 0.1 sec to 0.125 (25 % more) and it will look alright but I would like to know why this is happening).
Can anybody explain this? I have looked at how game speed affect the game but it seems unlikly as for it to be possible the game speed and dialog ui update speed must then be 2 different timelines (which it shouldn't be). I also timed a skill that should be 10 sec cooldown but in real time it had approx 13 (prob 12.5 sec).
That's because Starcraft works with game ticks. A game tick is 1/32th of a second. But for some reason the Wait system skips every second game tick, turning it into 16 ticks per second instead of 32.
The Wait command actually will not wait exactly 0.1 seconds if you ask it to, but it can only wait a number of game ticks, thus it's a multiple of 16.
So when you want it to wait for 0.1 it'll round the number up to the next multiple of 16, which is 0.125 (2/16th).
Because of this you're actually waiting 0.125 seconds but subtract 0.1 from your variable, which results in an exactly 25% longer total wait time.
And that is also why it worked so well with 0.125 wait instead - this is exactly one game tick. No inaccuracies there. That's also the only way to "fix" this, you have to use multiples of 16 everywhere you need accuracy.
Oki Thanks s3rius for the answer. Even though I think that is retarded I guess I have to live with it.