[System] Smooth Timers

tain

New Member
Reaction score
0
Why would you use Timers anyway?

There are better way to do stuff now.

For Example:

Trigger:
  • Actions
    • General - While (Conditions) are true, do (Actions)
      • Conditions
        • GameRunning == true
      • Actions
        • Variable - Set Test = (Test + 1)
        • General - Wait 0.0 Game Time seconds
 

BlowingKush

I hit the blunt but the blunt hit me.
Reaction score
187
Why would you use Timers anyway?

There are better way to do stuff now.

For Example:

Trigger:
  • Actions
    • General - While (Conditions) are true, do (Actions)
      • Conditions
        • GameRunning == true
      • Actions
        • Variable - Set Test = (Test + 1)
        • General - Wait 0.0 Game Time seconds

and wheres the event that makes this code run???...
 

BlowingKush

I hit the blunt but the blunt hit me.
Reaction score
187
i would think a continously running trigger like that would use up all the processing time

ill check it out
 

Zwiebelchen

You can change this now in User CP.
Reaction score
60
i would think a continously running trigger like that would use up all the processing time

ill check it out
I doubt that. Its just a 0.03125 second wait and an integer count. I would even say that this is more efficient than any timer system ... well, but that only counts if it is really accurate.

Damn, someone really needs to test the waits in bnet!!
 

BlowingKush

I hit the blunt but the blunt hit me.
Reaction score
187
This.

And the reason you need timers can be seen in FirstPerson, where the thread must be stopped externally. I haven't seen a way to terminate a specific instance of a trigger, immediately...

You mean an 'interupt'?

though I thought an expiring timer just generated an event that was queued up with all the other events and it had to 'wait in line' for its turn to be processed and not interrupt driven

I was able to verify the 16 limit ok too.

I set up your example in order to try and get a 32 count but can not get the trigger to define
 

Attachments

  • TimerTest.zip
    30.2 KB · Views: 302

Zoxc

New Member
Reaction score
13
I see you're back at writing useless systems!

Here is some numbers for you:
The timers seems to get called 50-60ms then 4-8ms apart. When they're 4-8ms apart, SC2 prints the same time in the trigger debugger, so it's likely that no rendering is done between them. The time between your two initial triggers seems to be around 1.2 seconds.
 

Zwiebelchen

You can change this now in User CP.
Reaction score
60
I see you're back at writing useless systems!

Here is some numbers for you:
The timers seems to get called 50-60ms then 4-8ms apart. When they're 4-8ms apart, SC2 prints the same time in the trigger debugger, so it's likely that no rendering is done between them. The time between your two initial triggers seems to be around 1.2 seconds.
So basicly, that means: Screw timers, you won't have an accuracy advantage over waits anyways. :thdown:
At least, if waits are as accurate in Bnet as they are in Single Player.
 

Jesus4Lyf

Good Idea™
Reaction score
397
I see you're back at writing useless systems!
I'm not sure this statement is related to the rest of your post.
The timers seems to get called 50-60ms then 4-8ms apart. When they're 4-8ms apart, SC2 prints the same time in the trigger debugger, so it's likely that no rendering is done between them. The time between your two initial triggers seems to be around 1.2 seconds.
Unless Wait(0,gametime) gives exactly 0.03125 sec wait on b.net every time, then I appreciate your validation for a system like this - but as said, it may need some adjustment.

Indeed, the fact that it is complicated to do this sort of thing means that a system with this interface is what's required. The purpose behind releasing this was so that I could code using it, and update it later to fire exactly when it should. :thup:

>So basicly, that means: Screw timers, you won't have an accuracy advantage over waits anyways.
Screw timers anyway because you can't attach to them. But if 32 execs/sec cannot be achieved reliably with waits on b.net, then this actually validates a system like this perfectly.
>At least, if waits are as accurate in Bnet as they are in Single Player.
Correct.
 

Zwiebelchen

You can change this now in User CP.
Reaction score
60
>At least, if waits are as accurate in Bnet as they are in Single Player.
Correct.
Someone really needs to find that out ... can we host custom maps in bnet atm or will that be added in one of the next patches?
 

Zoxc

New Member
Reaction score
13
Wait(0) seems to take either 0 ms or 50-60 ms to execute. Wait(0.0625) seems to be more reliable with 50-60 ms.
 

Zwiebelchen

You can change this now in User CP.
Reaction score
60
It's almost like the Galaxy scripting language works entirely on 62.5 ms ticks.
To be honest, I always felt like this was the case for Warcraft III too. For example, the "GetCameraTargetX()" and all other camera natives like "PanCamera" were updated in constant intervals of 25 ms. If you instantly panned the Camera somewhere, you'd have to wait for "GetCameraTargetX()" to return a new value until you can pan again.

I think that intervals of 62.5 ms is sufficient for everything. I mean ... this equals 32 fps, which is exactly what you need to fool the human eye. Why would you ever need a faster interval?
It's just weird that - in case theres really this 62.5 ms interval between operations - timers do only use the doubled amount of that, whereas waits (In Single player ... at least) use the normal interval ... Wonder why they did that?

Maybe blizzard realized that they could create much faster reacting events like keypress in bnet, if they would 'synchronize' all operations. Would make sense to me, as I think the general Bnet data transfer interval is possibly also 62,5 ms ...
So possibly, we can expect extremely fast reacting keypress or button click events? You'll never know until the next patch.
 

Arkless

New Member
Reaction score
31
I did a bit of research...
The game runs on 32 updates per second (interval is 31.25 ms).
The minimum Wait time is 1 interval. Timers are updated every two intervals (if you check them in between, they will have the same time as their last updateinterval).

Units as well as EVERYTHING else follow this tickrate.
To archive that knowlege about units, do the following:
create about 1000 regions in a straight line which have a very small distance between the center.
Make a function execute every time a unit enters 1 of those Regions.
Add 2 integer variables, whenever the trigger executes you check if the unit position (I only used the x value) is already in the first variable.
If not, add 1 to the second variable. If it is, don't count this, as the unit didn't move at all.
While doing that let a timer run, do it for a long time so that the error is very small. Let's just say 10 second (I did it with some kind of loop for the runner and 100 seconds).
variable2/10 = tickrate = minimum interval between actions in the game (other than instantly :D)...
(btw. thats 0.03125 seconds)

edit: sry, I tested it yesterday evening and it seems like i missed a didgit (calculating with a calculator <.<)
32 ticks per second, tick = 0.03125 (makes more sense with timers updating every 0.0625 anyways)
 

Zwiebelchen

You can change this now in User CP.
Reaction score
60
Hmm, I suppose, if they changed the engine to base on "ticks" totally, I doubt that waits would work different in multiplayer. That means that timers would become obsolete (except when you need a timer window).

Of course, you can never be totally sure, as we all know blizzard always loves surprises and weirdness, but I am ALMOST sure that waits will work exactly the same in Bnet, now that we know that.

Would be awesome, as waits are much easier to use than any timer system could ever be.
 
General chit-chat
Help Users
  • No one is chatting at the moment.

      The Helper Discord

      Members online

      No members online now.

      Affiliates

      Hive Workshop NUON Dome World Editor Tutorials

      Network Sponsors

      Apex Steel Pipe - Buys and sells Steel Pipe.
      Top