Archived

This topic is now archived and is closed to further replies.

Please be aware that the content of this thread may be outdated and no longer applicable.

seronis

Curious about this code in lightningrod.lua, a bug?

Recommended Posts

seronis    130
local function setcharged(inst)   dozap(inst)   inst.AnimState:SetBloomEffectHandle( "shaders/anim.ksh" )   inst.Light:Enable(true)   inst.charged = true   inst.chargeleft = 3   inst:ListenForEvent( "daycomplete", function()      if inst.chargeleft then         dozap(inst)         inst.chargeleft = inst.chargeleft - 1         if inst.chargeleft <= 0 then            discharge(inst)         end      end   end, GetWorld())end

I have a couple personal mods im writing that would benifit from being able to react to a rod being struck by lightning (bringing things back to life nearby). Looking at the code here i noticed that every time the rod is struck, and thereafter calls 'setcharged', it adds an additional Listener for the daycomplete event. 

 

Doesnt this mean that if your game runs more than one or two rainy sessions without quitting the lightning rod will have multiple copies of this listener running? This appears it would make it lose charge faster than intended.

 

Shouldnt this listener only be added once and then not ever added again? There is no safeguard currently to prevent that.

Share this post


Link to post
Share on other sites
seronis    130

OK..  i was thinking someone would tell me  'seronis you're an idiot.  making a new listener replaces the old one'.  

 

Was pretty sure you could have multiple listeners per event type though. Thanks for clarifying that im not insane (about this)

Share this post


Link to post
Share on other sites
Mobbstar    13,515

I noticed that before too, but didn't give it more concern since it's unlikely for somebody to have enough lightning strikes at one lightning rod to significantly slow the game before ending the session.

With public DST servers, that may change... (assuming DST rods work with the same code)

 

On a side note, is it possible to remove a listener at the end of the listeners function? It wouldn't matter in this case, since you could do so in "discharge" too. In my experience a function call always pauses the script until the function has finished, so it shouldn't make any difference.

I haven't got the time to test this on my own. And once I have, I probably forgot about this too :p

Share this post


Link to post
Share on other sites
Heavenfall    184

On a side note, is it possible to remove a listener at the end of the listeners function? 

 

Yes, I've done this. Although in my case the listener function was not defined in the listenforevent, because it's much easier to remove the listener if you know the listener function's name. It would be interesting to see what happened if you defined the listener function inside the listenforevent, because you'd be removing the listener function while it was running itself.

Share this post


Link to post
Share on other sites
simplex    2,602

On a side note, is it possible to remove a listener at the end of the listeners function? It wouldn't matter in this case, since you could do so in "discharge" too. In my experience a function call always pauses the script until the function has finished, so it shouldn't make any difference.

I haven't got the time to test this on my own. And once I have, I probably forgot about this too :razz:

Yes. I implemented the following a long time ago, and U&A uses it in a fair number of places:

function ListenForEventOnce(inst, event, fn, source)	-- Currently, inst2 == source, but I don't want to make that assumption.	local function gn(inst2, data)		inst:RemoveEventCallback(event, gn, source)		return fn(inst2, data)	end		return inst:ListenForEvent(event, gn, source)end

Share this post


Link to post
Share on other sites