> > > With versioning, you can see that the version is lesser than the
> > > current, so you don't try to scanf with an incorrect format, you
> > > add in default values to the struct, and let the MUD
> > > integrate default values, write it back out in the new version, and you
> > > never have to hand edit your area files.
>
>
> The way I plan on doing it is this:
>
> * code new fields in the save, etc., functions.
> * increment version #
> * change the load function to read in the old version if the version is one
> less than the current, then save it right away, bringing it up to the new
> version.
> * at leisure, change the load functions to only read the current version.
>
> This way I only really need to do one reboot/copyover, not two, and I don't
> have to write something to save all zones, and I don't have to do it manually.
Actually, this is pretty trivial. Works best with binary files
where version information is actually important; binary files being loaded
up based on struct size usually. Just pop an int into the first bytes of
the file for the version, and 'react' to that. Anytime you make a change,
you write a new function to load up the new version, and a companion
function to translate from version x to version x+1.
However, if you use ascii files, well, it's easier to used named
field tags, and just setup default information before parsing that data
entry. If you're curious, a named field is just a piece of
self-descriptive data;
Name: Xap
or
BareHandDamage: 50
Instead of the only slightly more inflexible version in most world
files, where the order is the important thing. You can just check for
returns from *scanf though in that case (oh, I got 4 ints, and needed 5,
well, place a default value in the 5'th key).
PjD
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT