bleh, sorry for the long post.
> >You mean, going back to the original DikuMud order of doing things? They
> >(kept through SillyMud) have one world file, one zone file, etc (the zone
> >file is just zone concatenated onto zone, so that each 'load' section is
> >'unique' and separated from the rest). Part of keeping the files separate
> >makes it _really_ easy to work with the files when you're the one in
> >charge of keeping the world in order (much easier than dealing with a 4Mb
> >file for example).
Actually, I never liked the single file(s) setup. Which is why I
don't like a setup which would actually _allow_ this. It's nice to
support both types of setup, and yes, it makes life easier in a way since
circle can more easily accept whole-hog zone sections from a disparate set
of code bases. At the same time, it makes life difficult for the program
loader to insure validity, and worse, it makes it very difficult to keep
track of 5 individual files, and their indexes (and mini indexes) when the
files are nebulously defined.
> >> Multiple files for each of the 5 'types', each with their own
> >> index, makes it easy to miss addition to an index for a given type (ie,
> >> you load the rooms, but not mobs).
> >This might be better addressed by having _one_ index. For example, on
> >VieMud, we have one index file (in the zone directory), the game reads
> >that, and will try to load a corresponding zone file, world file, object
> >file, and mobile file. These files do _not_ need to contain anything,
> >and can be simply '$~' (in CircleMUD terms), but do need to exist.
>
> Even that much should be unnecessary. A simple existence check would
> make the blank dummy files unnecessary. In fact, Circle could
> definitely benefit from being made more fault-tolerant during db boot.
> I'm not sure a single-file system would make things better or worse,
> but I think the formats of the files might be improved to allow the
> loaders to skip sections to the next sane entry.
The only reason I found to require that files exist is because it
makes it easier to insure that at least one valid _x_ is defined. I think
that one index file is fine, and with simple tracking, we can ignore the
non-existance of a named file.
> >> Multiple file types, without actual bounds (ie, 26.wld can have
> >> room 30000 in it) make it more difficult to save/load a specific room, and
> >> potentially causes errors if (and this is easily possible) you have
> >> rooms/etc in a file not associated with the zone it's in.
> >Putting everything into one file is not the best solution here. A better
> >solution is to sit down with the code and do one of the following:
> >a) force all lib files to contain only the 100 items (whether rooms, mobs,
> > or objects) that should be in there (ie 1200-1299 for 12.*)
> >b) fix the OLC saving routines so that they will save room 1200 in 12.*
> > and then 30000 in 300.*
>
> I think that if all the stock zones were restructured to 100 rooms per
> zone, there probably won't be many instances of oversize zones
> cropping up if people are using OLC primarily,
>
Exactly my point. Right now, the only zones that I've seen that
use this oversized setup are provided with stock circle. It'd take around
15 or 20 minutes to seperate them out into individual files, but I think
that time would be well spent. After all, as a stock world directory, I
would rather it be indicitive of the most common, easy to copy/understand
setup, instead of a wide variety of different styles.
> >> The only advantage of having multiple file types is a speedy
> >> lookup of a given room/etc.
> >How about the easy removal or addition of zones? Not very easy with
> >single files. Quite painful in fact.
>
> How so? I got so annoyed doing multiple moves/copies to install zones
> I ended up writing a script. Moving zones around is the one big
> reason I can see for going to a single file.
>
I think that moving zones around may happen less often than a
minor bug in a file load/save routine you just added causing havoc with
the file (and usually everything after the trouble entry). I'm glad that
they're seperate, so the damage is more well contained.
Does your script handle the instances in which a room/obj/mob/shp
for a zone exists in a file other than the zone#.room/obj/mob/shp? You
should, it's just as valid as compressing all files to one monstrous one.
> >> compounded by the fact that oasis/other OLCs enforce their own given
> >> format which may work - but is not specifically compatible with
> >> previous formats
> >That isn't a CircleMUD problem. That's a problem with the OLCs not
> >going along with the CircleMUD model. Fixing the source of the problem
> >rather than the symptom is generally a better idea.
>
The problem is the poor definition of circlemud world files. This
is displayed when an interface like Oasis, or hand editing the world
files. Worse, the setup to circle appears intuitive, but is actually not,
making it exceptionally prone to errors in all the 'boundry'-rated
conditions; those that don't often appear. Aka, "oh yeah, we never
thought of someone doing _that_".
> I'm not sure I understand what is meant by OLC's enforcing formats.
> If anything the OLC's would make a format change transparent to most
> builders, assuming they were updated at the same time as the stock db
> loading was changed, and updating the OLC's would be pretty easy.
Creation of zone# creates (and adds index entries) the 5
zon,wld,obj,mob,shp entries. However, I could (legally) have object 44 in
the file 30.obj. It would be valid, load correctly, etc. This works for
rooms, shops, objects, mobs. Say I never had a zone 30 - and I create it
- suddenly this previous entry gets wiped out, and I loose my object #44.
Most olc's say "a zone is defined as zone#*100 to 'top of zone' -
if a room/mob/obj vnum is in that range, write it to file zone#". Which
is only one valid setup. It also tends to conflict with every other
setup. You'd actually have to include a setting for each obj/room/mob/shp
which contains a variable pointing to the file(name) that it actually came
from, so you can write it back out to the correct spot each time.
Yes, it is a stupid thing to have it in a non intuitive manner,
but it doesn't escape the fact that stupid or not, it's a valid setup.
Until you have OLC enforce the most commonly percived format and it causes
harm to your existing setup.
So, we need a more rigidly defined file format.
I like 1 index file, zone files can still retain the range, but a
mob/shp/wld/obj file will only contain 0 to 100 entries of the form #*100
to #*100+99, based on the name of the file.
Further, it would be good to declare that all zones are
specifically 100 rooms maximum size - if you need more, you simply add
another zone (like the confusing zone 25 in stock would be zones 25 & 26).
This is how it's done most of the time with Oasis anyway, since altering
'top of zone' tends to cause issues in the long run (or at least, it did).
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/11/01 PDT