![[ nwe help ]](/writing/help/images/nwe-help.GIF)
| Search | Help » General » MOO » JHC » Wizard Help |
MOO Administrator (Wizard) Help
$site_db @@who @abort-shutdown blacklist @blacklist @chown @denewt @detoad @dump-database @egrep @grant graylist @graylist @grep @grepcore @guests @log make-core-database @make-guest @make-player @net-who @newt @players @programmer @quota @recycle redlist @redlist @shout @shutdown @toad @unnewt @untoad @who-calls
$site_db is a database of places people have connected from.
Important verbs and properties are:
:add(sitename,player)
records the fact that player connected from sitename.
:load()
clears the db and reloads all of the player connection info.
.domain
default domain for unqualified sitenames given to :add.
For each domain we keep a list of players and subdomains.
For example, :add("doc.ic.ac.uk",#666) enters #666 on the lists for
"doc.ic.ac.uk", and, if we have to create an entry for "doc.ic.ac.uk",
we enter "doc" on the list for "ic.ac.uk", "ic" on the list for
"ac.uk", etc.... In this case, :find("ic") will return the "ic.ac.uk"
list if there is no other domain in $site_db starting with "ic". Note
that the "ic.ac.uk" list may contain both objects, i.e., players that
have connected from the site "ic.ac.uk", and strings, i.e., subdomains
of "ic.ac.uk" like "doc".
:find_exact(string) => player/subdomain list or $failed_match
:find_all_keys(string) => list of all domains that begin with string
:find_key (string) => unique domain that begins with string,
$ambiguous_match or $failed_match
The other $generic_db functions (:find, :find_all) are also available,
though admittedly less useful.
Syntax: @net-who [<player>...]
@net-who from [<domain>]
Synonym: @@who
@net-who without any arguments prints all connected users and hosts.
If one or more <player> arguments are given, the specified users are
printed along with their current or most recent connected hosts. If
any of these hosts are mentioned on $login.blacklist or
$login.graylist (see `help blacklist'[1]), an annotation appears.
With a `from...' argument, this command consults $site_db and prints
all players who have ever connected from the given domain.
Syntax: @abort-sh*utdown [<text>] This aborts any shutdown currently in progress (i.e., set in motion by @shutdown). All players are notified that no shutdown will actually occur; <text>, if given will be included in this notification.
$login maintains three lists of hosts/domains to support player
registration schemes and blocking of connections from highly untrusted
hosts:
.redlist -- all connections from these sites are disabled
.blacklist -- player creation and guest logins are disabled
.graylist -- advisory list of potential trouble spots (putting a
site on the .graylist merely annotates it in @net-who listings).
The lists are kept in a special format so it is highly recommended
that you either use $wiz:@*list/@un*list or the following verbs to
query/update the respective lists rather than bash them directly:
$login:*listed (host) is host is on .*list?
$login:*list_add (domain or subnet) add domain or subnet to .*list
$login:*list_remove(domain or subnet) remove domain or subnet from .*list
where `*' is one of `black', `red', or `gray'.
One may either specify a domain name (e.g., "baz.edu") or a numeric IP
address (e.g., "36.0.23.17"). Domain names match all hosts underneath
that domain, so, e.g., puting "baz.edu" on a list effectively adds
"x.bax.edu" for all x as well.
Likewise, an incomplete numeric address, e.g., "128.42" will match
that entire subnet, in this case all hosts whose IP numbers have the
form "128.42.m.n" for arbitrary integers m and n.
One may also give a domain name containing a wildcard ("*"), e.g.,
"fritz*.baz.edu", in which case all hostnames matching in the sense of
$string_utils:match_string() are considred to be on the list.
Wildcard matching should be avoided since it is more time-consuming.
It should be noted that, since there is no direct access to the domain
name service from within the MOO, it is possible for a host to be
blacklisted or redlisted via its domain name, and yet have someone be
able to connect from that host (and, in the case of a blacklisted
host, create a character) --- this can happen if the name service is
down and connection_name() on that player thus has given the numeric
IP address rather than the domain name. Similarly, if you list a host
by IP number alone, it will still be possible to get in via the site's
domain name. Thus to be completely assured of shutting out a site,
you need to list it both by domain name and IP number.
Syntax: @redlist [<domain or subnet> [commentary]]
@blacklist [<domain or subnet> [commentary]]
@graylist [<domain or subnet> [commentary]]
Syntax: @unredlist [<domain or subnet> [commentary]]
@unblacklist [<domain or subnet> [commentary]]
@ungraylist [<domain or subnet> [commentary]]
With no argument, the current contents of the <color>list are printed.
Otherwise, the specified domain or subnet is added to or removed from
the list and mail will be sent to $site_log.
If the given domain or subnet has subdomains/subsubnets that are
already on the list, you will be prompted as to whether you want to
remove them. Note that adding an entry for a particular domain or
subnet effectively adds all subdomains/subsubnets, so unless there's
some reason for keeping an explicit entry for a particular subdomain,
chances are you will indeed want to remove them. One reason to keep
an explicit entry for a subdomain would be if you intended to unlist
the full domain later but wanted to be sure you didn't unlist the
subdomain in the process.
See `help blacklist'[1] for a description of the functions of these
<color>lists.
Syntax: @chown <object> [to] <owner>
@chown <object>.<propname> [to] <owner>
@chown <object>:<verbname> [to] <owner>
Changes the ownership of the indicated object, property or verb.
Verb ownership changes are fairly straightforward, being merely a
matter of changing the verb_info() on a single verb.
Changing an object ownership includes changing the ownership on all +c
properties on that object. Note that @chown will not change the
ownership of any other properties, nor will it change verb ownerships.
Use @grant if you need to do a more complete ownership change. The
quota of the former owner is increased by one, as is the quota of the
new owner decreased by one.
Changing a property ownership is truly hairy. If the property is +c
one shouldnot be doing this, unless it is to correct a past injustice
which caused the property to be owned by the wrong player. In the
case of -c properties, the property ownership is changed on all
descendent objects (currently, if +c instances of a -c property are
found in the traversal of all of the descendants, these are not
changed, being deemed sufficiently weird that they should be handled
on a case-by-case basis...).
If there's any justice, a future version of the server will prevent
occurrences of (1) +c properties being owned by someone other than the
object owner (2) -c properties with different owners on descendant
objects (3) -c properties that are +c on some descendants.
Syntax: @denewt <user> [commentary]
Synonyms: @unnewt
@get-better
@denewt reverses the effects of @newt, moving a user's :denewt_confunc
back to :confunc, but checking first that :confunc is the same as
$wiz_utils:newt_confunc (if not, we save :confunc as :newt_confunc and
complain).
Mail is sent to $newt_log including any commentary you provide. E.g.,
@denewt Twit He promises not to do it again.
Syntax: @untoad <object> [as <name>,<alias>,<alias>...] Synonym: @detoad Turns the object into a player. If the name/alias... specification is given, the object is also renamed. In order for this to work, the object must be a nonplayer descendant of $player and the new object name (or the original name if none is given in the command line) must be available for use as a player name. As with ordinary player @renaming, any aliases which are unavailable for use as player names are eliminated. If the object is a descendant of $guest, then it becomes a new guest character. Otherwise the object is chowned to itself. In the latter case, it is advisable to check that the .password property has something nontrivial in it. If the object is a descendant of $prog, then its .programmer flag is set. Note that the .wizard flag is not set under any circumstances.
Syntax: @dump-database Invokes the builtin dump_database(), which requests that the server checkpoint the database at its next opportunity. It is not normally necessary to call this function; the server automatically checkpoints the database at regular intervals; see the chapter on server assumptions about the database for details.
Syntax: @grep <string> in <object>
@grep <string> in {<objectlist>}
@egrep <regexp> in <object>
@egrep <regexp> in {<objectlist>}
These are named for the corresponding unix utilities.
@grep searches the given object(s) for verbs whose verbcode contains
the given string as a substring of one of its lines.
@egrep searches the given object(s) for verbs whose verbcode contains
a substring matching the given regular expression (see `help
regular-expressions'[1]).
For wizards, the following forms are also available for doing full-db
searches
@grep <pattern>
@egrep <pattern>
@grep <pattern> from [#]<n>
@egrep <pattern> from [#]<n>
the first two search all objects in the database while the last two
search the range [#<n>..max_object()]
See also: @grepcore, @who-calls.
Usage: @grant <object> to <recipient> (used by owner)
@grant <object> to me (used by recipient)
Change the ownership of an object, including all properties and verbs
owned by the owner. This is a two-step process: First the owner
offers it to the recipient, then the recipient accepts it.
All properties and verbs on the object that are owned by its owner
will be given to the recipient. This means you should probably be
careful in accepting an object. In addition, !c verbs owned by this
object's owner will change hands on all descendants.
Wizards can @grant objects in one step.
$login maintains three lists of hosts/domains to support player
registration schemes and blocking of connections from highly untrusted
hosts:
.redlist -- all connections from these sites are disabled
.blacklist -- player creation and guest logins are disabled
.graylist -- advisory list of potential trouble spots (putting a
site on the .graylist merely annotates it in @net-who listings).
The lists are kept in a special format so it is highly recommended
that you either use $wiz:@*list/@un*list or the following verbs to
query/update the respective lists rather than bash them directly:
$login:*listed (host) is host is on .*list?
$login:*list_add (domain or subnet) add domain or subnet to .*list
$login:*list_remove(domain or subnet) remove domain or subnet from .*list
where `*' is one of `black', `red', or `gray'.
One may either specify a domain name (e.g., "baz.edu") or a numeric IP
address (e.g., "36.0.23.17"). Domain names match all hosts underneath
that domain, so, e.g., puting "baz.edu" on a list effectively adds
"x.bax.edu" for all x as well.
Likewise, an incomplete numeric address, e.g., "128.42" will match
that entire subnet, in this case all hosts whose IP numbers have the
form "128.42.m.n" for arbitrary integers m and n.
One may also give a domain name containing a wildcard ("*"), e.g.,
"fritz*.baz.edu", in which case all hostnames matching in the sense of
$string_utils:match_string() are considred to be on the list.
Wildcard matching should be avoided since it is more time-consuming.
It should be noted that, since there is no direct access to the domain
name service from within the MOO, it is possible for a host to be
blacklisted or redlisted via its domain name, and yet have someone be
able to connect from that host (and, in the case of a blacklisted
host, create a character) --- this can happen if the name service is
down and connection_name() on that player thus has given the numeric
IP address rather than the domain name. Similarly, if you list a host
by IP number alone, it will still be possible to get in via the site's
domain name. Thus to be completely assured of shutting out a site,
you need to list it both by domain name and IP number.
Syntax: @redlist [<domain or subnet> [commentary]]
@blacklist [<domain or subnet> [commentary]]
@graylist [<domain or subnet> [commentary]]
Syntax: @unredlist [<domain or subnet> [commentary]]
@unblacklist [<domain or subnet> [commentary]]
@ungraylist [<domain or subnet> [commentary]]
With no argument, the current contents of the <color>list are printed.
Otherwise, the specified domain or subnet is added to or removed from
the list and mail will be sent to $site_log.
If the given domain or subnet has subdomains/subsubnets that are
already on the list, you will be prompted as to whether you want to
remove them. Note that adding an entry for a particular domain or
subnet effectively adds all subdomains/subsubnets, so unless there's
some reason for keeping an explicit entry for a particular subdomain,
chances are you will indeed want to remove them. One reason to keep
an explicit entry for a subdomain would be if you intended to unlist
the full domain later but wanted to be sure you didn't unlist the
subdomain in the process.
See `help blacklist'[1] for a description of the functions of these
<color>lists.
Syntax: @grep <string> in <object>
@grep <string> in {<objectlist>}
@egrep <regexp> in <object>
@egrep <regexp> in {<objectlist>}
These are named for the corresponding unix utilities.
@grep searches the given object(s) for verbs whose verbcode contains
the given string as a substring of one of its lines.
@egrep searches the given object(s) for verbs whose verbcode contains
a substring matching the given regular expression (see `help
regular-expressions'[1]).
For wizards, the following forms are also available for doing full-db
searches
@grep <pattern>
@egrep <pattern>
@grep <pattern> from [#]<n>
@egrep <pattern> from [#]<n>
the first two search all objects in the database while the last two
search the range [#<n>..max_object()]
See also: @grepcore, @who-calls.
Syntax: @grepcore <pattern>
@who-calls <verbname>
@grepcore pattern is @grep pattern in {all core objects}. Core
objects are computed for you by #0:core_objects().
@who-calls greps for the verbname + "(", hoping to catch it as a verb
call. Currently @who-calls does not allow you to restrict the search
as @grep does. (Volunteers?)
Syntax: @guests [<n>] Prints out the log of guest player connections, indicating connect/disconnect times and where they came from. If a numeric argument n is given, then only the last n entries in the log are consulted (useful for when the full log is rather long) --- note that connections and disconnections are separate entries so the actual printed listing will be about half this length. Alternate: @guests now Prints out in @who format all connected guests. In place of the location field is the current connect site.
Syntax: @log <message>
@log
The first form enters <message> as a one-line comment in the server
log. The second form prompts for a sequence of lines to be
collectively entered as an extended comment. This uses
$command_utils:read_lines so all of those conventions apply, i.e., a
period on a line by itself ends the text, `@abort' aborts the command,
etc...). Example: If Wizard (#2) types
@log I did $dump_interval=3600
the following line appears in the server log
Aug 19 22:36:52: COMMENT: from Wizard (#2): I did $dump_interval=3600
Syntax: make-core-database ...makes a core database (surprise). Film at 11...
Syntax: @make-guest <adjective> This creates a new guest character. For example, @make-guest Loud creates a child of $guest, owned by $hacker, named Loud_Guest and with aliases Loud and Loud_Guest. Note that in order to have `connect guest' connect to a guest character, there needs to exist some guest character having "Guest" as a name or alias. See also `help @make-player'[1].
Syntax: @make-player <name>[,<aliases>] [<email-address> [password>]] This creates a new player having the given name and password. If an email address is given, this information is sent off to $new_player_log. If password is null or not given, a random password is generated.
Syntax: @net-who [<player>...]
@net-who from [<domain>]
Synonym: @@who
@net-who without any arguments prints all connected users and hosts.
If one or more <player> arguments are given, the specified users are
printed along with their current or most recent connected hosts. If
any of these hosts are mentioned on $login.blacklist or
$login.graylist (see `help blacklist'[1]), an annotation appears.
With a `from...' argument, this command consults $site_db and prints
all players who have ever connected from the given domain.
Syntax: @newt <player> [commentary]
The @newt command temporarily prevents logins on a given player. It
works by installing a confunc ($wiz_utils:newt_confunc) on player that
does an immediate ;boot_player(), saving any existing :confunc the
user may have as :denewt_confunc. Use @denewt to reverse this.
You must give either the player's full name or its object number.
Also, this command does not let you @newt yourself.
Mail will be sent to $newt_log, listing the player's
.all_connect_places and including any commentary you provide. E.g.,
@newt Twit did real annoying things.
As with @toad and @programmer, there are messages that one may set
@newt [{list}]
Printed to everyone in the room in which the victim is being @newted.
If you're worried about accidentally newting yourself in the process of
setting this message, you can't (see above).
@newt_victim []
Printed to the victim.
This is followed by $login:newt_registration_string().
See `help @toad'[1] if you need something more drastic.
Syntax: @players [with objects] Hmmm... what *does* this do, anyway?
Syntax: @programmer <player>
Sets the programmer flag on the indicated player and sends mail to $new_prog_log.
If the player is not already a descendant of $prog, we @chparent
him/her to $prog. In this case, if $prog has a larger
.ownership_quota than its ancestors, then we raise the player's quota
by the difference between $prog.ownership_quota and the
.ownership_quota of the common ancestor of player and $prog, be this
$player or some intermediate class.
There are messages that one may set to customize how the granting of a
programmer bit looks to the victim and to any onlookers. After all,
this is a seminal event in a MOOer's life... Thus we have
@programmer [{list}]
Printed to everyone in the room with the victim being @programmer'ed.
@programmer_victim [You are now a programmer.]
Printed to the victim.
These are pronoun subbed with victim == dobj.
Usage: @quota [<someone>] Each player has a limit as to how much database disk space e may consume with their objects, properties, and verbs. Objects are periodically measured (and can have their measurement forced---see help @measure). If a player is over quota after a measurement, e will not be able to @create any objects, use @copy, @verb, or @property to grow any objects. Existing properties and verbs may be edited/changed at will, even while over quota. The @quota command prints out your current quota and measured usage. If you have more than one character, it will summarize all your other characters' usage as well. @quota <player> will print out the quota and usage of another player. [Note: you will not be able to obtain second character information for another player; whether primary or secondary character, the @quota display will only show one character's quota.] @quota prints a time of measurement in its display. This is the time of the oldest measurement out of all your objects. For example, if you @measure three of your objects right now, those individual times get updated, but if you still have a couple of objects with older measurements, that older time will be the time printed by @quota. This is confusing to many people. If you want to get more quota, please see `help quota-policy'[1]. - - - - - - - - - - - - - - - - - - - - - - - - - - Syntax: @quota <player> is <number> [<reason>] This second and more interesting form of the verb changes a player's quota to the given number. Mail will be sent to $quota_log; the message will include the <reason> if such is given.
Syntax: @recycle <object-name-or-number> Destroys the indicated object utterly and irretrievably. Naturally, you may only do this to objects that you own. Of course, wizards are allowed to @recycle anything at all. There is, however, a block (in $player:recycle) against recycling actual players, i.e., descendants of $player that have the player flag set. This is mainly to prevent stupid mistakes. If, for some reason, you want to recycle a player, you need to @toad it first.
$login maintains three lists of hosts/domains to support player
registration schemes and blocking of connections from highly untrusted
hosts:
.redlist -- all connections from these sites are disabled
.blacklist -- player creation and guest logins are disabled
.graylist -- advisory list of potential trouble spots (putting a site
on the .graylist merely annotates it in @net-who listings).
The lists are kept in a special format so it is highly recommended
that you either use $wiz:@*list/@un*list or the following verbs to
query/update the respective lists rather than bash them directly:
$login:*listed (host) is host is on .*list?
$login:*list_add (domain or subnet) add domain or subnet to .*list
$login:*list_remove(domain or subnet) remove domain or subnet from .*list
where `*' is one of `black', `red', or `gray'.
One may either specify a domain name (e.g., "baz.edu") or a numeric IP
address (e.g., "36.0.23.17"). Domain names match all hosts underneath
that domain, so, e.g., puting "baz.edu" on a list effectively adds
"x.bax.edu" for all x as well.
Likewise, an incomplete numeric address, e.g., "128.42" will match
that entire subnet, in this case all hosts whose IP numbers have the
form "128.42.m.n" for arbitrary integers m and n.
One may also give a domain name containing a wildcard ("*"), e.g.,
"fritz*.baz.edu", in which case all hostnames matching in the sense of
$string_utils:match_string() are considred to be on the list.
Wildcard matching should be avoided since it is more time-consuming.
It should be noted that, since there is no direct access to the domain
name service from within the MOO, it is possible for a host to be
blacklisted or redlisted via its domain name, and yet have someone be
able to connect from that host (and, in the case of a blacklisted
host, create a character) --- this can happen if the name service is
down and connection_name() on that player thus has given the numeric
IP address rather than the domain name. Similarly, if you list a host
by IP number alone, it will still be possible to get in via the site's
domain name. Thus to be completely assured of shutting out a site,
you need to list it both by domain name and IP number.
Syntax: @redlist [<domain or subnet> [commentary]]
@blacklist [<domain or subnet> [commentary]]
@graylist [<domain or subnet> [commentary]]
Syntax: @unredlist [<domain or subnet> [commentary]]
@unblacklist [<domain or subnet> [commentary]]
@ungraylist [<domain or subnet> [commentary]]
With no argument, the current contents of the <color>list are
printed. Otherwise, the specified domain or subnet is added to or
removed from the list and mail will be sent to $site_log.
If the given domain or subnet has subdomains/subsubnets that are
already on the list, you will be prompted as to whether you want to
remove them. Note that adding an entry for a particular domain or
subnet effectively adds all subdomains/subsubnets, so unless there's
some reason for keeping an explicit entry for a particular subdomain,
chances are you will indeed want to remove them. One reason to keep
an explicit entry for a subdomain would be if you intended to unlist
the full domain later but wanted to be sure you didn't unlist the
subdomain in the process.
See `help blacklist'[1] for a description of the functions of these <color>lists.
Syntax: @shout <text> Broadcasts the given text to all connected players.
Syntax: @shutdown [<text>] This is the friendly way to do a server shutdown; it arranges for the actual shutdown to take place two minutes hence. Shutdown is preceded by a sequence of warnings to all connected players. Warnings are likewise given to all players who connect during this time. <text>, if given is included in these warning messages, perhaps as an explanation for why the server is being shut down. Shutdown may be aborted at any time by using @abort-shutdown.
Syntax: @toad <player> [graylist|blacklist|redlist] [commentary]
@toad! <player> [commentary]
@toad!! <player> [commentary]
Resets the player flag of <player> (thus causing <player>
to be booted), resets the .programmer and .wizard flags, chowns the
player object to $hacker, and removes all of its names and aliases
from $player_db.
You must give either the player's full name or its object number.
Also, this command does not let you @toad yourself.
A message will be sent to $newt_log, containing a list of sites the
player has connected from, and the commentary if you provided any.
In some cases you may wish to add the player's last connected site to
the site graylist, blacklist or redlist -- see `help blacklist' -- in
order to invoke various kinds of blocking on that site (e.g., if
player creation is enabled, you may want to enter the player on the
blacklist to keep him from immediately creating a new character).
Specifying one of the listnames `graylist', `blacklist' or `redlist'
will do this.
@toad! <player> is synonymous with @toad <player> blacklist
@toad!! <player> is synonymous with @toad <player> redlist
There are messages that one may set to customize toading. After all,
a toading is (supposed to be) a rare event and you will doubtless want
to put on a good show. Thus we have
@toad [{list}]
Printed to everyone in the room in which the victim is being @toaded.
If you're worried about accidentally toading yourself in the process of
setting this message, see above.
@toad_victim [Have a nice life...]
Printed to the victim.
These are pronoun_subbed with victim == dobj.
Syntax: @denewt <user> [commentary]
Synonyms: @unnewt
@get-better
@denewt reverses the effects of @newt, moving a user's :denewt_confunc
back to :confunc, but checking first that :confunc is the same as
$wiz_utils:newt_confunc (if not, we save :confunc as :newt_confunc and
complain).
Mail is sent to $newt_log including any commentary you provide. E.g.,
@denewt Twit He promises not to do it again.
Syntax: @untoad <object> [as <name>,<alias>,<alias>...] Synonym: @detoad Turns the object into a player. If the name/alias... specification is given, the object is also renamed. In order for this to work, the object must be a nonplayer descendant of $player and the new object name (or the original name if none is given in the command line) must be available for use as a player name. As with ordinary player @renaming, any aliases which are unavailable for use as player names are eliminated. If the object is a descendant of $guest, then it becomes a new guest character. Otherwise the object is chowned to itself. In the latter case, it is advisable to check that the .password property has something nontrivial in it. If the object is a descendant of $prog, then its .programmer flag is set. Note that the .wizard flag is not set under any circumstances.
Syntax: @grepcore <pattern>
@who-calls <verbname>
@grepcore pattern is @grep pattern in {all core objects}. Core
objects are computed for you by #0:core_objects().
@who-calls greps for the verbname + "(", hoping to catch it as a verb
call. Currently @who-calls does not allow you to restrict the search
as @grep does. (Volunteers?)