Also see: @add-owner in Manager Help
Use: @check-for-core <name>
or: @check-for-core <core id>
where <core id> is the object's unique name in its unique_id[1] (see 'help unique-id').
Additional comands for core object testing are available as feature verbs on $core_utils. See 'help $core_utils' and '@about $core_utils' or '@mailme $core_utils' for details.
The "@add-class" and "@add-class-object" commands are available for adding a new class (catagory) or object to a class, to be displayed by @classes.
The @classes command uses the values in #0.class_registry ($class_registry).
$class_registry is in the following format:
{ {name, description, members}, ... }
where `name' is the name of a particular class of objects, `description'
is a one-sentence description of the membership of the class, and `members'
is a list of object numbers, the members of the class.
Related Topics:
@add-class -- add a new
class of objects
@rm-class -- remove one
@add-class-object
-- add an object to a class
@rm-class-object --
remove one
Also see: @classes in Builder Help
Gives information identifying a core object. This can be used either to check if a given object is part of the base core or a core option, or to get the object number for a given core id name. If given the object name, outputs the object's unique ID. If given a core id name, the object number and name is displayed. Also indicates whether this object can be referenced by $<name>.
Use: @corify <object> as [$]<name> [<core-option>]
where <object> is the object number of a name found by my_match_object, <name> is the unique ID of the object which must be different from any other core or core option object, the $ prefix is used if the object ID is also to be a property on #0, and <core-option> is the core options set if this object is to be a part of an option rather than the base core. See also 'help unique-id'.
Note that once corified, the object can be referenced by &<name>. This is useful for referencing objects on linked sites using the DUcore because it is independent of the object number.
The @uncorify command is used to remove an object from the base core database or a core option, to remove it's unique ID, and remove all references to its name to the registered name data base. This should be done before any such object is recycled or replaced by another object which is to replace it in the core db.
Use: @uncorify <object>
NOTE that the core extraction system at this MOO differs from that on the standard LambdaCore. In particular, an object number reference on #0 is no longer sufficient for it to be part of the core. Also, if you omit the "$" ahead of the <name> when using @corify, then the object will NOT be added as an object number reference on #0. See '@about $core_utils' or '@mailme $core_utils' for details.
| Syntax: | @email-access <who> is <access> |
Related Topics:
email-permeability - overview of the system
| Syntax: | @manager <person> for <responsibility> |
If you don't specify a responsibility, you'll be told which responsibilities the person already has and which are available. Specifying "nothing" as the responsibility will remove the person from the Manager class entirely. Specifying a responsibility with "!" prefixed means to remove that responsibility from the person.
Note that some abilities apply to all Managers, and there is no setting for them. These include: @shout.
Assignable responsibilities are:
nothing - if the person isn't already a Manager, this makes them a Manager but with no areas of responsibility assigned. If the person is a Manager, then all areas of responsibility are removed. Note that the @unmanager command is used to remove someone's Manager status completely.
character applications - the Manager can access the *character-request-pool. *created, *reject, and *undecided mail folders and use @created and other commands to process character applications.
VSPO management - the Manager can create and destroy VSPO groups, as well as perform VSPO group management functions on any group.
builder management - the Manager can confer or remove builder permissions, and also can set people's building quota.
programmer management - the Manager can confer and remove programmer permissions (progbits).
rooms and exits - the Manager can add and remove exits from any MOO room, allowing them to manage MOO building activities.
ownership transfers - the Manager can transfer objects from one person's ownership to another. Note this gives @recycle ability indirectly.
access restrictions - the Manager can control user access functions including @unlock-account, @boot, and @newt.
server management - the Manager has permission to shutdown and force checkpoint backups of the MOO.
Administration and policy - the Manager has responsibility for DU MOO administration and policy development. Note this doesn't provide access to any new commands, and is strictly for informational purposes.
---------
| Syntax: | @unmanager <person> |
Related Topics:
@managers -- which Managers
are connected (or list all)
manager-summary --
list of commands available to Managers in each
area of responsibility
Related Topics:
$object_quota_utils
-- the utility controlling quota under object-based quota
$byte_quota_utils --
the utility controlling quota under byte-based quota
Also see: @quota in Manager Help
Use: @register-name <object> as [$]<name>
where <object> is the name or object number of an object, <name> is the unique ID of the object which must be different from any other core or core option object, the $ prefix is used if the object ID is also to be a property on #0.
Wizards have the additional requirement of adding a help text to the appropriate database for all command line verbs on generic user characters. See "@kids $generic_help" for the list of databases.
Such verbs should NOT have any header lines, but instead be solely documented through the help database system. This is because the Undocumented Help System ($undoc_help) will find help in both places and ask the user which they wish to see. Just put all the documentation (except internal verb comments) in a help database text.
It is VITAL that help texts have a format that allows them to
be properly extracted for HTML format, which means that they should follow
the format given below. Note that help texts for other than commands don't
need to fit the format given, but *do* need to follow the rule that a double-hyphen
may only be used to demarcate a reference to another help topic. The format
for help database entries is as follows:
__________
| Syntax: | <command> <arguments....>
<command variation> <arguments....> |
Explanation of what command is for, including its variations.
[Examples: <example or examples here>]
Related Topics:
<help topic> -- short description of topic or command
__________
| Syntax: | The titles given (e.g. "" or "Related Topics") are not suggestions! These are keys scanned for by the system that extracts the eDUcore manual (all the help texts) and if you don't use them exactly, it creates errors in the extracted manual. An example of two types of Usage is "@eject" and "@eject!" where the varients have slightly different effects. The "Example" line is optional, and only needed when the "Usage" line is complex. Multiple "Usage" and "Example" lines may be used when appropriate. |
When creating a multi-part help text across several help databases, add a "Notes for <class>" line followed by a blank line (see this text as an example). This indicates to the user that the following text applies specifically to a certain <class> of character (e.g. Wizards, Managers, etc.). The <class> should be derived from the class that the particular help text database is for.
IMPORTANT: Note the two hyphens after the <help topic> in the "Related Topics" section. The automatic hypertext help system uses these to identify command names that can be used to point to addition help texts, and assumes that left of the double hyphen is a single word that is itself a valid help topic. Use a single <help topic> per line. Never use a double hyphen in a help text *except* to demarcate a related help topic!!
Also see: documentation in Programmer Help
@manager-access *<mail-folder> to <access>:<manager_area>
where <access> is one of readers, writers, moderators, or
unsealed_for, and <manager_area> is one of the Manager areas of
responsibility (property names on $manager ending in "_ok"). If you
feed the command junk, it will tell you allowable settings.
Also see: mail-recipients in Builder Help
| Syntax: | make-core-database |
wiz-tuned - shows who's currently listening on the [wiz] channel
wiz-tune - used with "in" or "out" to tune in or out of the wiz-channel
wiz - speak using the [wiz] channel
wiz: - emote using the [wiz] channel
wiz! - speak with emphasis on [wiz} channel