Timer Attachment Systems

[Romek]

Timers are looking as rubbish as usual (with very few additional actions that allow the modification of the timer window), and according to J4L, waits are still inaccurate. So, it would seem we need to use attaching again.

I tried doing the return bug, and got an 'implicit cast not allowed' error. There is an actual specific error for attempting such a thing now, which probably means that there's a very slim chance of ever getting such a thing.

Records (like structs) cannot be passed as parameters.
Regardless, indexing would probably work, so all that needs to be passed around is the index for arrays.

Now, how would we attach an integer to a timer?

 

[Jesus4Lyf]

I guess I'll rewrite T32.
I suppose allowing people to call something like T32_Add(trigger, int) and retrieve the int should do it...
Or better yet, T32_Add(trigger) returns an index to attach to.

 

[Cookiemaster]

Timers are looking as rubbish as usual (with very few additional actions that allow the modification of the timer window), and according to J4L, waits are still inaccurate. So, it would seem we need to use attaching again.

I tried doing the return bug, and got an 'implicit cast not allowed' error. There is an actual specific error for attempting such a thing now, which probably means that there's a very slim chance of ever getting such a thing.

Records (like structs) cannot be passed as parameters.
Regardless, indexing would probably work, so all that needs to be passed around is the index for arrays.

Now, how would we attach an integer to a timer?

Waits? Inaccurate?

:O?!!?

The following code:

Yields the following results:

How they get those decimals and why, I have no fucking clue.

But the waits seem accurate enough to be used in non-short-term cases.

 

[Jesus4Lyf]

No, I tried in Galaxy before the editor even came out. Off memory, waits round off to the nearest eighth of a second or something, which makes them utterly useless for things which must happen 32 times a second, like making a unit slide.

I have a neat design for a timer system which I'll complete tomorrow. I said I'd stay up 'til 4 am tonight, and I achieved that. -_-

I'm calling it SmoothTimer. It will do the whole 32/sec thing, with simple data attachment... :thup:

 

[Romek]

Done in a similar manner to Cookiemaster's tests, but using a different timer for every test, so the results are clearer.
I also used real time seconds.

Time - Actual Time Taken.

 

[BlowingKush]

Waits? Inaccurate?



How they get those decimals and why, I have no fucking clue.

But the waits seem accurate enough to be used in non-short-term cases.

I think the decimals are from the elapsed time that has occured during the time it takes to process the display line.

EDIT:

Wait if that wre the case the 1st result would be 6.995 or some bs not > 7 nm

 

[Jesus4Lyf]

Timers have been nerfed. They may no longer expire more than 16 times per second.
It's gonna take some haxx to get SmoothTimer to work.

... FOR THE MAPPERS!!...

 

[PurgeandFire]

Timers have been nerfed. They may no longer expire more than 16 times per second.
It's gonna take some haxx to get SmoothTimer to work.

... FOR THE MAPPERS!!...

Asdfjkgf. Damn. 0.0625 periods are ugly/choppy. Is it just for normal timers or trigger event timers as well? (Although, I'd assume they'd be the same) Are timers still more accurate than waits?

 

[Sevion]

Are you kidding me? Why the hell would they do that?

 

[Jesus4Lyf]

Fix'd.