> > > Setting default values is easily accomplished. Initialize them just > > > before the pfile is loaded. Then old pfiles are converted to new pfiles > > > the next time the user connects. > > > > It's a method that's very easy to have a program automatically upgrade if > > anything is added to the structure. This is exactly what I was talking > > about. And I think the 'waste' is overcome if the file's not necessarily > > a text file, but a binary file. > > > > If an entire player file were read in as a block and then parsed, the MUD > > wouldn't have to spend a lot of time chopping up a text file into > > separate pieces. > > Yep. I've been playing with merc 2.2 and circle 3bpl8. Whichever one I > eventually stick with, I plan on using a system like that. For right > now, though, the merc text files are a real convenience during > development. I s'pose I could throw a god-command in circle to text-save > a player in merc format when I want to look at a pfile. Guess I'll put > that on my big list of small projects ;) A system could be installed such that both formats are supported and a conversion process exists that could convert text to binary and back. Quite the project altogether. I've been meaning to look into saving world, object, mobile and zone files, on a similar topic. I've decided to build my own tertiary editor, in hopes of building something that's efficient for me. I'd like to have a number of editors installed for flexibility. The "rset" command is installed now; it recognizes "name", "desc" and "state" (state is inside, mountain, etc etc). Eventually it'll be writing to memory, and later I want it writing to the world files. Then objects are next. <grin>. It's going to be a long pull altogether, but it will be advantageous in the long run.
This archive was generated by hypermail 2b30 : 12/07/00 PST