Reaganomicon wrote:It's hacky, but deconstruction is done by calling p_deleteUnmovableObject, so you could modify it make a note of who was in the area before actually going through with the deletion. You'll probably need baron.cs if you want accurate realtime positions, though.
I've done this on my server. It's not perfect but it works. Basically I added two functions (
f_baron_deleted_umovable and
f_baron_deleted_movable) which are then called in the
f_deleteUnmovableObject and
f_deleteMovableObject procedures. If you only care about unmovable objects (buildings) you can obviously discard the movableObject bits.
This grabs the object type and the current time and adds a new record to
baron_deletelog. This gives me all of the deletion events that have occurred, like so:
It then grabs all the current players (via baron.cs) in the
baron_players table and stores them with a reference to the log (deletion) event in
baron_deletelog_players. Which I can then look at to see who was playing at the time the object was deleted. Then I can just do a simple distance calculation to see who was closest to the object that was deleted, and they'll pretty much always be the culprit. I don't do the distance calculations in SQL though, as I have my own utility for that. But I'm sure someone can add that functionality to the SQL procedures. It'd probably be better that way as then you can store only the closest player and save some storage space.
You can download and run the SQL file to generate these procedures/tables at
http://pastebin.com/J8nmhHMD. You will also need to modify
p_deleteMovableObject and
p_deleteUnmovableObject procedures to look like this:
http://pastebin.com/91YSPs58. Note the 'CALL' statement before the transaction.
You will also need baron.cs, so follow the instructions here:
http://lifeisfeudal.com/forum/lif-baron-script-get-all-currently-active-players-t3364/Not the greatest way to do this, but it works--and it should suffice until the developers add better logging features.