Wizards' Guide

This simple guide is provided for the wizards who will build this game. (Right now, that's you, Fade and Guyman. <G>) Of course, I'll try to make it general, after all, I do want this to be a general guide for anyone using my system.

The first thing to understand is that this is an RPG system. It is only a Monster Rancher game because that's what I (as a wizard) have created it to be. It could be a starship, a sword and sorcery world, or anything else. The concept of this game is based on the idea of a MUD, or Multi-User Dungeon.

Specifically, this is based on an object oriented MUD. What this means is that everything on the game is based on the Object, a common class that give the objects their common properties. In fact, part of the definition of an Object is that it contains Properties, name/value pairs that establish attributes for an object in the game.

Each object in the game has a unique identifier associated with it, the Database Reference or dbref. The reference always consists of the "#" symbol, followed by a series of digits, and a final letter that indicates the object's type. The dbref is unique to each object, is never duplicated, and can be used to refer to that object from any location. Note that although a name can start with the "#" symbol, it should not, unless the name is itself the dbref.

The ending letter of a dbref is "R" for a Room, "I" for an Item, "N" for an NPC, "P" for a Player, and "E" for an Action. (The "E" stands for "exit") If the user is a wizard or builder, he will be able to see the dbref of all objects listed by "inv", "exits", "who", or in the lists to the right of the screen.

What kind of Objects are there?

There are only five kinds of objects: Rooms, Items, Players, NPCs (that's short for Non Player Character) and Actions.

Rooms are the Objects that provide setting and location to the game. Rooms can contain Items, and can have Actions linked to them. Rooms can also link to other Rooms, allowing the user to "overlook" that room.

Items are Objects that have location. An Item can be placed in a Room or in another Item. Items can also have Actions linked to them.

NPCs are Items that are able to move about and take Actions. Unlike Players, NPCs are not under the direct control of a player, but they are the same type of Object. In fact, NPCs are the same type of object as a Player, with its "robot" flag set, but it can be thought of as a different type.

Players are the player's interface with the game. Each player of the game has a Player object associated with them, which represents their position and status in the game. Players, like NPCs, are also Items, and so they can contain other Items (even other Players!) and can have Actions linked to them.

Actions are the Objects that Players use to manipulate the game. Although there are several built-in commands in the game ("look", "get", and so on) you can add commands to the game at any time by creating an Action. When the player types in the name of an Action that he has access to, the Action will be performed.

Most Actions take the form of exits from one Room to another. The player has access to any Action that he is linked to, that an object in his inventory is linked to, or that the Room he is in is linked to. So, if an action named "north" is in the room, the player goes north by typing the name of that Action.

Of course, the Action must then link to the Room that is north of the player's position. This is the default action of an Action, it moved the player to the new room. But it is actually possible to program an Action to perform more complex operations. This will be described later.

It's also important to note that Actions are inherited from an Object's parent. The parent of most Rooms in the game is Room #0, Nowhere. So any Actions on this room are "global" Actions, which can be accessed from anywhere in the game. (Currently, "stats", "edit" (for players) and "create" are global Actions)

What are the common Properties?

All objects have a number of properties in common. These common properties come in three types: Text strings, Integers, and Flags. Properties themselves also come in two types, those that are inherited from their parent objects, and those which are not. All inherited properties start with the character "_", this is what indicates them as inherited to the game.

The following text properties are used to describe an object:

name - The name of the object. This value may never be undefined, but may be changed at will. It is important to note, however, that in some cases (mainly, if the object is not in the room) a link to the object may retain the old name until it is either "looked" at, or otherwise accessed.
_desc - This property is displayed when the user "looks" at the object.
_succ - This property is displayed whenever the user successfully uses the object. For an Action, it would be displayed when the user activates the Action, for an Item, it would be displayed when the item is picked up. A Room, however, uses this property to store its list of Exits. (Displayed to the upper right of the screen)
_fail - This property is displayed whenever the user fails to use the object. An object can be locked to a user with the "lock" property, at which time it would display this message when it was attempted to be used.
_drop - This property is displayed whenever the user drops the object. This is most commonly used with Items, which can be picked up and dropped. However, this property is displayed on a Player or an NPC when it is knocked out.
_osucc - The "Other Success" message, it is displayed to other players in the room when the object is used. See below.
_ofail - The "Other Fail" message.
_odrop - The "Other Drop" message.
lock - This value is converted using standard String Substitution (described in the Player's Guide) and if the value is "yes", the Object is locked. This may be used to lock an Object to any Player, any Item in their inventory, or any number of other conditions.
parent - The parent of this object. This is usually an Object of the same type as this object, and all Actions and inheritable Properties will be inherited by this object.
owner - The owner of this object. This must be a Player.
home - The "home" of this object. This is a remnant from the old MUD systems, and may not be useful. But if it is, this is a Room that the Object will go to if "swept".
location - May be abbreviated "loc" for most wizard commands. Only Items can have location. This is the item's current Room.

The "Other" properties described above are logged to the text file associated with the Player's current Room, with the name of the person using the Object prepended. That is, if the "_osucc" message for an Action "north" is "goes North", and "Ralph" activates that Action, then the message "Ralph goes North" will be logged.

Note that since the message is logged to the room, everyone in the room will be able to see the message either when they log on, or when they type "messages". The "_succ" message, of course, will be displayed immediately to the user, and as the user already knows that he is the one taking the action, nothing will be prepended.

The Integer Properties are:

health - As with Players, all Objects have a Health rating that indicates how close to destruction they are. Unlike Players, however, zero health indicates not destruction, but that the object cannot be damaged. At a future time, I may implement a feature to automatically destroy any Item or Action that is reduced to zero health, and have a Room that is so destroyed "crumble", doing damage to the Player. (And maybe even dumping him somewhere!)
energy - Again, this rating of Players is also common to all objects. Most Items and Actions, however, use the energy rating not to indicate how much energy they have, but how much energy they take to use or pick up. Rooms, if set to a value greater than zero, limit energy to that level when they are entered. (For instance, this is used in the Monster Rancher RPG to ensure that all monsters enter the Arena with no more than 50 energy)
level - The level of an object represents its difficulty to use. For instance, an NPC's level, as it gets higher, makes it more likely that it will disobey orders, and the level of any character reflects its ability to dodge as a player tries to move near it.
score - Only Items (and thus Players and NPCs) can have score. This represents their value. A Player's score is how much money he has, while an Item's score represents its worth.
heal - This value, valid on Players, NPCs, or Rooms only, effects the "regeneration rate" at which players recover health. The default is one point per "turn", but may be set higher. Not that a "turn" is normally a day, but can be set higher or lower by the Applet Parameters on the game's Web Page. For rooms, this value acts as a multiplier, so you can have special "healing" rooms where a character recovers twice or three times the normal amount of health. Note that if you set this value to zero, it will prevent any healing in that room. A negative value can also be used, to halve the rate, and so on.
recover - Just as heal sets the "recovery rate" for health, recover indicates the rate of energy recovery. Energy regeneration defaults to ten, much higher than healing rate. Depending on the situation, a character could have a rate higher or lower than the norm. The recover rate will effect how fast the player can fight and move, so you could make some players slow and ponderous, while others are speedy. Again, as with heal, if recover is set on a room it will act as a multiplier for the player's natural recover rate.
_uses - Only Actions can define this property. If this value is greater than zero, this is the number of times the action must be used before it can be "leveled up" by using one of its multiple names. See below.
_levelup - Again, only Actions can define this property. Indicates the additional energy cost per level required to "level up" the Action.

Finally, there are twelve flag properties that may be set to either "yes" or "no":

chown - If true, anyone can take possession of this object. If false, the current owner or a wizard must set the owner. This has not yet been implemented. (A "chown" command will probably be added)
link - If true, it is okay to link to this object. This also has not yet been implemented. (It is currently okay to link to any object)
home - If true, it is okay to set your home to this object. Again, has not been implemented.
hide - The item is invisible, and does not show up in the list of items displayed to the right. The "search" command will reveal hidden items. But neither this flag nor "search" has been implemented.
kill - It is okay to destroy this object. Not implemented.
large - This object is very large. Can be tested for in locks. If set on a Room or Action, will prevent any Actor for which the bit is set from entering. Also, when set on an Item, (but not a character) it makes the item immobile. Immobile items must be moved "next to" in order to use their Actions, instead of picking them up.
sticky - I had an extra bit, okay? "Sticky" comes from FurryMUCK.
robot - This important bit cannot be set on characters. It determines whether a character is a NPC or a Player. If used in a lock it can exclude NPCs, and it can be set on a Room, Action or Item to automatically exclude NPCs from using that object.
builder - If set on a Player, it gives them the ability to use the builder commands on objects they own, as well as make objects. Currently no effect on any other items.
wizard - If set on a Player, it provides access to the wizard commands. Wizards also automatically have ownership of all objects in the game, except for Sysop.
quell - Temporarily disables all builder or wizard powers. The player will still be able to see dbrefs, but will not see email addresses in the "who" list.

How do I add a Player?

Well, first of all, only those who are both wizards AND builders can create players. That most important of all tasks is reserved for a priviledged few. Assuming you have the proper flags set on your character (and only other wizard/builders can effect your flags...) here's how to create a character:

First, you will use the @make command to create the player. Then, you should make sure he or she is in a location where the new player will not become lost or confused. That's all you need to do, however, if the game is set up correctly, any stats the player needs to define will be automatically set by a "create" program run the first time he or she logs on.

For instance, to create a character named "Rover", for a player named "Ralph" who wants to use the password "abc123":


@make plyr=Rover:abc123:Ralph

The password is not optional, however, the player will be able to change it once he logs on, so you can enter anything. The purpose of the password is to ensure no one steals the new character before the player has a chance to log on. The new character will be in the same room with you. If this isn't a good room for him to be in, use @set to change his location. For instance, if you know that #10R is a room with lots of folks in it to help out the newcomer:


@set Rover:loc=#10R

As an added bonus, everyone in the room will see Rover appear in a puff of smoke, which should serve as a conversation starter. <G> Note that usually you have to specify a room by dbref since you can't usually see it from your current position.

How can I create a Room or a Magic Item?

Well, again, this is done with the @make command. And any builder can create Rooms or Items, not just wizard/builders. Its up to the builders to create the adventures that make a role playing game fun. And of course the builders also build the more ordinary environments like cities and towns.

To create a room, use the @make command to create the room. You can then teleport there with the @set command. To "walk" in and out of the room, however, you will have to create Actions that lead in and out of it. So, to create a house for yourself:


@make room=Home

You should make note of the dbref of the room created, which will be displayed to you. Let's say in this case it was #313R:


@make exit=enter
@link enter=#313R
enter

If you did it right, you should now be in your Home. You'll want an exit back to where you came from. Let's say that was #116R:


@make exit=leave
@link leave=#116R

Now you can type "edit Home" to define the description and other properties of your new room, and "edit leave" to edit the description of the exit that leads out of the room. You can leave the room and edit the "enter" Action, too.

To create Items, just use the @make command, and then "edit" to describe what it looks like. For treasure and other items that have no value but score, you don't have to do anything else. If you want to define a weapon or a magic item, though, you will probably want to attach some kind of a program to it. See below.


@make item=Chalice
@set Chalice:score=100000
edit Chalice

How to I create Non Player Characters?

Again, any builder can create a Non Player Character. There are actually two types of NPCs. The first type are henchmen, which follow a character around, and are used as a sort of secondary character under the control of the player. Builders, however, will often create an NPC to be a guard in a room, or to interact with the players as a shopkeeper or salesman.

Any NPC can be a henchman. In fact, any player can control a henchman, where he or she is a builder or not. The only requirement is that the player own the henchman, and since only builders can create NPCs, normal players must get henchmen from builders. The builder can "give" an NPC to another player by setting its owner:


@make npc=Frank
@set Frank:level=1
@set Frank:owner=Rover

Rover now "owns" Frank, and can set his description (with edit) and order him around with the "tell" command. The builder who created him cannot control Frank any more, unless he is also a wizard. He cannot even set his owner property any more, since you must own an object to set its properties. (Which is why the level of the NPC was set before the owner, above. If the builder wishes to call edit on the NPC, this should also be done before setting the owner)

Note that many games may require you to use an action to create NPCs. This ensures that the proper stats are set on that NPC. You should always follow the guidelines set by the game for henchmen. The more ordinary type of NPC, however, can be created directly.

What distinguishes a henchman from an ordinary NPC is the "level" of that NPC. Note that in the example above I set the new NPC's level to 1. This is the lowest level a henchman can have. It gives a beginning player (who should have a level of 1) a 50% chance to control that henchman. As the level of the player increases, the chance that the henchman will disobey decreases. But, if the NPC's level is 0, not only is there no chance that the NPC will disobey, but anyone else can access the NPC's Actions, (but only its Actions) as well.

So, let's say that you wanted to create an NPC to sell food:


@make npc=Counter Clerk
@set Counter Clerk:level=0

You'd probably also edit the clerk to set his description. You actually don't have to set the level, it defaults to 0, but I specified it in the example to make this clear.

Now we need some Actions to make the clerk give the player the food:


@make exit=Cheeseburger
@link Cheeseburger=Counter Clerk
@unlink Cheeseburger=here
@make exit=Chips
@link Chips=Counter Clerk
@unlink Chips=here
@make exit=Pepsi
@link Pepsi=Counter Clerk
@unlink Pepsi=here

You need to unlink the Actions from "here" because they were automatically linked to the Room when created, but you don't want them accessible that way. You would then create a program for each action. Programming is described below, but just as an example: (Assume you haven't unlinked Cheeseburger from the room yet)


@edit Cheeseburger:_program

(in the edit dialog type)
if %s < 10
{
    print Sorry, you don't have enough money!;
}
else
{
    set me:score=%eval[%s-10];
    @make item=Cheeseburger;
    @set item:_desc=It's a cheeseburger.;
    @set item:loc=me;
    print You now have a Cheeseburger.;
}

There is one very important thing to note here. If this NPC were a henchman, and you were to tell him to use one of his actions, the word "me" would refer to the NPC. In this case, however, it refers to the player, the person who said to the NPC, "tell Counter Clerk, Cheeseburger". This is similar to the use of items, and in fact, the NPC itself can be referred to as "item" in the program. (In the example above, "item" is redefined when you create the Cheeseburger) In order to be consistent, if an NPC is level 0, it will execute its Actions in this way, even if you own it.

Of course, if you own the henchman, it will follow your other orders as well. So you could tell the Counter Clerk to look around, go to another area, or whatever you wanted it to do. In addition, if the player said something to the NPC that it didn't recognize, (that is, it didn't say "Cheeseburger", "Fries", or "Pepsi") the message would be sent to you, and you could respond to it in your own turn. (Perhaps by having the clerk quote an old Saturday Night Live routine. <G>)

The "success" and "fail" messages are also used differently, depending on the NPC's level. A level 0 NPC will display its success message, if defined, whenever a player enters its location, or when the player logs on, if it is in the room with the player at that time. It will display its "fail" message (again, if defined) in response to a command it does not recognize. A henchman uses its success and fail messages to indicate to its owner whether or not it will disobey an order given to it with "tell".

Creating a guard is a little more complicated. Any exits from the room, or object that the NPC is intended to guard, should be locked to a property on the guard. For instance, this would probably be the most common use of a guard:


@set exit:lock=%prop[guard,health]
@set exit:_fail=The guard monster blocks your path to the door.

Because of a convenient coincidence, that "0" is interpreted as "no", and any other value is interpreted as "yes", the exit will be locked as long as the guard is conscious. The player will have to fight the guard and knock him out in order to leave the room. Of course, there are other possibilities. A Sphinx might ask questions, and if the user gets them right, set a property on the player that lets him go through the exit.

In order to allow NPCs to counter attack players that attack them, a "_program" property may be set on zero level NPCs, just like on Actions. This program will be executed the moment a player enters the room, and at the beginning of each turn, as long as the player is still in the room. A whole combat could take place, without the builder himself needing to get involved.

What are the builder commands?

There are several builder commands used to create and manipulate objects. All builder commands (and wizard commands as well) start with "@". It is important to note that unless a builder is also a wizard, he can only effect objects that he owns.

In addition to his other powers, a builder can see the dbrefs of any objects or players in the same room with him.

In the following table, I will describe the syntax for a command as follows: The symbols "<>" indicate a value that the user must substitute. The symbols "[]" indicate an optional value that may be left out.

@make <type>[=<name>]

Creates an object and adds it to the database. An Item will be added to the current Room. An Action will be linked to the current room. There are five type specifiers that may be used:

room - Room
item - Item
npc - NPC
plyr - Player
exit - Action

Only wizards can create players, and the name argument is NOT optional. In fact, the name argument must consist of a name, a password, and an optional real name and email address, all separated by colons: @make plyr=<name>:<password>:<realname>:<email>

@set <object>:<property>[=<value>]

Sets a given property on the object specified to a given value. The object may be specified by name or dbref, although it must be in the same room to be specified by name. If the value is left off, the property will be removed.

@ex <object>

Displays all properties on the specified object. The dbref will also be indicated. "Ex" stands for "examine".

@link <from_object>=<to_object>

Links an object to another object. Items are linked to by the Room or Item in which they are located, but they should never be moved by this command. Use @set <object>:loc=<object> instead.

@unlink <from_object>=<to_object>

The opposite of @link, it removes a link created previously. Note that when an Action is created, it is linked to by the Room. This link may need to be unlinked.

@destroy <object>

The opposite of @make, this command destroys an object. At this time, objects contained in a destroyed object may not be properly handled. Use with caution at any rate.

@edit <object>:<property>

A useful derivation of @set, this command takes the current value of the property and opens a dialog allowing the property to be edited. It can be very useful for multiline descriptions, and for Action programs.

@copy <from_object>[:property]=<to_object>

Copies the specified property from one object to another. If the property is not specified, all properties (except name and location) will be copied. Note that it may be more efficient to specify a common parent with an inherited property.

@read <filename>

Reads from the given file. Files may be used to save large volumes of text. There are also two special types of files. The help files, all of which start with the letter "h", are accessed by the player using the "help" command. The filename, minus the leading "h", should match the argument to the "help" command.

The other type of file is the "talk" file. These files, starting with the letter "t", are associated with objects, such as Rooms. The success and failure messages of objects, as well as the messages logged by the "say" command, are logged to the Room's talk file. The talk filename always consists of the letter "t", followed by the dbref of the Object. So the talk file for Nowhere (Room #0) would be "t#0R".

@write <filename>[=<text>]

Writes the line of text to the given file. If none is specified, deletes the file.

@append <filename>=<text>

Appends the line of text to the given file.

@import <filename>=<local_filename>

Imports a file from the player's computer to the database. While this is a very helpful command, it is usually prohibited, due to Java security restrictions. If the game displays a "Security Error" message, alter the permissions on your browser to allow unsigned Applets access to your file system. Don't forget to turn off this permission when you are done, this is an unsafe condition.

@export <filename>=<local_filename>

Exports a file from the database to the player's computer. As with "import", you may need to set permissions. On Internet Explorer, it is important to note that if you do not specify a drive letter, the file will be saved to your desktop. This can be useful. Also note that objects in the database can be saved by typing in their dbref as the filename. Such saved objects can thus be restored if corrupted, but do not try to create an object in this way. (It won't work)

