I been wondering after I read a post here on running val thru a hotboot. that someone wrote a way to circumvent the player connection code so he could boot the mud from the debuged hotboot. I would love to have a fully persistent mud that would save everything in its state like when you hotboot. Could anyone point me in the right direction for this. Im not a great programmer but iv done such things as adding my own weather system and adding dynamic room description so im learning. Please any help on this subject would be very helpfull since our mud was originaly invisioned as fully persistent but we just couldnt pass up the great features of afkmud.

Uh.. I suppose you could change the code to dump info into the hotboot folder, but..

Firstly, why would you reboot in the first place?
Second off, any crash would mess this up for you, unless you were working with external
data files being consistantly written to, which would be maaaassively inefficient. :/

Hotboot wasn't really designed for use as a persistent world system. Most of what it does is out of convenience, and is a really poor method to use for much more than that. If you're looking to do that, you should plan out what you want to preserve and then plan a method for doing so, probably using some kind of database system.

Haha, yeah. However, taking this into account...



..it's just possible that he could figure out how to rig hotboot to shutdown and startup. Adding a new db system seems a little ..er.. heh. It'd be a several day project even for me >.>

Nobody said it couldn't be done, just that using hotboot type code for this isn't exactly the best way to go about it. I would much rather encourage someone to learn the "right" way to do this than to learn the hackish way.

Yeah, good point

Well at the moment I have to say I am using the hackish style for this. I have set it up so on startup it checks the hotbot dir if files are found it loads them. It also saves the files on shutdown and reboot just incase of accidents. For crash protection iv made a backup hotboot dir and when the world goes to file about every hour the old files are moved to the backup dir. I know this is not a real good way of doing this and since i will have to redo alot of the hotboot because of new things i want to save Im going to slowly work on a database system. I think i am going to try mysql but have also been looking at xml format for files. Will get back to you when i figure out exactly what im going to do. Just so you know Im working on a world simulation more than anything. A persistent world with a ecosystem. This is more of a experiment than a working mud. But if i can pull off even half of my ideas i would like to turn it into a running mud in a year or two. So thats why i dont mind taking the time to do it right. I wish i had others around me that could program I got the ideas but boy are they complex and my programming skills need work lol. But this is also
the other reason I love working on afk. Im learning as i go. If any of you have suggestions on a good database structure for this type of mud please feel free to yell it out. I'm currently looking at the SOI mud mysql code as examples( Well sorta )..

I'd also be be very interested in selective persistence via db structures, if anyone's got pointers on how to achieve this, specifically for say chests or player manufactured items, I'd be very interested in the info.

Thanks in advance

Edit: Nevermind this. It was an absurb idea that wouldn't work without 100 years of blood, sweat, and tears.

Edit2: But this looks fascinating: http://www.ossp.org/pkg/lib/mm/

Fascinating indeed, but personally I'm a little wary of what seems to be a fairly low-level solution. I think that for persistence to be sane, you'd need to manage game entities at a higher level than the memory structures. After all, the whole point of copyovers is to change code, which can mean changing data structures: a straight memory map probably wouldn't work (and might even cause crashes).

For the codebase I recently resumed development on (woot) I'm thinking that the best way to do this is to have self-describing storage formats, where fields fully specify their type, name, etc. -- then the loader can decide what to do with them.