[Solved] Handle Id Recycling

[AGD]

From what I understand when I do

local timer t = CreateTimer()
call DestroyTimer(t)

t still points to the handleid of the destroyed timer so I need to set t = null so that the handleid of the destroyed timer will be recycled.
But when i do

local timer t = CreateTimer()
call DestroyTimer(t)
call BJDebugMsg(I2S(GetHandleId(t)))
set t = null

set t = CreateTimer()
call BJDebugMsg(I2S(GetHandleId(t))) // not the same as before

it seems that the handleid of the previous t was not recycled by the new t.

Question:

• How can I make it so that the new t will be using the handleid of the last destroyed t?
• Is there some delay in the handleid recycling?

 

[Dr Super Good]

Is there some delay in the handleid recycling?

There is a delay, I forget if it is per frame or at thread termination.

Run the function again and again, eg in response to pressing Esc, and you will notice that the same Handle Ids are used.

 

[AGD]

There is a delay, I forget if it is per frame or at thread termination.

Run the function again and again, eg in response to pressing Esc, and you will notice that the same Handle Ids are used.

I did a test and it seems that the delay is by fps and not by thread termination.
So if someone can benchmark this it would be nice =). I can't do benchmarking in my PC =(.

 

[Wietlol]

Use a stack.

Instead of destroying the timer, you store it in an array of timers.
Then when you want to create a new timer, you can load the last one out of the array and reduce the array size.
That way, it will be the same handle.

 

[AGD]

im actually doing something like that. What i need to do is to detect when a timer from the stock is destroyed by hooking DestroyTimer and then replace it with a new one. But i need it to have the same handleid as the destroyed timer because i have function that gets the index of a timer by this formula GetHandleId(timer) - START_HANDLE

 

[Pyrogasm]

It's pretty old but it was updated for 1.24b so you could use Vexorian's TimerUtils. You can attach an integer to them (effectively a struct, which then is any data you want by extension) so instead of making sure they have the same handle id do this:

local timer T = NewTimer()
integer data = GetHandleId(T) //if T should be a 'new' timer
integer data = OldHandleIdHoweverYouGetIt //if you want it to 'be' an old timer

call SetTimerData(T, data)

 

[Wietlol]

Why do you want to hook DestroyTimer() instead of replacing the function with your own call?

 

[AGD]

Why do you want to hook DestroyTimer() instead of replacing the function with your own call?

I want to do a safety precaution in case one timer belonging to the stock is accidentally destroyed. Although it might not be practical because as what you said I can just use my own function instead of DestroyTimer() since it is used only by my own map but I want my systems, even personal ones, to act as though it is for public use. =)

 

[Wietlol]

You then need to restrict access to the handles.

I use a Timer struct which has a private timer array.
You cant double destroy one struct (or at least it wont have any effect in my case) so you cant add it to the stack twice.
This is one of the problems that TimerUtils for example has (it does have a safety check, but you still got access to the actual handle).

 

[AGD]

You then need to restrict access to the handles.

Hmm is that even possible? Because I have a function that returns the timer.

 

[Wietlol]

Dont have a function that returns the timer.

 

[AGD]

Dont have a function that returns the timer.

Okay, so I have to remake the system a bit =). Thanks.

EDIT:
I was able to retain the system design, I'm now able to replace the timer with a new timer with the same handleid as the destroyed timer

 

[AGD]

Btw, it seems that the delay of handeid recycling is about 0.0050000. I emphasized the trailing zeroes because it seems that 0.005 does not mean the same as the previous although it should be, weird.

 

[Dr Super Good]

Btw, it seems that the delay of handeid recycling is about
0.0050000
. I emphasized the trailing zeroes because it seems that
0.005
does not mean the same as the previous although it should be, weird.

Single precision floating point rounding error. If you compare the two values bitwise you will notice some difference.

The way it is close to 200 times a second would make it seem to have something to do with in game update periods.