abode
bogus builder
cheatsheet chown_ok control costs
dark drop drop-to
examine
failure flags
gender get give go goal gripe
haven help home homes
inventory
jump_ok
kill kill_ok killing
link_ok linking look
man money mucker
news
objectmatching outputprefix outputsuffix
page pose propdirs propdirs-example put
quell quit
rob robbery
say score sex startingout sticky strings substitutions success
timestamps types
vehicle
whisper who wizard
zombie
@password drop examine get give go goal gripe help home inventory kill look money news page pose put quit rob robbery say score startingout whisper who
"@set me=sex:female" (or "@set me=sex:neuter" to be an 'it').
Igor falls down.
In the second form, with the <message>, the user receives a message like: '<pager> pages, "<message>" to you.' Your location is not revealed in message pages.
If a player is set HAVEN, you cannot page them. You will instead be told, 'That player does not wish to be disturbed.'
Note: Most systems use a MUF program with a global 'page' action, which takes the place of the built-in 'page' command, and has more features. Usually, you can see the extra features of this MUF page program by using the command 'page #help'.
Note: Most systems use a MUF program with a global 'whisper' action, which takes the place of the built-in 'whisper' command, and has more features.
In the second form, attempts to get <object> from the given <container>. The _/clk lock property on <container> is tested, and if it is true, then it checks to see if the standard _/lok lock property on <object> tests true. If both locks pass, then <object> is moved into the player's inventory. If there is no _/clk property on <container> it defaults to failing. The _/lok property, on <object>, on the other hand, defaults to passing. @succ/@fail messages are not displayed, when fetching something from a container.
TAKE can also be used instead of GET.
You can also put programs in containers, much the same as you can with things. Throw and put can be used instead of drop.
If the thing's STICKY flag is set, it will go home when dropped.
If the room's drop-to is set, and the room has it's STICKY flag set, then the thing will stick around in the room until all players have left. If the room is not set sticky, then the thing will be sent to the location given by the room's drop-to.
You can also drop programs, much like things, but they are not affected by room droptos or STICKY flags.
An '@drop' message can be set which will be shown to the player dropping the object, and an '@odrop' message can be set, which will be shown to the other players in the room. Throw and put can be used instead of drop.
2) Find pennies.
3) Get killed.
4) Be given money by another player.
5) Rob someone. Once you reach 10000 pennies, it becomes difficult to acquire more. Wizards don't need money to do anything.
If you do not control <object>, it prints the owner of the object.
If you control <object>, examine will give you a complete breakdown of all standard fields, flags, etc that are associated with the object. MPI in the the displayed fields will be shown raw, without executing it.
If the optional proppattern field is supplied, then it instead lists out all the properties that matches the given wildcard pattern. If the pattern ends with '/' then all the sub-properties in the matching propdirs will be listed. If the pattern ends with **, then all sub-propdirs of the matching properties will be shown recursively.
ex obj=/ list all root properties on obj. ex obj=/** list ALL properties on obj. ex obj=foo/ list all properties in the foo propdir on obj. ex obj=foo/** list all props in the foo/ propdir, and all contained dirs. ex obj=foo*bar list root props whose name start with foo and end with bar.
The first letter following an object's ID number indicates the type: P(layer), E(xit), F(orth program), or R(oom). Otherwise it's a Thing.
Each object has an ID number (the 'dbref'), which appears after the name of the object, and is followed by any flags on the object; Ie: Foo(#3672PB) is a Player, named Foo, set BUILDER. The number is a database reference, and is used to specify objects at a distance; Ie. 'examine #3672'. You will only see the ID number of objects you own, or which are set LINK_OK, ABODE, or CHOWN_OK. Wizards can see the numbers and flags on all objects.
There are a few things to keep in mind, in relation to the above:
a) Anybody can @chown an unlinked exit to themselves, even if it is locked.
Builders should beware of this, lest their exits be linked or stolen.
Once the object has been chowned, then it will be controlled by the
owner, as per rule 1.
b) Players can @chown to themselves any exits which are linked to an object
they own. Note Rule #1.
c) Players can @chown to themselves any exits which are attached to an object
that they own. Note Rule #1.
d) If an object is set CHOWN_OK, anyone may "@chown <object>=me" and gain
ownership and control of the object. (see chown_ok)
@open sit
@link sit=here (because unlinked exits can be stolen)
@lock sit=me&!me (therefore always fails)
@fail sit=You sit on the chair.
@ofail sit=sits on the chair.
Since nobody can go through it, it always fails. The @fail message is
displayed to the player, and the @ofail message (preceded by the player's
name) to everyone else.
%a (absolute) = Name's, his, hers, its.
%s (subjective) = Name, he, she, it.
%o (objective) = Name, him, her, it.
%p (possessive) = Name's, his, her, its.
%r (reflexive) = Name, himself, herself, itself.
%n (player's name) = Name.
Capitalized pronouns are also available with %A, %S, %O, %P, and %R.
If you need a '%', use %%.
The naturally supported genders are 'male', 'female', 'neuter', 'herm', and 'hermaphrodite', with the last two being equivalent, both using the sie/hir/hirself/hirs pronoun set.
This set of supported genders can be extended either on an individual player, or globally by adding _pronouns/GENDER/%X properties on the player, or on #0 respectively. For example, to add support on yourself for a 'stallion' gender, you would add five properties, one for each of the %a, %s, %o, %p, and %r pronouns, in the _pronouns/stallion/ propdir. Ie:
@set me=_pronouns/stallion/%a:his
@set me=_pronouns/stallion/%s:he
@set me=_pronouns/stallion/%o:him
@set me=_pronouns/stallion/%p:his
@set me=_pronouns/stallion/%r:himself
If a shapeshifting player decided that they prefer a different subjective
pronoun for themselve while they were in herm form, they could override it
with something like:
@set me=_pronouns/herm/%s:shi This would only override the %s pronoun while their gender was 'herm', though, meaning that if they shapeshift to male, they only have to change their 'sex' property, and not tweak their pronouns as well.
If a player sets a %a, %s, %o, %p, or %r property on themselve, that value WILL be used, instead of any matching _pronouns/GENDER/%X property. This lets players make quick temporary pronoun fixes, and is also available for legacy reasons.
Ex. '@ofail teapot=burns %p hand on the hot teapot.'
@link <exit>=home
Drop-tos can also be set to 'home'. @teleport accepts home as an argument,
so you can @teleport things (and players if you are a wizard) to their home.
Examples:
@lock thingy=*Igor
@lock thingy=me|#1234
@lock here=me|Other Thingy
@lock west=sex:female
@lock east=((*Igor|*JohnDoe)&sex:male)
@set does one of three things on TinyMUCK, it can modify flags, add properties to an object, or remove properties from an object.
Using the first format, you may set flags, which are: ABODE (AUTOSTART) BUILDER (BOUND) CHOWN_OK (COLOR) DARK (DEBUG) HAVEN (HARDUID) JUMP_OK KILL_OK LINK_OK MUCKER QUELL STICKY (SETUID) VEHICLE (VIEWABLE) WIZARD XFORCIBLE ZOMBIE
You can also set the MUCKER (or Priority) Level of an object by using 0, 1, 2, or 3 as the flag name.
The second format sets <property> on <object> to <string>
The third format will remove <property> and any sub-properties under it.
The fourth format removes all properties from an object.
@propset can set and clear properties from an object.
If the first format above is specified, the @propset command sets <property> on <object> to <value>, where <value> is of type <type>. <type> can be one of 'string', 'integer', 'float, 'dbref', or 'lock'. A string can be any set of characters the MUCK recognizes. An integer must be composed solely of numerals with the possible exception of a leading sign indicator (+ or -). A float must be a valid floating point number. A dbref must be of the form # followed by a positive integer, and it must be a valid dbref (i.e., the object must exist). A lock value must be a key that would be accepted by @lock or a similar command (see the help for @lock for more details).
The second format removes <property> on object. Note that if <property> is a propdir, it removes all properties below <property> as well. If you wish to clear the value of a propdir without removing the properties below it, use '@propset <object> = integer:<property>:0'.
Examples:
@chlock here=*Igor
@chlock thingy=*Igor|*JohnDoe|me
@chlock here=!sex:neuter
@chlock here=me|((*Igor|*JohnDoe)&sex:male)&!_flight?:yes
Flags or types can be specified, to specify that you only want to list objects that have that flag set, or that are of that type. You can also specify to list objects that are NOT of that specific type, or that do NOT have that flag. (A "!" before the modifier indicates that it is to be inverted.)
The flags that you can specify are: (use the initial capitalized letter only)
Abode, Builder/Block, Chown_ok, Dark/Debug, Haven, Interactive, Jump_ok,
Kill_ok, Link_ok, Mucker, Quell, Sticky/Silent, Vehicle, Wizard, Xforcible,
and Zombie.
You can also specify Mucker Levels by the level number: 1, 2, 3, or 4.
The types that you can specify are: (use the capitalized letter only)
Exit, muF program, Garbage, Player, Room, and Thing.
There are a few other modifiers you can specify: (use only initial character)
Unlinked will specify that you want to list only unlinked objects.
@ specifies to list objects longer than about 90 days old.
~size will match all objs whose current memory usage is greater than
or equal to size bytes. This must be the last modifier in the
list of modifiers.
^size will match all objs whose total memory usage, when fully loaded,
is greater than size bytes. To do this, it loads the entire
object into memory from disk. This modifier is only available
to wizards. For regular players, this acts like ~size. This
must be the last modifier in the list of modifiers.
The output types that can be given are owners, links, size, count, & location.
(You use the whole name for output type, and you can use only one at a time.)
owners lists who owns each object.
links shows what each object is linked to, or *UNLINKED*, or, for exits
linked to multiple things, *METALINK*
size displays how much memory is currently being used by an object. If
this option is used with the ^ modifier, (see above) then this
will display the true full size of the object, and not just how
much is currently being used.
count causes nothing to be shown but how many objects the @find/etc would
match. ie: it doesn't display any of the matched objects.
location shows where the object is located at.
The matching on names is as follows:
Individual words can be matched as {word1|word2|...}
Individual characters can be matched as [abc...]
A ? matches any character.
A * matches any number of characters, including none.
Any of these special charcters can be matched by putting a \ before it.
Examples of use:
"@find north = EU = location" will find all of your unlinked exits named
"north" and print them along with their locations.
"@find {big|little} = R!L" finds all your rooms whose names contain "big"
or "little" and are not LINK_OK.
"@find w[ei]ll" will find everything you control whose name contains "will"
or "well."
"@find =E=links" will list all exits that you control, and display where
they are linked to.
"@find button==locations" will list all objects you control with 'button'
in the name, and it will display where thay are located at.
"@find =~2000=size" will list all your objects whose current memory usage
is 2000 bytes or more, and it will display their size.
"@find =^2000=size" will, for a wizard, find all objects in the db that are
2000 or more bytes in total size, when fully loaded, and it will show
their sizes. Note that this will load all of each object into memory
to make the size determination. On some systems this can take a while,
and on all systems this is an abuse to the diskbasing cache. Only
Wizards may use this search feature.
For an explanation of the flags/types modifiers and the output types, see the help entry for @FIND.
Example: @owned Revar=F!L3=location
Will list all Mucker Level 3 (3) programs (F) owned by revar, that are NOT set Link_OK (!L), and it will show the location of each one.
Note that only wizards can do an @owned on other people.
For an explanation of the flags/types modifiers and the output types, see the help entry for @FIND.
Example: @contents here=DE=owner
Will list all Dark Exits who's source is your current location, giving the owner of each one.
For an explanation of the flags/types modifiers and the output types, see the help entry for @FIND.
Example: @entrances here=ED=location
Will list all Dark Exits that are linked to your current location, giving the location of each one.
abode builder chown_ok dark flags haven jump_ok kill_ok killing link_ok mucker quell sticky vehicle wizard zombie
When set on a program, it means AUTOSTART. This means that when the game is first started up, the program will automatically be run with a trigger of #-1 and a 'me @' of the owner of the program. This is useful to restart processes that run in the background periodically.
When BUILDER is set on a program, it is called "BOUND" and it causes any functions within the program to run in preempt mode, regardless of the multitasking mode that the process had before calling this program. When the execution exits this program, the multitasking mode returns to what it was before the function was called. This lets libraries of atomic functions be written.
When the mucker level of an exit is set, is it called the exit's priority level. The priority levels let you specify that certain exits are not overidable by local actions. When an exit is searched for, in the matching routines, it will match like it used to, except that if it finds an exit, later in the search order, that has a higher priority level, it will choose that exit instead.
You can set the priority level of an exit by setting its Mucker Level. (ie: @set exit=2) A level of 0 is the lowest priority, and a level of 3 is the highest priority. Only a Wizard can set the priority level of an action or exit.
When the server looks for the standard "connect", "disconnect", or "look" actions, it will ignore any actions with a priority Level of 0. When an action is @attached to another object, @named to something else, or @unlinked, its Priority Level is reset to 0.
If COMPATIBLE_PRIORITIES is #defined on your system, then exits that are on room or player objects will never act as if they have an effective priority level of less than 1.
A player can set themselves "SILENT" and not see all the dbrefs and dark objects that they own. They won't see objects in a dark room either. They still control the objects though. Silent is the same flag as STICKY.
Things with the ZOMBIE flag set cannot enter rooms or use exits that have the ZOMBIE flag set. This allows a way to prevent zombies from entering areas where they are not wanted.
If you try to run a program that you control, that has its ZOMBIE flag set, it will drop you into the MUF debugger. This lets you step line by line, or instruction by instruction through a muf program, setting breakpoints to stop at, and other nice things. There is help available within the debugger, via the 'help' command.
gender propdirs propdirs-example sex strings
examines. To examine the properties on an object, use 'ex <obj>=<propdir>'.
where to examine the base properties in an object, <propdir> would be '/'.
You can see the value of a single property with 'ex <object>=<propname>'.
Propdirs are a method of storing and organizing properties to speed
access and to provide a sort of built-in organization. The basic idea
is to make something similar to a 'filesystem' for properties. In this
analogy, each person would be a filesystem, with a root directory and
(theoretically) an infinite number of properties beneath that.
A property has been expanded with the idea that each property may now
contain a new property list -- the 'propdir'. properties can both have
a value (either integer or string as before) _and_ contain other
properties.
The actual directory entries may ALSO contain data. Propdirs' only
real 'visible' changes are in the names of properties -- '/' is used as
the property directory separator, and so will not appear in the names
of the properties when listed through 'examine' or MUF programs.
Property protections have also been expanded -- the . and _ may appear
either at the beginning of the property name or immediately following a
'/', and that property will have the appropriate protections. For
example, the property '/mail/.inbox/mesg/#' would have the same
protections as '.mesg#' would now.
There are two ways to remove a property list:
* First, and most straight forward, is to remove the property that
contains it. so, in the previous example, removing the property
'/mail/.inbox' would (recursively) remove all properties under
.inbox before removing .inbox itself.
* The second way is to remove all properties within the property list
yourself. When the last property is removed, the parent property
(the one that contained the property list) is examined to see if
contains data. If it does, then the property list only is
removed. If the property doesn't contain data then it is removed
also.
Because of the first method of removing propdirs, the ability to have a
property list and value in the same property should be used sparingly.
If you try to access a property ending in '/', in MUF, it will give a
programmer error, except in NEXTPROP, in which it will give the name of
the first property in that propdir.
The last visible, non-MUF change that propdirs bring is that 'examine'
will no longer show properties _directly_. Instead, where the properties
would normally be shown, it will say:
"[ Use 'examine <object>=/' to list root properties. ]"
Examine now can take an argument which is the property or propdir to
view. If the property name given ends with a '/', all properties in
property directory will be listed, otherwise the single property named
will be shown.
Internally, a few things changed. property lists are now stored as AVL
trees instead of straight lists, so there is a speed increase even if
propdirs are not directly used. This also means properties are kept in
sorted order and will be displayed that way.
'addprop' will no longer allow a ":" in the property name.
To clear a propdir's value without deleting the proptree below it,
from MUF do a '"" 0 addprop' to it.
A property can *not* have both a string and integer stored at the same
time anymore. The old property.c was lax and allowed this, even though
the integer value would be lost on dbload.
See also PROPDIRS-EXAMPLE.
Lines indented 6 spaces are what the MUCK is returning to the user.
Lines in []'s are comments on what's going on.
[first, lets set up a bunch of properties]
@set me=first:a property.
@set me=second:another property.
@set me=first/one:A property in a propdir
@set me=first/two:Another property in a propdir
@set me=third/prime:three
[Okay, now lets see what properties we have. We use the examine command
to do that, with a second argument, to tell it what we want to list in
the way of properties. In this case, since we want to list the base level
properties, we use '/'.]
ex me=/
first/: (string) a property.
second: (string) another property.
third/: (no value)
[Okay, it has a few properties with the first part of the names of the
properties that we set. The /'s at the end of some of the property
names means that there are sub-properties that we can list. When we
set a property like 'first/one', it's actually creating a sub-property
named 'one' beneath a property named 'first'. If 'first' doesn't
already exist, then it will create that property. Let's list what
sub-properties we created under 'first'.]
ex me=first/
first/one: (string) A property in a propdir.
first/two: (string) Another property in a propdir.
[Here we see the properties that we set as sub-properties under 'first'.
We examined for 'first/' to list the sub-properties. The / at the end
of the name tells the game that we want it to list the sub-properties
of that property, and not that property's value itself. Lets see what
value the property 'first' has, itself. To do this we leave off the '/']
ex me=first
first/: (string) a property.
[Okay, lets say that we just want to see the value of the sub-property
named 'one', under the property 'first'. We can list it as follows:]
ex me=first/one
first/one: (string) A property in a propdir.
[If the property or sub-property that you specify does not exist, it
will complain about it.]
ex me=first/three
No property found.
[if a property was created to contain a sub-property, but was never given
a value itself, it is listed as having no value. It has sub-properties,
however.]
ex me=third
third/: (no value)
[Let's list those sub-properties.]
ex me=third/
third/prime: (string) three
[Okay, let's delete the sub-property 'prime', from under the property
'third'. To do this, we act like we are setting the variable again,
except that we are giving it no value this time.]
@set me=third/prime:
ex me=third/
No properties listed.
[There. It's gone. Now let's list the bottom level properties again.]
ex me=/
first/: (string) a property.
second: (string) another property.
[Whoops! The property 'third' is gone too! This is because properties
with no values are automatically deleted when their last sub-property
is deleted. Let's delete a subproperty from 'first', now.]
@set me=first/one:
ex me=/
first/: (string) a property.
second: (string) another property.
[The property 'first' still exists, with it's string value, and it still
has sub-properties. Lets list those.]
ex me=first/
first/two: (string) Another property in a propdir.
[Here we see that the sub-property 'one' is gone, as we expected. Let's
see what happens when you erase a property that has sub-properties.]
@set me=first:
ex me=/
second: (string) another property.
[The property 'first' is gone.]
ex me=first/
No properties listed.
[And the subproperty it had is gone too! Let's remake the 'first' prop.]
@set me=first:again, a property.
ex me=/
first: (string) again, a property.
second: (string) another property.
[We have two properties again, and no sub-properties. It should be
noted that sub-properties can have sub-sub-properties, and they can
contain even subbier properties, and so on and so forth.]
@set me=first/one:uno
@set me=first/one/example:dos
@set me=first/two/example:tres
@set me=first/one/example/cat:meow
ex me=first/
first/one/: (string) uno
first/two/: (no value)
ex me=first/one/
first/one/example/: (string) dos
ex me=first/one/example/
first/one/example/cat: (string) meow
[There is a special case in examine to let us list ALL the properties and
sub-properties of a prop. To use it, we just specify '**' as a propdir.
For example, to list all sub-properties and sub-sub-properties, etc.,
under 'first', you would do the following:]
ex me=first/**
first/one/: (string) uno
first/one/example/: (string) dos
first/one/example/cat: (string) meow
first/two/: (no value)
first/two/example/: (string) tres
[Let's delete all the properties on the object, now. To do that, we
specify no property name or value when we use @set. Nothing but a
colon.]
@set me=:
ex me=/
No properties listed.
[All gone!]
2) a description. (stored in _/de property)
2) an inside description (for vehicles). (stored in _/ide property)
3) a success message (seen by the player). (stored in _/sc property)
4) a fail message (seen by the player). (stored in _/fl property)
5) an osuccess message (seen by others). (stored in _/osc property)
6) an ofail message (seen by others). (stored in _/ofl property)
7) a drop message (seen by the player). (stored in _/dr property)
8) an odrop message (seen by others). (stored in _/ofl property) (see properties)
@edit @kill @list @mcpedit @mcpprogram @program @ps man
@armageddon @bless @boot @delta @dump @force @newpassword @pcreate @restart @restrict @shutdown @toad @unbless @usage @wall
With the compile option GOD_PRIV, God cannot be forced by anything except God owned, wizbit programs.
This is a wizard-only command.
Blesses all properties on <obj> that match the given <proppattern> wildcard pattern. The wildcard pattern works similarly to how the examine patterns work. ie:
@bless obj=/** blesses ALL properties on obj.
@bless obj=foo/** blesses all props in the foo/ propdir, and all propdirs
under the foo/ propdir, recursively.
@bless obj=foo*bar blesses all root props whose name start with foo and end
with bar.
The @bless command will list all properties that it blesses.
Blessed properties can execute MPI code with elevated permissions, allowing scripts that can alter remote objects, and those objects not controlled by the trigger owner. Blessed MPI can also use {force} on anyone.
Blessed _msgmacs properties don't execute with blessed permissions when they are referenced from other MPI code. Instead, the bless bit on _msgmacs props indicates only that that macro is available to scripts up the environment, even if the script's trigger is not the same as the owner of the environment room the _msgmacs prop is on.
This is a wizard-only command.
Unblesses all properties on <obj> that match the given <proppattern> wildcard pattern. The wildcard pattern works similarly to how the examine patterns work. Ie:
@unbless obj=/** unblesses ALL properties on obj.
@unbless obj=foo/** unblesses all props in the foo/ propdir, and all
propdirs under the foo/ propdir, recursively.
@unbless obj=foo*bar unblesses all root props whose name start with foo
and end with bar.
The @unbless command will list all properties that it unblesses.
Blessed properties can execute MPI code with elevated permissions, allowing scripts that can alter remote objects, and those objects not controlled by the trigger owner. Blessed MPI can also use {force} on anyone.
Blessed _msgmacs properties don't execute with blessed permissions when they are referenced from other MPI code. Instead, the bless bit on _msgmacs props indicates only that that macro is available to scripts up the environment, even if the script's trigger is not the same as the owner of the environment room the _msgmacs prop is on.
cheatsheet costs outputprefix outputsuffix
@dig: 10p
@create: 10p (or more, up to 505p)
sacrifice value=(cost-5)/5
@find, @owned: 100p.
@link: 1p (if you didn't already own it, +1p to the previous owner).
@open: 1p (2p if linked at the same time).
Wizards don't need money to do anything.