@log <object>=<text>

Logs a message to the object's talk file. The @log command uses a special format that is displayed only if it was logged more recently that a time that may be specified by the application. This is how "say" and other messages are logged to the talk file.

@fedit <filename>

A very useful command that allows the user to edit a file in the database. It can be used to edit help files, talk files, or any other files the user may wish to place out in the database.

What are the wizard commands?

As mentioned above, the wizard's primary power is that he has ownership of every object in the game. Combined with the builder commands this makes a wizard very powerful. It is important to remember, however, that wizards do not ordinarily have access to the builder commands. And it should also be noted that only Sysop or another builder/wizard can set either the wizard or the builder flag.

Most of the wizard commands are concerned not with creation and manipulation of the game environment, but with the moderation of the players in the game. The wizard has powers that allow him to ban or otherwise control unruly players. Here are the wizard commands:

password <player>=<password>: While this is not strictly a wizard command, this use of the command is only available to wizards. The wizard is able to change the password of another player in this fashion.
who: Again, while this is not strickly a wizard command, only wizards will be able to see the email address portion of the player list.
@ban: This command has not yet been implemented.
@purge: This command has not yet been implemented.
@wall: This command has not yet been implemented.

How do I program an Action?

As mentioned above, the default result of an Action is for the player (and anyone following him) to be moved into the Room the Action links to. If the Action is not linked to a room, this fact will be displayed to the user, and nothing will happen. In order to perform operations other than movement, an Action must have a program.

