File	Date	Author	Commit
CVS	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
.history	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
BuildMap.lpc	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
Exits.h	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
MapKnower.lpc	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
README	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
ROOM.lpc	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
controller.lpc	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
massacre.lpc	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
skeleton_key.lpc	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
spec_rooms.lpc	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
track.lpc	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
virtual.lpc	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.
walkabout.lpc	2022-09-16	Geoff Wong	[e89a16] Moved from CVS to git.

Read Me

Map - routing, tracking, and map management system.  Except where
otherwise noted, all of this is by Gandalf, over the years (Copyright
mmcg@cs.monash.edu.au).

This stuff is designed to be able to be dropped into a mudlib, and
accumulate data on what rooms link to what other rooms.  A tracker is
provided which will generate a sequence of commands to walk from one
room to another.  It's fairly robust, stable code.

There are the following objects:

    MapKnower.c (server)  - central repository of known map & link data,
			    plus route calculation engine.
    track,c (soul object) - clonable object that gives a simple interface
			    to the route calculation engine, issuing "commands"
			    to do the moves.
    BuildMap.c	- loads every reachable room, writes a trace to a logfile.
		  I have various external programs (in C) to check these maps
		  for consistency.
    massacre.c	- stress test the mud (same as BuildMap, but doesnt log).
    controller.c - basic area controller
    maze_controller.c - controller that generates random simply connected mazes.
    spec_rooms.c - tracks special rooms.  shouldnt be here.
    virtual.c - test object.  shouldnt be here.

External considerations:

All rooms are supposed to call MapKnower->add_location() when they are
loaded and given a dest dir.  It is assumed that new rooms are being
added all the time, but that the dest dirs of existing rooms don't
change with time (to rebuild the map data whenever one does so would
constitute an intolerable CPU overhead).  No special consideration
needs to be given to the addition of "normal" rooms with fixed dest
dirs, besides ensuring that this is called (probably in your base
inherited room file); even if there is no preexisting map, the system
will accumulate room data and keep it in a savefile; as soon as it has
seen enough rooms to know that there is a path from A to B, it'll
calculate it on demand.  After reboots, etc, the info will be available
from a savefile; rooms are never loaded when calculating route data (except
the target room, if it's known to exist but has never been loaded before).

Rooms that are managed by area controllers are not managed by this
system; the task is deferred to the controller (which likely knows a
lot more about the area than us).  The primary reason for doing this
even when this code would be optimal for a given area is that (a) we
can't know that, and (b) areas can be very large, but array sizes are
limited.  Area controllers should call MapKnower->add_controller(); it
is presumed that all rooms with names that have the controller name as
a prefix will be managed by that area controller.  This is not the most
flexible way to do things, but is probably the cheapest.

Rooms which have changing dest dirs (eg old style mazes) are a problem;
the system attempts to detect and accomodate them; however, I'll not
be making special purpose code to deal with them properly because I
believe they should not exist (you can manage them using your own
area controller).  Eventually, I intend to delete all such mazes
from our mudlib (the mapper already informs me of them :)