Differences

This shows you the differences between two versions of the page.

--- building_guide [2010/01/26 03:53] – zobeid
+++ building_guide [2010/01/26 04:17] (current) – zobeid
@@ Line 8: / Line 8: @@
 A flag is a simple on-or-off switch applied to an object. The same flag can have different effects on different types of objects. For example, D stands for DARK when applied to rooms, things or actions. D stands for DEBUG when applied to a MUF program. You can get a full list of flags by typing: **''help flags''**
-Flags are set or cleared using the @set command:
+Flags are set or cleared using the **''@set''** command:
   @set <object>=<flag>
 . . .and cleared by adding an exclamation point (!) which stands for "not". . .
   @set <object>=!<flag>
 An example may help. Let's imagine we have a mushroom that we want to make sticky, but not dark:
   @set mushroom=s
   @set mushroom=!d
 You can see the flags on an object (and a lot of other useful information) anytime by using **''examine''** on it. (You can also use **''ex''** for short -- remember that most commands can be shortened in this way!) The same command also is used for viewing properties.
@@ Line 145: / Line 149: @@
   @odrop lr=wanders in from the kitchen.
-Since the doorway is not locked, the @fail and @ofail messages are not needed here. @drop likewise is not often used. Note that exits can have an @desc, and players can look at them. Now, when I use this exit, I will first see:
+Since the doorway is not locked, the **''@fail''** and **''@ofail''** messages are not needed here. **''@drop''** likewise is not often used. Note that exits can have an **''@desc''**, and players can look at them. Now, when I use this exit, I will first see:
   You wander into the living room.
@@ Line 161: / Line 165: @@
 You should also be aware that these messages can include MPI code which will execute. Therefore, you can create an action linked to $nothing, but with MPI code in the @succ message. This is a commonly used way of creating MPI-based commands.
-All messages are set as properties on the object, and in fact you can also set them using the generic @set command. For example, the following commands are equivalent:
+All messages are set as properties on the object, and in fact you can also set them using the generic **''@set''** command. For example, the following commands are equivalent:
   @succ d=You go down the stairs.
@@ Line 171: / Line 175: @@
   @succ here=@$obvexits