An Action's program is a script, stored in the property "_program". Note that the program may be inherited from a parent. The script consists of a number of commands, which are very similar if not identical to the commands available to builders. Normally, only Actions can have programs, although an NPC can execute a program under the special circumstances described above.

Actions, and only Actions, can have multiple names, separated by semicolons. (In other words, a list) This is most useful with exits, as it allows to you specify common synonyms or abbreviations for an action, so the user doesn't have to remember an exact command. When used with a program, however, the multiple names capacity of an Action allows you to "level up" an action, an attack, for instance, to give multiple effects.

If an Action has multiple names, the index of the name used to activate the action is added to the level property of the Action for the duration of the execution of the program. Thus, for instance, if a fire Action attached to a Phaser, with a level of 0, were to be named "stun;disrupt;kill", typing "stun Alien" would cause the Action to be executed with the stated level of 0, while typing "kill Alien" would cause the level property to be temporarily increased to 2. Setting certain properties can give this "level up" additional abilities, such as an additional cost, or greater area of effect.

Here is the list of program commands. Note that whitespace (spaces, returns, etc) is ignored. Where the symbol "||" appears, the argument is a set of values, separated by semicolons. (<value>;<value>;<value> etc.)

if <expression> { <true_code> } [else { <false_code> }]: Evaluates expression, and if true executes true_code, otherwise executes false_code if present. The expression will undergo String Substitution as normal, but will also be automatically evaluated as a conditional, as if it were enclosed in the %yes code. Note that "input" can appear for any value in the expression, or even as the expression itself.
while <expression> { <code> }: As if, but instead of selecting the code to perform, repeats the specified code section for as long as the expression is true.
call <object>[:<property>];: Parses the given property as if it were part of the currently running program script. When the code specified by the call reaches its end, the current program will resume at the line following the call. This allows "subroutines" to be defined. If the property is not specified, the object given (which must be an Action) will be activated directly, causing a switch in context. ("this" will refer to the new Action, for instance) Otherwise, the program will simply be executed using the current context.
end;: Terminates the program. Useful for preventing huge numbers of stacked if statements. Note that if the end command is executed within code executed by the call statement, the entire program will be terminated. The only way to "return" to the calling process is to end normally at the last line. (Unless the call was to another Action as described above)
rem <comment>;: Allows a comment to be inserted into the code. All text between the rem statement and the semicolon will be ignored.
move <object>=<destination>;: Moves the specified object into the given room. An item may also be specified. Note that this is similar but not identical to the default action, as minor variations may occur in the output to the user, and so forth.
print <text>;: Outputs the specified value to the user. String Substitution will take place on the text. See also log, below.
set <object>:<property>=<value>;: Identical to the builder command except for the semicolon at the end. String Substitution will take place on the value and property.
mset |<value>| { |<obj>:<prop>[=<default>]| }: Copies each value in the value list to the corresponding property in that list. If there are not enough values in the list, the default is used.
make <type>[=<name>];: Identical to the builder command. The object created may be referred to as "item" later in the script. (Even if it is not an Item) See below.
destroy <object>;: Identical to the builder command.
link <from_object>=<to_object>;: Identical to the builder command.
unlink <from_object>=<to_object>;: Identical to the builder command.
edit <object>:<property>=<prompt>;: Opens a dialog displaying the prompt given, and the allowing the user to edit the property given. This will be a multiline dialog. Note that String Substitution will not take place on the user's entry.
medit <prompt> { |<obj>:<prop>[=<field name>]| }: Opens a dialog displaying a number of fields, each of which allows the user to edit a property in the list. If the field name given is greater than 15 characters long, the name will appear above the field, otherwise it will appear to the left of it. You can force the field name to appear above the text by ending the field name with "-". (The "-" will not appear in the dialog)
list <prompt> { |<obj_or_prop>[=<name>]| }: Opens a dialog displaying the prompt given and a list of items. Each item in the list will be either an object or a property, or if specified the name. The object or property selected by the user will be copied into the input value.
select <key> { |<obj_or_prop>=<match>| }: Takes the specified key, and if any match value matches the key, copies that object or property into the input value. The special match value "default" will match any key if no other value matches the key.
read <filename>;: Identical to the builder command. The special values "me", "here" and "item" can be used for the filename. They will substitute the filename of the appropriate talk file. "input" can also be specified, but it will write to a file with the name given by the user's input, not the talk file for an object.
write <filename>[=<text>];: Identical to the builder command. String Substitution will take place on the text. The value "input" can be specified for the text. It will write the user's input (after the Action name) to the file. Also see read.
append <filename>=text;: As write.
import <filename>=<local_filename>;: As write.
log <object>=<text>;: Identical to the builder command. The special values "me", "here" "item" and "input" can be used for the object. This can be used to log messages to others in the room, "log here=<message>;" just as print can be used to display messages to the user. Thus succ or osucc messages may be "faked".
fedit <filename>;: Identical to the builder command. See also read.
talk <object>[:<prefix>]=<prompt>;: Opens a "talk" dialog similar to the one opened by the talk command. The prompt for the dialog may be specified. The input entered by the user will be enclosed in quotes, prefixed with theuser's name, and the given prefix, and saved to the object's talk file. If none is specified, the default prefix is "says:".

