Timers module

[Y_Less]

This is a sneak-peek at one of the improved modules we've done, for timers in open.mp:

PHP Code:

native SetTimer(const func[], msInterval, bool:repeat) = SetTimerEx;
native SetTimerEx(const func[], msInterval, bool:repeat, const params[], GLOBAL_TAG_TYPES:...);
native KillTimer(timer) = Timer_Kill;

// CreateTimer
native Timer:Timer_Create(const func[], usDelay, usInterval, repeatCount, const params[] = "", GLOBAL_TAG_TYPES:...);

// KillTimer
native bool:Timer_Kill(Timer:timer);

// Return time till next call.
native Timer_GetTimeRemaining(Timer:timer);

// Get number of calls left to make (0 for unlimited).
native Timer_GetCallsRemaining(Timer:timer);

// Get `repeatCount` parameter.
native Timer_GetTotalCalls(Timer:timer);

// ?Get `usInterval` parameter.
native Timer_GetInterval(Timer:timer);

// Reset time remaining till next call to `usInterval`.
native bool:Timer_Restart(Timer:timer); 


The first two are just for backwards-compatibility, the rest are the improved API:

PHP Code:

native Timer:Timer_Create(const func[], usDelay, usInterval, repeatCount, const params[] = "", GLOBAL_TAG_TYPES:...); 


• `func` - Fairly obvious; what to call.
  
• `usDelay` - Again obvious, the delay before the call (in microseconds).
  
• `usInterval` - What to reset `usDelay` to after the first call. ?So if you wanted a timer on the hour every hour, but it was 8:47am right now, the call would be `Timer_Create("OnTheHour", 780 SECONDS, 3600 SECONDS, 0);`
  
• `repeatCount` - Unlike the old functions, which are just "once" or "forever", this instead takes the number of times to call the function. ?"once" would be `1`, `500` would stop after 500 calls, and (backwards from the old API) `0` means "forever".
  
• `GLOBAL_TAG_TYPES` - Like `{Float, ...}`, but with more tags.
  

[JustMichael]

It's so pretty uwu



I definitely prefer this over how timers are handled in SA-MP. Even the little things can make a big difference.

[Freeze]

Very good!

I'm looking forward to what's coming soon

[Afisiado]

Finally, decent functions with timers!

[CRHStudios]

Pretty good features and improvements with the timers.

[2PAC_]

Very nice, good job!

[Max_Andolini]

This is great!!!

[Verc]

What a great news!

[Koplan]

Good Job!

[Hawkins]

Continue in the same spirit

[Manyula]

Absolutely love the new API, great job! Not really a fan of the prefixing of the functions, though. Is that scheme gonna be applied to all of the new API?

[BigETI]

Think it having two names: The prefix is the library or module the function is from and the suffix is the actual function name. The underscore just seperates both names.

[JustMichael]

Think it having two names: The prefix is the library or module the function is from and the suffix is the actual function name. The underscore just seperates both names.

Well said, sir. Have a box?of cookies :)

I do prefer this to how SA-MP does it, and I wouldn't want to have mixed casing.

[Manyula]

I understand that the prefix is there to be able to quickly identify the module it belongs to, but imho I don't think that's necessary. But then again, I think this comes down to personal taste.



One more thing: I think some of the timer functions lack a certain consistency in terms of naming.

Code:

native Timer_Get[b]Time[/b][i]Remaining[/i](Timer:timer);

native Timer_Get[b]Calls[/b][i]Remaining[/i](Timer:timer);

should be...

Code:

native Timer_Get[i]Remaining[/i][b]Time[/b](Timer:timer);

native Timer_Get[i]Remaining[/i][b]Calls[/b](Timer:timer);

to be in line with...

Code:

native Timer_GetTotalCalls(Timer:timer);

as the latter sounds more natural.

[BigETI]

The naming of the functions is more a convention we are going to use rather than personal taste. (I personally don't like it)

[NexoR]

Good job.

[Y_Less]

I understand that the prefix is there to be able to quickly identify the module it belongs to, but imho I don't think that's necessary. But then again, I think this comes down to personal taste.



One more thing: I think some of the timer functions lack a certain consistency in terms of naming.

Code:

native Timer_Get[b]Time[/b][i]Remaining[/i](Timer:timer);

native Timer_Get[b]Calls[/b][i]Remaining[/i](Timer:timer);

should be...

Code:

native Timer_Get[i]Remaining[/i][b]Time[/b](Timer:timer);

native Timer_Get[i]Remaining[/i][b]Calls[/b](Timer:timer);

to be in line with...

Code:

native Timer_GetTotalCalls(Timer:timer);

as the latter sounds more natural.

You're right about the mixed verb/noun order, I'll fix that.



As for module prefixes, that's now quite well established. It gives a nice consistent naming scheme, and there's a longer-term goal you'll have to wait for to see...

[Gravityfalls]

Amazing.

[Riddick]

This seems to be all right. Is it PAWN limitation or bad SA-MP's SetTimer(Ex) functions coding that we are not allowed to pass strings in it? (or we are but it didn't work correctly - I can't remember now).



---

I still wish here for "IsValidTimer" function. I know that IDs could be assigned to a new timer where the other timer has finished its job and it doesn't guarantee that the timer in a give slot is still the same, but some internal IDs should be assigned once maybe? I guess maybe use versioned timer IDs?



Unless you are not going for it.

[Y_Less]

It's a bug in the native, not a pawn limitation.

[Expert*]

I use module prefixes for fixed/protected/new functions so i love it. What i don't love is extra work to ensure compatibility.



global func: Player_SetSkin

static func: player_setskin

call: PLAYER_RequestSpawn

[Y_Less]

I'm not sure what that last line is.

[Expert*]

Callback, starts with uppercase letters ( PLAYER_, VEHICLE_ ) ex: PLAYER_EnterVehicle.

[Y_Less]

Callbacks start with "On".

[Expert*]

*that's how i prefer to name my callbacks*

I started to name them like this because "OnPlayerLogin" was taken by y_users.

[Roth]

Incredible, very good job.

[BoNNe]

great job

[TroyST]

Well done wise man!

[Sasino97]

I hope?this one to?work when passing strings as parameters, lol.

Think it having two names: The prefix is the library or module the function is from and the suffix is the actual function name. The underscore just seperates both names.

That is how it should be :D

Then I will

Code:

#define Timer. Timer_



Timer.Create(...);

and pretend to be using some high level OO programming language, like I always do.

[Markski]

This is really good. Just some days ago I was considering making an include (based on samp-precise-timers) for functions to have a limited loop lifetime without needing to have such logic to kill the timer on each public. Glad to see this is being done for the OG native.

[[SF]kAn3]

So should I stop using y_timers?

[2KY]

Very nice improvements to the code. Thanks!

[EvilShadeZ]

I think this module is missing Timer_SetCallsRemaining(Timer:timer,calls);

This would be very useful for adjusting how many calls are left. Useful for shortening / extending repeating timers.



Absolutely loving timers in microseconds. How accurate are they compared to SA-MP timers?