-This is not required, but it makes building easier when you can see what you are doing. If you want to make the exits invisible later (so that other players don't know what they are), you can toggle them off again using Editroom, or by clearing the property (@succ here=). Leaving the exits visible is usually a good idea, unless you have some reason in mind why other players shouldn't see them (like in a maze, maybe). For building in public areas, visible exits are practically a requirement.
+This is not required, but it makes building easier when you can see what you are doing. If you want to make the exits invisible later (so that other players don't know what they are), you can toggle them off again using Editroom, or by clearing the property (**''@succ here=''**). Leaving the exits visible is usually a good idea, unless you have some reason in mind why other players shouldn't see them (like in a maze, maybe). For building in public areas, visible exits are practically a requirement.
 Also note... If you want most exits in a room to be visible, but want to hide a particular one, you can set a DARK (D) flag on it:
@@ Line 179: / Line 183: @@
 This can also be done using Editroom: select X to edit exits, then select the number of the exit you want to edit, then D to toggle the DARK flag or or off.
-If you are a creating a role-playing or puzzle area with hidden exits, you should make them reasonably findable. A good rule of thumb is that the exit name should at least be a word appearing somewhere in the room desc, unless you have prepared some other clue for the players. If you have an exit that is really private and others are not intended to use, it is a very good idea to @lock it. The management cannot guarantee players won't be able to detect your exit by some means, so putting @lock on your private exits or paths is just good sense.
+If you are a creating a role-playing or puzzle area with hidden exits, you should make them reasonably findable. A good rule of thumb is that the exit name should at least be a word appearing somewhere in the room desc, unless you have prepared some other clue for the players. If you have an exit that is really private and others are not intended to use, it is a very good idea to **''@lock''** it. The management cannot guarantee players won't be able to detect your exit by some means, so putting **''@lock''** on your private exits or paths is just good sense.
 ====== Using @Excavate ======
@@ Line 191: / Line 194: @@
   @excavate Inside the Hut=Enter Hut;enter;hut=Outside;out;o
-It creates a room named "Inside the Hut", creates an exit named "Enter Hut;enter;hut" leading into the room, and creates another exit named "Outside;out;o" leading back out of it. You should note that many flags and settings are copied from the room you are in and applied to the new room. You can edit a room, get the settings you like, and then use @excavate repeatedly to create a whole area with the same settings.
+It creates a room named "Inside the Hut", creates an exit named "Enter Hut;enter;hut" leading into the room, and creates another exit named "Outside;out;o" leading back out of it. You should note that many flags and settings are copied from the room you are in and applied to the new room. You can edit a room, configure it with the settings you like, and then use **''@excavate''** repeatedly to create a whole area with the same settings.
-When you are creating new rooms using the R command in Editroom, it will prompt you for the same information: first the name of the new room, then the name of an exit leading into the room, and then the name of an exit leading back out. So, you can do exactly the same kind of building as you would with @excavate.
+When you are creating new rooms using the R command in Editroom, it will prompt you for the same information: first the name of the new room, then the name of an exit leading into the room, and then the name of an exit leading back out. So, you can do exactly the same kind of building as you would with **''@excavate''**.
 ====== Basic Things ======
-Most players soon discover that they can @create things. Your basic object of type "thing" can be carried around by players in their inventory, or dropped in a room. You can use @desc to add a description and look at it just as you would look at a player. This is fine for simple props, but you can also do more sophisticated things with things.
+Most players soon discover that they can **''@create''** things. Your basic object of type "thing" can be carried around by players in their inventory, or dropped in a room. You can use @desc to add a description and look at it just as you would look at a player. This is fine for simple props, but you can also do more sophisticated things with things.
 A thing can contain other things, and it also can have exits or actions attached to it. That means you could carry around a portable "doorway" leading to another room, or you could carry a thing with a MUF action attached. The action is usuable when you are carrying the thing or when the thing is in the same room with you.
-If you set the STICKY (or S) flag on a thing, it will return to its home location when it is dropped. The home is set using the @link command. This is useful when creating objects that other players may use temporarily. For example, in your spaceship you could have space suits set STICKY and @linked to the airlock. Other players could take and wear them, but as soon as they drop the suit it would come back to your ship.
+If you set the **STICKY** (or S) flag on a thing, it will return to its home location when it is dropped. The home is set using the **''@link''** command. This is useful when creating objects that other players may use temporarily. For example, in your spaceship you could have space suits set STICKY and **''@link''**ed to the airlock. Other players could take and wear them, but as soon as they drop the suit it would come back to your ship.
-You can also use @lock to control who is able to pick up your thing. To make an object immobile, you could use these commands:
+You can also use **''@lock''** to control who is able to pick up your thing. To make an object immobile, you could use these commands:
   @link mything=here
   @lock mything=me
-Now nobody but you can pick it up. (You could also lock it to "me&!me" -- me and not me -- a conditon that can never be met, which would even prevent you from accidentally picking it up.) However, you or a wizard could still move it using @teleport. Linking your thing to the room means if it ever does somehow get moved, it ought to eventually be swept back home where it belongs.
+Now nobody but you can pick it up. (You could also lock it to "me&!me" -- me and not me -- a conditon that can never be met, which would even prevent you from accidentally picking it up.) However, you or a wizard could still move it using **''@teleport''**. Linking your thing to the room means if it ever does somehow get moved, it ought to eventually be swept back home where it belongs.
 ====== Containers ======
@@ Line 221: / Line 223: @@
 Please see the section on locks if you aren't sure how they work.
 ====== DARK Flag and Fake Contents ======
-When the DARK (D) flag is set on a room, the description of the room is still shown, but the contents of the room are not visible. When the DARK flag is set on a thing, the thing won't be seen in the content listing of the room, container or player where it's located. When DARK is set on an exit, it will not appear in the obvious exits listing of the room (as shown by $ObvExits).
+When the **DARK** (D) flag is set on a room, the description of the room is still shown, but the contents of the room are not visible. When the **DARK** flag is set on a thing, the thing won't be seen in the content listing of the room, container or player where it's located. When **DARK** is set on an exit, it will not appear in the obvious exits listing of the room (as shown by **$ObvExits**).
 You can set a property on your container:
@@ Line 272: / Line 273: @@
 It is also possible to create special locks using MUF programs. However, that is an advanced technique. In such cases you should refer to the MUF's instructions to see how it must be set up.
 ====== Environment Rooms ======
@@ Line 281: / Line 281: @@
 You only have to set this once in the parent room, you don't have to set it on each sub-room. BANISH is another program that recognizes parent rooms. So, you can banish someone from the parent, and they are automatically kept out of the sub-rooms too.
-Another neat trick is your ability to enter and exit rooms. If you are in a sub-room, you can "exit" into the parent. There you can see your sub-rooms listed and easily "enter" one of them. This is very handy when building large areas and working on many rooms.
+Another neat trick is your ability to enter and exit rooms. If you are in a sub-room, you can **''exit''** into the parent. There you can see your sub-rooms listed and easily **''enter''** one of them. This is very handy when building large areas and working on many rooms.
-You can use Editroom to change the parent of a room you have built. When making a new room, the default parent is the same parent of the room you were already in. This means once you've created a parent room and your first sub-room, you can build with Editroom or @excavate and all the new rooms will go under the same parent.
+You can use Editroom to change the parent of a room you have built. When making a new room, the default parent is the same parent of the room you were already in. This means once you've created a parent room and your first sub-room, you can build with Editroom or **''@excavate''** and all the new rooms will go under the same parent.
-Finally you can use @tel to change the parent of a room. For example, let's say you have created a parent room for your apartment. You already have made a kitchen and you want to set the parent for it:
+Finally you can use '**'@tel''** to change the parent of a room. For example, let's say you have created a parent room for your apartment. You already have made a kitchen and you want to set the parent for it:
   @tel (dbref of kitchen)=(dbref of parent)