From: George Greer <greerga@CIRCLEMUD.ORG>
> On Tue, 4 Dec 2001, krenshala wrote:
>
> >Some friends and I have finally gotten around to working on our mud
again,
> >so I just downloaded 3.0bpl19 (since we are starting from scratch).
After
> >reading the ChangeLog, I'm not sure if I'm properly understanding the
> >changes to zones/rooms.
> >
> >It sounds like zones can now me made up of any series of vnums from 0 to
> >32767. Is this correct? And is there a limit on the number of zones
(not
> >rooms) that stock Circle will support?
>
> Unless you change the vnum/rnum data types, you're still limited to 32,767
> zones, 32,767 rooms, etc. The change is that the zone starting room is
not
> forced to '100 * virtual_zone' any longer. Be wary that a lot of existing
> OLC software breaks horribly for overlapping areas. Also, since we ignore
> the old Diku "zone" field in the room files (which might actually be
useful
> again), a room is assumed to be contained in the first zone that can
accept
> it. In other words, with two zones from 5-6 and 6-7, room #6 is in the
> first. This only really matters for "shout" and other single-zone
> commands. Zzone resetting is handled properly.
We aren't using OLC (at least, not at this point :) so that won't be a
problem.
So, as long as both the zone numbers and room numbers don't exceed 32767
things are good? This I can work with. :)
As for overlapping zones (using your example) will the zone reset for both
zones affect room 6? If so, this leads to some ... interesting
posibilities. [The shout (and other similar command) limitations are a
minor thing.]
Larry
Larry Robinson
krenshala@jump.net
:wq
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 06/24/03 PDT