Dachannien
June 11th, 2007, 22:52
I've had a couple of cases where, after a few hours of play with lots of FG objects open (personality sheets, maps, tokens, etc.), the system will start to slow down as if there's some sort of resource leak (i.e., handles or memory), eventually resulting in a catastrophic power-cycle-needed crash. (That is, FG crashes, but even after that, the machine acts screwy until it is rebooted, even with FG no longer running.)
While this obviously needs to be resolved, I'd like to suggest that FG handle crashes better. When FG saves a campaign, it needs to do two things: one, make a backup copy of (or rename) the old db.xml and campaignregistry.lua files before saving out the most recent data, and two, flush the buffers (or, better yet, close the files) on the most recent data so that we can manually copy those files if needed.
Sometimes the actual crash happens when FG is closing, which results in the corruption of those data files. I've lost hours worth of work on multiple occasions due to this, as well as combat tracker entries from the middle of heated combat. Shouldn't be that hard to implement, either, since it's just file manipulation - probably much easier than tracking down the crash bug itself ;)
While this obviously needs to be resolved, I'd like to suggest that FG handle crashes better. When FG saves a campaign, it needs to do two things: one, make a backup copy of (or rename) the old db.xml and campaignregistry.lua files before saving out the most recent data, and two, flush the buffers (or, better yet, close the files) on the most recent data so that we can manually copy those files if needed.
Sometimes the actual crash happens when FG is closing, which results in the corruption of those data files. I've lost hours worth of work on multiple occasions due to this, as well as combat tracker entries from the middle of heated combat. Shouldn't be that hard to implement, either, since it's just file manipulation - probably much easier than tracking down the crash bug itself ;)