George wrote (and I was too lazy to sort out):
On Tue, 26 Sep 2000, Patrick Dughi wrote:
>> So why would wld25 have 2601 in the first place?
> Because it could. 2601 could be in zone 26, or zone 70, or
>whatever, and be valid. no overlap.
Obviously the argument I had in my head didn't quite get across, even to
myself. It was along the lines of "if you had 2601 and wanted a zone #26,
why put it in zone #25's file, just place it in #26". That was assuming
the a) disallowing of overlap (implied or explicit) and b) it'll get moved
by the olc anyway.
I'd rather think you're abusing the intended system there with placing room
2601 in zone 70. Sure the code isn't enforcing it, that's back to the flat
file days. I always considered it an unwritten rule to place stuff in
zone*100+top_of_zone and not object 43 in zone 700.
>However, there are no rules saying that a given piece of data must load
>from a file named after the zone it's in. Thus, i could change my
>wld/obj/shp/mob indexs to 0.<suffix>, put all things in there, and the
>.zon files would delineate which went to which zone.
You could also define a single zone 0 going from 0 to 32767. Then you can
even leave your other (object/room/mob/shop) files separate or just unify
them as well. That'll wreak havoc on your zone resets though and make it
tough to give builder permissions. :)
> But in the end, it'd be valid. It'd work, because the parser is
>either way too fault tolerant, or doesn't adequatly describe any sort of
>relationship between a piece of data, and where it's saved and where it's
>loaded. It's only implied, and the parser doesn't care either way.
> Worse, the parser works even if you do something like above (i
>tested it, it works fine), which means, it's 'alright to do'.
OasisOLC (and probably other OLC systems) obviously does care and will, in
fact, "fix" all your files if you issue a save command for them. It'll
take all your wacky objects for zone #70 with a virtual number of 26 and
throw it into zone #0 instead. Similarly, all of your misplaced rooms get
rearranged. If you saved both, everything is happy; if you save only one
then you get either a lost object or duplicate objects.
CircleMUD doesn't care, it lets you devise any wacky scheme you like. I'm
not yet convinced that's bad. After all, we're online creation agnostic,
although the warning gets pretty religious. :)
>> v2.0 changes. If you find any, let me know in an easily pointed out
>> manner.) Now, if someone tried to create zone #26 with room 2601 in zone
>> #25, then I'd have the zone creation just punt. (Maybe the current code
>> doesn't...don't remember.)
> Current code takes room# = zone#*100. If room# exists between
>zone#*100 to top of any zone, it denies it.
room = vzone_num * 100;
for (i = 0; i <= top_of_zone_table; i++)
if (zone_table[i].number * 100 <= room && zone_table[i].top >= room) {
*error = "A zone already covers that area.\r\n";
return NOWHERE;
}
And it is correct, the zone below it already covers that area.
Add Zone #26 to Zone #25, 2500-2601
2500 <= 2600 <= 2601
> But, I could put object 3000 in file 0.obj, and it'd still load
>up, right as rain.
And I can pipe /dev/zero to /proc/kcore to crash my machine. That doesn't
convince me CircleMUD should care. The world is in a consistent state for
all it sees, although the various OLC systems will throw fits at you.
>> If you'd like to enforce 100'ism, just make all of your zone_table[].top to
>> x99 and write some code to check for objects/mobiles outside of zones. In
>> essence, OasisOLC should allow >100 per zone, but you're not forced to do
>> it that way.
> I'm not saying that's the best way, but the format should be much
>more concrete for file placement of data. That way things that work on
>the data externally can create this setup more easily, without stepping on
>a previous (and working) situation.
> Circlemud itself never has to deal with the creation of new files.
>It excpects people to do the hard work for it. Now OLC does it, but it
>makes assumptions which may cause breakage (though shouldn't unless you
>have one wierd ass setup).
Ok, let's go back to the original message by you:
> Re-re-revamping offline editor, I thought to myself, should I try,
>in any way whatsoever, to promote a more, well.. structured view of the
>data files in the world directory?
Don't litter zone #700 with vnum 36. Keep all stuff in zone #40 in
(top_of_zone39+1) to (top_of_zone40). OLC frequently assumes (zone*100) as
the start of the zone. Is that correct? No, but since there isn't a
zone_number[].bottom and zone #39 isn't guaranteed to exist, that's what it
uses. Zone #2 does have to be "above" zone #1, so funny ordering isn't
allowed. If we added a '.bottom' then I would readily agree to your
argument that we shouldn't assume 'zone*100' as the base. Until then, you
have a better idea?
> 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?
You have all the rope you need to hang yourself with. :)
(Unless you change the format of the file in question to something like a
Berkeley DB.)
> Well, barring .zon files... which have their own special load
>section, so only one zone definition per file.
> Is that right?
> Doesn't this just make stock circle setup more error prone?
Error prone to what? Placing object #70 in zone #50? It's logically wrong
for humans but CircleMUD doesn't mind. The OLC systems care but they
enforce their own little world of assumptions (based on the existing stock
world) on the code.
> 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).
It also makes it easy to individually turn them off. It's a trade-off.
Perhaps you're importing a new area but only load the objects/mobiles first
to see what they look like before adding the entire area to the world.
> 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.
Maybe I want objects and mobiles not associated with a zone, because said
zone/rooms don't exist yet. CircleMUD has no objections (I've done it
before) but I'm fairly sure the OLC systems would throw a fit.
> The only advantage of having multiple file types is a speedy
>lookup of a given room/etc. This is negated by having no fixed or
>required format, and compounded by the fact that oasis/other OLCs enforce
>their own given format which may work - but is not specifically compatible
>with previous formats (ie causing errors in the second place).
> So, it seems that to make life easy, either you put everything in
>as few files as possible, or give a single file a very discrete set of
>boundries - and probably load directly off just a single index file (the
>zone index file)....
I think the system works well for what we use it for. When you add an OLC
system with its own requirements, then things may not be optimal. OasisOLC
assumes zone*100 base number and that everything in that zone is numbered
(zone*100) to (top_of_zone#).
In essence:
If you write an OLC system with a different set of rules than
CircleMUD itself needs, then modify the CircleMUD loading routines
in your OLC system to check for such problems.
Having said that, no, OasisOLC doesn't modify to check for such strange
acts. I've never heard of anyone trying to actively confuse themselves and
break stuff with regard to zone loading. I'll throw it on my queue of
things to do if you really want it.
I'm all for the code not stopping people from doing correct yet illogical
things. Perhaps we have some things like that in CircleMUD I'd rather be
changed, I don't know. For example, I recently got upset when I couldn't
truncate (0 byte, not delete) a program that was causing a fork bomb. As
far as the truncate would be concerned, it would be correct. It's rather
illogical to overwrite a running program, however, but my intent was to
crash said program by making it execute 0's instead of the proper assembly
code, thus ending the fork bomb. I got "error: text busy" and had to
reboot the machine.
Along the same lines are anywhere the code tells the Owner of the MUD he
can't do that. "I don't care if the room is private, a death trap,
underwater, and without exits, let me go there!"
Anyway, hope that gets the idea around.
--
George Greer
greerga@circlemud.org
+------------------------------------------------------------+
| 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