Jump to content

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


seronis

Recommended Posts

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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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.

×
  • Create New...