building_guide
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
building_guide [2010/01/26 03:56] – zobeid | building_guide [2010/01/26 04:17] (current) – zobeid | ||
---|---|---|---|
Line 169: | Line 169: | ||
@succ d=You go down the stairs. | @succ d=You go down the stairs. | ||
@set d=_/sc:You go down the stairs. | @set d=_/sc:You go down the stairs. | ||
- | |||
====== Making Exits Visible or Hidden ====== | ====== Making Exits Visible or Hidden ====== | ||
Line 176: | Line 175: | ||
@succ here=@$obvexits | @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' | + | 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 (**'' |
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: | 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 184: | 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. | 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 **'' |
====== Using @Excavate ====== | ====== Using @Excavate ====== | ||
Line 196: | Line 194: | ||
@excavate Inside the Hut=Enter Hut; | @excavate Inside the Hut=Enter Hut; | ||
- | It creates a room named " | + | It creates a room named " |
- | + | ||
- | When you are creating new rooms using the R command in Editroom, it will prompt you for the same information: | + | |
+ | When you are creating new rooms using the R command in Editroom, it will prompt you for the same information: | ||
====== Basic Things ====== | ====== Basic Things ====== | ||
- | Most players soon discover that they can @create things. Your basic object of type " | + | Most players soon discover that they can **'' |
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 " | 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 " | ||
- | 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 | + | 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 **'' |
- | 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 **'' |
@link mything=here | @link mything=here | ||
@lock mything=me | @lock mything=me | ||
- | Now nobody but you can pick it up. (You could also lock it to " | + | Now nobody but you can pick it up. (You could also lock it to " |
====== Containers ====== | ====== Containers ====== | ||
Line 226: | Line 223: | ||
Please see the section on locks if you aren't sure how they work. | Please see the section on locks if you aren't sure how they work. | ||
- | |||
====== DARK Flag and Fake Contents ====== | ====== 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: | You can set a property on your container: | ||
Line 277: | 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. | 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 ====== | ====== Environment Rooms ====== | ||
Line 286: | 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. | 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" | + | Another neat trick is your ability to enter and exit rooms. If you are in a sub-room, you can **'' |
- | 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 **'' |
- | 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 (dbref of kitchen)=(dbref of parent) | @tel (dbref of kitchen)=(dbref of parent) |
building_guide.1264478195.txt.gz · Last modified: 2010/01/26 03:56 by zobeid