On Tue, 26 Sep 2000, George Greer wrote:
> On Mon, 25 Sep 2000, Patrick Dughi 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?
>
> Changing one item/mobile/room forces a rewrite of every other such object
> in the world. That is, unless you like rewriting 768kB (stock CircleMUD
> wld/) on every change to a room.
>
> That little problem alone is enough for me to not consider it. Now if you
> wanted to use a Berkeley database or other such storage, then you'd be
> crazy to have separate files.
>
Didn't say it was a sane change - which is curious as to why we
allow it. Also, no olc tracks the origin file, so, when you wrote out the
zone after a change, it would write to it's own file.
You'd of course, still need seperate zone files.
Perhaps what might be better (read - easier) is to switch to a
logical non-additive system. For example, if I have zone 30, and it takes
up all 100 rooms, and zone 31 takes up some odd number ... if I want to
expand zone 30, I cannot. At least, not easily.
One of the by-products of an AVL-loading world structure I wrote a
while ago was that instead of a single vnum for an object (ie, mob, room,
etc) you had a zone-vnum combo. Now, it's ugly, and because I had some
problems with the 2'nd right rotation (AVL algorithm) that I never traced,
I am using some incompatibly licenced libraries to supplement it. Well,
some code from them at least.
This setup worked _really_ well. I can't distribute it, not even
in free form though, till I write it more from scratch.
Too bad too, this setup would eliminate sizing problems. You'd be
able to easily start at room vnum 21312 (for zone, say, 3..er.. naw, zone
"L"), and end up at 76543. Since you know the zone, you know the file
they go into. Of course, you don't have to worry about conflicts, even if
room 21312 or 76543 appear in other files.
I also changed the directory structure around, instead of 5 major
dirs with an index, I had a dir for each zone, and each had it's own 5
major dirs in there. No indexes.
Each object (mob/etc) was it's own file. Ugly, but it only took
about 2 extra seconds to load a stock world, and editing routines should
be immesurably faster, as you only save one item at a time. Technically,
this phase wasn't supposed to exist - it was supposed to be hitting a
database at this point, but I got distracted.
It was also incredibly fault tolderant. if 40 files in the obj
dir were wrong in some way, they'd be ignored, and the rest of the files
would load, since there were not even file-based dependancies.
Well, something to think about. Maybe if the licensing
litigation pays off, I can send it to people. Even includes scripts
(perl) to transform a stock world dir into this setup. I still recommend
a db for it though.
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