--- help.text	Fri Mar 20 00:55:11 2009
+++ holo-help.text	Fri Mar 20 01:22:14 2009
@@ -587,7 +587,7 @@
   +-------------------------------------------------------------------------
 A | .           .      (1)         Author       .          .           Abode
 B | *           *      *           (2)          Builder    *           *
-C | *           *      *           *            *          *           *
+C | .           .      .           .            .          .           Chancellor
 D | Dark        Dark   Dark        Dark         Debug      *           *
 E | *           *      Exact       *            *          *           *
 F | *           *      FullName    FollowStatus FinalStack *           *
@@ -607,7 +607,7 @@
 T | Tap         *      *           Tap          *          *           *
 U | *           *      Unconnected Unseen       Unlistable Unkillable  *
 V | .           .      .           .            .          .           Visual
-W | .           .      .           .            .          .           Wizard
+W | *           *      *           *            *          *           *
 X | *           *      *           *            *          *           *
 Y | *           *      *           *            *          *           *
 Z | *           *      *           *            *          *           *
@@ -617,12 +617,12 @@
   server.
 . means "the same as the Other column".
 
-(1) A on an exit is Abode, unless the exit is set Wizard as well, in
-    which case A is Autostart.
-(2) B on a player is Builder, unless the player is set Wizard as well,
-    in which case it's Busy.
-(3) M on a player is Mucker, unless the player is set Wizard as well,
-    in which case it's Monitor.
+(1) A on an exit is Abode, unless the exit is set Chancellor as well,
+    in which case A is Autostart.
+(2) B on a player is Builder, unless the player is set Chancellor as
+    well, in which case it's Busy.
+(3) M on a player is Mucker, unless the player is set Chancellor as
+    well, in which case it's Monitor.
 
 Each flag name has its own help entry; for example, "help dark" will
 describe the semantics of the D bit when it's called Dark.
@@ -640,23 +640,24 @@
 "Living room(#1234R Joe)" instead of "Living room(#1234R)".
 &&& autostart
 At startup time, the server scans all exits in the db.  If any exit is
-set both W(izard) and A(utostart), and its first linked-to thing is a
-program, the program is run.  If the exit has an _autostart: property,
-its value is passed to the program as an argument; otherwise, "" is
-passed.  (A on a non-W(izard) exit is A(bode), but has no meaning.)
+set both C(hancellor) and A(utostart), and its first linked-to thing is
+a program, the program is run.  If the exit has an _autostart:
+property, its value is passed to the program as an argument; otherwise,
+"" is passed.  (A on a non-C(hancellor) exit is A(bode), but has no
+semantics to the server.)
 &&& builder
 The B(uilder) flag on a player or program allows that player/program to
 use the builder operations to create new things.  Specifically, the
 @open, @dig, @create, @action, and @attach commands do not work except
-when the player is set B(uilder) (or R(oyal) or W(izard)); the same
+when the player is set B(uilder) (or R(oyal) or C(hancellor)); the same
 applies to @link when used to seize an unlinked exit owned by someone
 else.  Similarly, the MUF primitives copyobj, create, dig, open,
 unlink, and addlink do not work unless (a) the effective player (see
-"man") is set B(uilder) (or R(oyal) or W(izard)), or (b) the program is
-set W(izard) and not Q(uell) and its owner is set W(izard), or (c) the
-program is set B(uilder).
+"man") is set B(uilder) (or R(oyal) or C(hancellor)), or (b) the
+program is set C(hancellor) and not Q(uell) and its owner is set
+C(hancellor), or (c) the program is set B(uilder).
 &&& busy
-When a player is set W(izard), the meaning of that player's B bit
+When a player is set C(hancellor), the meaning of that player's B bit
 changes from B(uilder) to B(usy).  Wizards always have builder
 privileges, so the B bit is unnecessary to indicate B(uilder) status.
 B(usy) has no semantics to the server.
@@ -730,9 +731,10 @@
 has the powers of a god, even if its G bit is not actually set, cannot
 be @toaded under any circumstances, and has a few other functions such
 as certain types of debugging output.  A G(od) bit does not grant all
-the powers of a W(izard) bit, notably the implicit M(ucker) and
+the powers of a C(hancellor) bit, notably the implicit M(ucker) and
 B(uilder) powers, but since a player set G(od) can always turn hir own
-W(izard) bit on, this does not actually restrict a god's capabilities.
+C(hancellor) bit on, this does not actually restrict a god's
+capabilities.
 &&& haven
 H(aven) has two functions: (1) no-one can use the kill command while in
 a room set H(aven), and (2) the page command will not send a message to
@@ -782,7 +784,7 @@
 player is set L(ink_OK), anyone may also set a thing's home to that
 player.
 &&& monitor
-When a player is set W(izard), the M bit changes its meaning from
+When a player is set C(hancellor), the M bit changes its meaning from
 M(ucker), which is redundant since wizards always have programmer
 privileges, to M(onitor).  When this bit is set, the player will be
 informed every time the database is checkpointed and whenever anyone
@@ -826,15 +828,15 @@
 but it is not restricted to that.
 &&& quell
 When a player's Q(uell) bit is set, any privilege that player has due
-to a R(oyal), W(izard) or G(od) bit is mostly suppressed.  Some
-privilege still remains; for example, a program set W(izard) and owned
-by a W(izard) player still has wizard powers if its owning player is
-set Q(uell) (though the _program_ can be set Q(uell) to quell its
-privilege).
+to a R(oyal), C(hancellor) or G(od) bit is mostly suppressed.  Some
+privilege still remains; for example, a program set C(hancellor) and
+owned by a C(hancellor) player still has wizard powers if its owning
+player is set Q(uell) (though the _program_ can be set Q(uell) to quell
+its privilege).
 &&& royal
-The R(oyal) bit grants many of the powers of a W(izard) bit, but not
-all.  It does not grant automatic builder or programmer privileges, for
-example, nor does it permit setting or clearing flag bits that the
+The R(oyal) bit grants many of the powers of a C(hancellor) bit, but
+not all.  It does not grant automatic builder or programmer privileges,
+for example, nor does it permit setting or clearing flag bits that the
 player could not set or clear without the R(oyal) bit.  What it does
 grant is the ability to use the #<num> and *<name> syntax for naming
 objects and players from a distance, and wizard-like ability to use
@@ -879,11 +881,12 @@
 who-list.
 &&& visual
 When an object is set V(isual), it can be "examine"d by anyone.
-&&& wizard
-When a player is set W(izard), that player has extra powers and
-immunities.  These are too widespread to list here; they are mentioned
-elsewhere when appropriate (for example, the W(izard) bit's interaction
-with the "kill" command is described under "help kill").
+&&& chancellor
+When a player is set C(hancellor), that player is called a wizard, and
+has extra powers and immunities.  These are too widespread to list
+here; they are mentioned elsewhere when appropriate (for example, how
+wizard status interacts with the "kill" command is described under
+"help kill").
 &&& properties
 Every object has a property list.  Properties are just name/value
 pairs, where the names and values are strings.  These are manipulated
@@ -907,7 +910,7 @@
 
 - When checking a property lock, if the property is an @ property, the
   lock always fails unless the object whose lock is being tested is set
-  W(izard).  (Q(uell) does not affect this.)
+  C(hancellor).  (Q(uell) does not affect this.)
 
 - When printing property lists for the @properties or examine commands,
   any * or @ properties are not listed unless the examining player is a
