To Destroy or Not to Destroy

[Technomancer]

Here's the code, moves my flying frog or whatever to wherever:

function Projectile_Move takes nothing returns nothing
    local timer t = GetExpiredTimer()
    local string s = GetAttachmentTable(t)
    local trigger trig
    local string strig
    local real ang = GetTableReal(s, "ang")
    local unit u = GetTableUnit(s, "u")    
    if (u == null) then
         PauseTimer(t) //DestroyTimer(t) ????
    else
        call SetUnitPosition(u, GetUnitX(u) + 30 * Cos(ang * bj_DEGTORAD), GetUnitY(u) + 30 * Sin(ang * bj_DEGTORAD) )
    endif
endfunction

Normally it'd be obvious to destroy this timer but it's attached to another object in a table elsewhere, however, I know I'll NEVER be using this particular timer again, so how should I go about destroying the leak? I don't want a leak every time someone fires a projectile, especially if I'm trying to make a projectile based map.

Also I just wanted to check my syntax; the unit destroys itself on contact with an enemy, so if I call up the unit later and it's gone, I'll get a null pointer correct? (I just pulled that out of my ass)

 

[Sim]

Well first of all you should null your handle variables.

> Normally it'd be obvious to destroy this timer but it's attached to another object in a table elsewhere, however, I know I'll NEVER be using this particular timer again, so how should I go about destroying it?

Is the pause considered the "end" of the timer? Will it ever be resumed?

If it is re-used somehow somewhere, then don't destroy it.

> so if I call up the unit later and it's gone, I'll get a null pointer correct?

Dead units are still considered units and can be referred to, but not permanently. At some point they completely vanish, I believe it is when the corpse is fully decayed.

 

[Doom-Angel]

what's the point of pausing the timer when it expires?
it's not gonna move anywhere below 0....

 

[Sim]

Pausing a timer is recommended before destroying.

Though the timer never gets destroyed...

 

[Cohadar]

what's the point of pausing the timer when it expires?
it's not gonna move anywhere below 0....

It is if it is periodic and you want to stop it.

Pausing a timer is recommended before destroying.

Destroying timers is not recommended

 

[Doom-Angel]

It is if it is periodic and you want to stop it.

oh right i haven't thought about that option

 

[Technomancer]

Found an easier fix using Vexorian's Caster System and CSCache for anyone interested who doesn't already know:

NewTimer()
and ReleaseTimer()

both explained at the top of the CSSafety readme

 

[TheDamien]

Flush the attachment? Anyway, it is generally accepted that timer recycling is much better than constantly creating and destroying timers.

 

[N-a-z-g-u-l]

NewTimer and ReleaseTimer are slower than normal timers

A timer for each projectile is too much and will make the map lagg

Dont use the game-cache when you need much speed, which is the case here

Instead use a global array of units, parallel arrays with their properties and one timer, calling a loop for all units in that array

but if you dont want to change that things, destroying would be the right way...

 

[Cohadar]

NewTimer and ReleaseTimer are slower than normal timers

No they are not.

 

[N-a-z-g-u-l]

seems like i mixed something up... at least the timers which are no timers, so just a simulation of one, which was done by vexorian, too, is slower... this one may create new timers whenever needed and save the old ones into a global stack to reuse them... yes, that could be faster sorry

oh, btw, does anyone have a link or good explanation for why timers are "bad"... to create and destroy and so on, only when i null them? so i can avoid it with never saving the timer into a local variable?

 

[SFilip]

You don't need to null timers if you use CSSafety. That's kind of the whole point.

 

[phyrex1an]

oh, btw, does anyone have a link or good explanation for why timers are "bad"... to create and destroy and so on, only when i null them? so i can avoid it with never saving the timer into a local variable?

Timer + H2I + null = very strange, rare, evil bugs. Maybe you have seen those spells where the projectile freezes in the air every 300 cast or so?

 

[Andrewgosu]

Maybe you have seen those spells where the projectile freezes in the air every 300 cast or so?

No, I haven't.

Can someone "recreate" one of them?

 

[emjlr3]

You don't need to null timers if you use CSSafety. That's kind of the whole point.

i thought the whole point was now it is safe to do so, not nulling the local timer still leaks, and so using the stack, you nver destroy the timers...or something.....anyhow, I null mine, and get no issues

Timer + H2I + null = very strange, rare, evil bugs. Maybe you have seen those spells where the projectile freezes in the air every 300 cast or so?

i have numerous times in the past, though the issue was not so much with my code, but with what the optimizer did with it with certain options on
then my shit would bug out

 

[SFilip]

> not nulling the local timer still leaks
It doesn't.
You only need to null variables that contain something that will be destroyed.
Player, for example, won't. No need to null that.
Timers from CSSafety are never destroyed, they are just being stacked up for later use. Thus you don't need to null them.

 

[Cohadar]

I confirm what SFilip said. CSSafety pwnz.

 

[N-a-z-g-u-l]

werent there some errors, too, when the timer wasnt stored in a variable anywhere? and then H2I() could return another id? well, then CSSafety wouldnt be 100% safe either...

 

[Cohadar]

*sigh*

That cannot happen because CSSafety stores timers in an array.

And it was I2H() that caused errors.

And if I see you use I2H() I will bash you to death.

 

[Doom-Angel]

I will bash you to death.

lol beware he got one hack of a bash