Re: [Circle] Query

From: George Greer (greerga@circlemud.org)
Date: 09/26/00


On Tue, 26 Sep 2000, Alex wrote:

>>         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.
>This is a reasonable format, but your suggestion about tracking the file
>that a room/object/mob/etc is from is an even better one.  That way, what
>could be done could be something as follows:
>- You have a file with rooms 2598, 2599, and 2601.  File is 'wld25' (for
>  argument's sake).
>- You create room 2600, OLC likes to have these things in their own file,
>  so it creates 'wld26' and puts room 2600 in it.  It then goes through
>  the world as it seeds the new room in and notices room 2601, so removes
>  that from 'wld25' and puts it in the newly 'wld26'.

So why would wld25 have 2601 in the first place?  OLC may be useful, but
it's not magical.  If someone created room 2600, I'd shove it into the
existing zone since 2600 is obviously less than 2601 and 2601 is in zone
#25 already. Just don't overlap zones and OasisOLC shouldn't have problems.
(It might, but I remember actively stomping out 100'isms on the v1.7 ->
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.)

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.

--
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