Objects in the program may be specified by name, but the objects so specified must be linked to by the Action. It is much more efficient to specify objects by dbref. However, there are several special values that may be specified in place of an object:

me - Of course, always refers to the user of the Action. (But this may be an NPC, not the player)
here - Again, always refers to the user's current room.
this - Refers to the Action itself. If this is an inherited program, "this" refers to the Action which was called, not the parent Action.
item - Refers to the item on which this Action was activated, if any. Also, the object the make command creates can be referred to by this value.
link# - Refers to an object linked to by this Action. Useful for inherited programs. Substitute an actual number for the "#" symbol, "0" would be the first item linked, "1" the second, and so on. (TORPS inherits from Java and C a numbering system starting with zero)
input - See below

The argument entered by the user on the command line, after the name of the Action, is passed into the Action in the value "input". It is also capable of being used in String Substitution. (See the Player's Guide) Although the input value can be used as a property, a value, and even a filename, it's usefulness in specifying an object is limited as noted above. (The object would have to be linked to)

For this reason, it is possible to have the input turned into a dbref, by searching the current room for the object. At the same time, the object can be checked for validity, insuring that the object is of the proper type before the program is even called. The "_check" property must be defined to one of the following values:

object - The input will be turned into a dbref, but no type check will be made. The object simply has to be found in the room or in the player's inventory.
room - The input has to be a Room.
item - The input has to be an Item. (But not a Player or NPC)
npc - The input has to be an NPC.
player - The input has to be a Player.
action - The input has to be an Action.
nonaction - The input has to be a Room, an Item, an NPC or a Player.
actor - The input has to be an NPC or a Player.
notme - As actor, but cannot be the user.
short - As notme, but the target must be either near the user, or the user must be near the target.
long - As notme, but the target must not be near the user, and the user must not be near the target.
default - This special value will force the the input to be the default value (below) and will prevent the user from typing in a value.

In addition, it is possible to specify a default for the input. The "_default" property is independent of "_check", either or both may be set for any Action.

me - This is the "default" default.
here - The default is the current room.
none - There is no default. The user must specify a text string after the Action name. If the "_check" value is "default", this value indicates that no input will be passed into the program. (input will be the empty string, "")
link# - An object linked to by this Action. As with this value in a program, the "#" symbol should be replaced with an index number between zero and the number of links pointed to by this Action.

All Actions, of whatever "_check" or "_default" value may be programmed to effect more than one object. This operation will cause the program to be called multiple times, with the input value set to each object effected. The property that sets this value is called "_area".

target (or no value) - Only the object specified will be effected.
link - The program will be called for all objects linked to by the specified object. The program will not be called with the object itself as an argument. (This will, for instance, allow players on a platform to be teleported somewhere. The platform itself will not move)
near - The object specified will be effected. If the object is an Actor, then all actors near the target will also be effected, at a level one less than the level for the target.
area - As "near", but additionally, if the "_check" value is "close", all actors near the caller of the action will also be effected, at a level two less than the level for the target. Otherwise, all actors but the ones near the caller will be effected, again at a level two less.
nearup - As "near", or as "area", depending on if the Action's level is zero or more than zero.
powerup - As "target", "near", or "area", depending on if the Action's level is zero, one, or more than one.
delayup - As "powerup", but is as "target" for levels one and two, and increases from there.

There are also three string substitution codes, not listed in the Player's Guide, which are useful when working with programs. There are:

%prop[object, property]: Substitutes the specified property from the object. Unlike %sub, however, string substitution will not take place on the property.
%mklist [list1, list2]: Concatenates the two lists (which may be single elements) to build a new list. This command is very useful with programs, which cannot specify a ";" character.
%rmlist [list, str]: Removes the item specified from the list, if found. To implement a set (a list with no repeated elements) call %mklist[%rmlist[list, str], str].

The %prop code is most useful when used with the set command, to copy a property from one object to another.

set me:one=%prop[input,one];
set me:two=%prop[input,two];
set me:three=%prop[input,three];
set me:four=%prop[input,four];

This Action would copy four properties from the object the user specified on the command line to the user's properties. Note that this code can also be used to copy program scripts from one object to another. Since you cannot assign a script directly inside a script (the parser would crash) you should always write programs manually (with @edit, for instance) and then either copy the program to the desired object, or execute it with the call command.

Note that the option to indicate an object and property in place of an argument in a string substitution code always performs string substitution on the fetched property, as with %sub. If you do not want this, you will have to nest a call to %prop as the first argument.

If you wish to actually set a property to a string substitution code, double the "%" sign, as in "%%sub[me,_desc]".