--- data/base.help.text 2012-01-10 13:23:09.000000000 -0500 +++ data/help.text 2012-01-10 13:46:11.000000000 -0500 @@ -614,7 +614,7 @@ +------------------------------------------------------------------------- A | . . (1) Author . . Abode B | * * * (2) Builder * * -C | * * * * * * * +C | . . . . . . Chancellor D | Dark Dark Dark Dark Debug * * E | * * Exact * * * * F | * * FullName FollowStatus FinalStack * * @@ -634,7 +634,7 @@ T | Tap * * Tap TriggerUID * * U | * * Unconnected Unseen Unlistable Unkillable * V | . . . . . . Visual -W | . . . . . . Wizard +W | * * * * * * * X | * * * * * * * Y | * * * * * * * Z | * * * * * * * @@ -644,12 +644,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. @@ -667,23 +667,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 +meaning.) &&& 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. @@ -757,9 +758,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 @@ -809,7 +811,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 +On a player 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 @@ -853,15 +855,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 even 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 even 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 # and * syntax for naming objects and players from a distance, and wizard-like ability to use @@ -912,11 +914,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 @@ -940,7 +943,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