On Tue, 26 Sep 2000 09:37:37 -0500, you wrote:
> 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.
I must have misunderstood your original comment. I thought you were
proposing a switch to single-file format. I agree that it would make
db loading a bit more complex, but nothing that a more robust loader
couldn't handle. I believe all the merc derivitives still use single
files.
> 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.
The only time I've seen a need to have at least one of something was
rooms, and that only because obuild required you to be located in a
room in the zone to create new rooms. Oasis may not have that
requirement and it isn't necessary anyway.
>> 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.
Well, there's definitely something to be said for displaying a variety
of styles. Even so, I think it would be best to fix those zones and
add a section to building.doc explaining the possibility of oversize
zones and the problems it may cause.
> 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.
No, moving zones was a fairly uncommon thing, but there were a few
builders who wrote zones offline, or modified them offline, and it was
a hassle when I would have rather been coding.
> 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.
It wasn't that sort of script. It was just a simple command to do the
copying for me so I could type copyzone 123 instead of all the cp
123.zon lib/world/zon, etc. There was so much db fault tolerence in
that particular mud that almost any weird configuration or typo was
handled as well as it could be.
> 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_".
The db loader I mentioned above was developed almost entirely using
the "oh yeah, we never thought of someone doing _that_" method. When
someone found a new way to break the loader, we fixed it. After
several years of newbie builder after newbie builder, it was a pretty
tight system. I don't think I still have the code, but it might be
possible to duplicate if implementors would be willing to submit
examples of problem zones as they encounter them.
Now that I think about it, though, do people still have these
problems, or has OLC made the point moot? It's been a very long time
since I've worked with builders.
>> 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.
Ah, I see. I suppose there may be someone out there who would want to
do something silly like that, but there would have to be at least two
before I'd consider modifying obuild to support it ;)
> 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).
Sounds reasonable to me.
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