Windowlist / Character delete events

[phantomwhale]

Been looking at the code for a while, and trying to work out the best way of tracking character delete events ?

Initially I was trying to pick up on the "Delete Item" menu selection in the character selection list. But then I notice that database nodes have an onDelete () event to plug into.

Perfect I thought - but I'm having trouble working out where is the best place to link into this method, as these objects get created by the inbuilt windowlist functions.

Maybe I'm just tired - it's certainly late - but any pointers would be welcomed right now !

[Moon Wizard]

The database is actually independent of the windows in FG. They are just linked together to make everything work.

Your best bet for a global capture of node deletion is to create a global script with an onInit function that links itself to the charsheet database node. You will need to add an onDelete handler to any child node of the charsheet database node, as well as adding an onChildAdded handler to the charsheet database node so that you can add the onDelete handler for any new characters added during the session.

Cheers,
JPG

[phantomwhale]

Took another look at this in the cold light of morning.

One approach I looked into was adding a script to the charsheet windows class, like so :



<script>
function onInit()
getDatabaseNode().onDelete = MyCustomLib.characterDeleted;
end
</script>


This worked for my purposes... but only because of the type of processing I was interesting in would only be important if a player had already taken control of the character - which can only be done by opening a player session and double-clicking the identity entry in the PC selection window, which then open's the main character sheet, triggering the above script's onInit method.

In short, it worked, but felt like bad programming.

The second approach was to add an onInit method to my custom lib (as you suggested), as follows :



function onInit()
if User.isHost() then
local charsheetNode = DB.createNode("charsheet");
for key, charNode in pairs(charsheetNode.getChildren()) do
registerCharacter(charsheetNode, charNode);
end
charsheetNode.onChildAdded = registerCharacter;
end
end

function registerCharacter(charsheetNode, charNode)
charNode.onDelete = characterDeleted;
end


This works, from the basis that it only runs of the host machine (often get caught out with DB functions running on multiple clients !), registers with the charsheet node for new characters, and equally registers existing characters on startup.

Now I've written it, this seems much better then how it was in my head last night (when I was struggling to work out how to register these child nodes - onChildAdded handler was exactly what I was missing).

I always feel a little funny constantly calling DB.createNode(), rather than findNode(), maybe because it's less clear which chunk of code is responsible for actually creating this node. But in this case, on a brand new campaign, it's not created yet so my custom lib actually has to create it. This was probably what was putting me off taking this approach, and got me trying to hook in the window events, but I think I'm happier with approach 2.

Always nice to examine the different approaches though - think I can get a bit too obsessed with best practice though. Comments and follows ups to the above approaches / other approaches welcomed. Otherwise thanks JPG, I'm back on track this morning with my extension.

Ben

[StuartW]

You might want to take a look at charlist.lua, which monitors connections and removals in order to display the list of portraits at the top-left of the FG screen. It already captures a number of the events, so you might be able to get away with adding a check into existing code rather than replicating it.

It would work for changes to active (logged-on) characters, but wouldn't catch deletions of inactive characters.

Stuart

[phantomwhale]

You might want to take a look at charlist.lua, which monitors connections and removals in order to display the list of portraits at the top-left of the FG screen. It already captures a number of the events, so you might be able to get away with adding a check into existing code rather than replicating it.

It would work for changes to active (logged-on) characters, but wouldn't catch deletions of inactive characters.


I've overwritten some bits of that in my extension to capture user logins and register DB handlers for them to update some extra parts of the database node hierarchy I've introduced.

Did look around a bit further, but like you mentioned, it appears to mainly override identity activation events, and looking over the refdocs, I could not see anything specific to deletion of identities. So I focused on capturing the underlying database node deletion instead.