On Tue, 26 Sep 2000 08:44:11 -0400, Alex wrote:
>> That is, is there anything actually stopping anyone from taking
>> all those files, removing the '$~'->EOF marker, and putting them all in
>> one single file together?
Inertia would be the biggest obstacle I think.
>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).
>
>> 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.
>> 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,
>> 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.
>> 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.
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.
Sam
+------------------------------------------------------------+
| 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