[System] Smooth Timers

[Jesus4Lyf]

Fair enough.

But I never used H2I or GetHandleId for ages. :thup:

I was the guy whose resources didn't break when the return bug patches happened.

 

[tain]

Why would you use Timers anyway?

There are better way to do stuff now.

For Example:

• 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]

Why would you use Timers anyway?

There are better way to do stuff now.

For Example:

• 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???...

 

[tain]

Um, Run trigger maybe lol?

Here, if you wanna see it live, check out this map: http://www.thehelper.net/forums/showpost.php?p=1231869&postcount=3

 

[Zwiebelchen]

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

Have you confirmed that working accurate in bnet? I mean, is the interval really always 1/32 seconds or has it a certain inaccuracy like the old TSA?

 

[BlowingKush]

i would think a continously running trigger like that would use up all the processing time

ill check it out

 

[Zwiebelchen]

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!!

 

[Jesus4Lyf]

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

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...

 

[BlowingKush]

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

 

[Zoxc]

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]

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]

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]

>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?

 

[sqrage]

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?

Publishing = Next patch.

 

[Zoxc]

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.

 

[Jesus4Lyf]

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.

Is it possible to actually execute anything 31 ms apart?
It's almost like the Galaxy scripting language works entirely on 62.5 ms ticks.

 

[Zwiebelchen]

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]

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 )...
(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)

 

[Jesus4Lyf]

Cool, next time I'm mapping I guess I'll switch this over to use a wait loop internally - at least for now. Seems it will be better than timers. Will have to wait for b.net patch to see if this stays true.

 

[Zwiebelchen]

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.