I figured those first 4 would be easy like that.
Take your time on the hard ones, I'm in no rush. As I said I don't mind figuring it out for myself, but if you have the time that's fantastic. I was more interested if a) can it be done at the db level at all, and b) what is the scope of the work.
For example, I assume some of these may be easier to do at the code level than at the db level. For example, when a mob is killed, I was thinking I could add a new "deadmob" table or similar, and populate it when the mob is toast, and then a back-end sproc can run at the end of each session to roll through the killed mobs and remove them from the db to prevent future spawns. Alternatively, the server code could immediately delete the named mob. But the problem with this is it changes the server code which I'd like to avoid if possible.
Or better yet, if enough info is aleady in the log files to do this, a simple program to parse the log files and then remove the items from the database could be another (perhps better) solution. This of course assumes that the log entires are rich enough to implement my necessary rules as defined. If the NPC ID is in the logs as well as it's name and zone name or ID I could quite easily write a program to do this in a few hours. I'd just have to hardcode zone names or ID's to a list of dungeon vs. non-dungeon zone, which is no big deal maintenance wise as the zone list isn't changing often.
I actually like this approach better as there may be rare occasions where I don't want to get rid of ALL of a dungeons mobs even if it was completely cleared out. I may want the named to go, but I may want to keep a few unnamed stragglers behind. Just enough to be annoying and act almost as "random" encounters, especially in those dungeon zones which act as a connection for multiple zones (BlackBurrow, RunnyEye, etc.). By using the log parsing approach, what I could do is write a program which simply generates SQL statements from the logs (if the logs are XML this could actually be triivial as a XSLT could perhaps do it). Then I can pare down the SQL by hand before executing it. In fact, in theory I could even be in the dungeon zone as GM, repop, delete a few, repop again, and see the changes on the fly. If the tool writes to stdout, it could still be used in an automated fashion for cases where I want everything wiped that was killed with no exceptions.
- Rhino