Building

From Wiki

Contents 1 Building Guide 1.1 Getting Started 1.2 Starting Your Project 1.3 Rooms, Exits, and Quota 1.4 Customizing Your Room 1.5 Customizing Your Exits 1.6 Adding Effects to Exits 1.6.1 Success Messages 1.6.2 Failure Messages 1.7 Adding More Rooms 1.8 Opening Exits 1.9 Changing Exits 1.10 Fixing Exits 1.11 Help Files

Building Guide

This little guide will tell you everything you need to know to get started in building your own project. Your "project" can be a private home or a public building of yours such as a business. Anything official (such as government buildings, parks, etc.) will usually be built by staff, not by players.

Getting Started

Building is really pretty easy. There are lots of commands for building, and that in itself can make it seem pretty daunting. But you won't often need most of those commands, and each of them has a good help file anyway. Plus, there's this guide!

The best way to learn these commands is to get in and use them. So let's begin with a sample project being built by Azrael (since he's the one writing this guide). Simply substitute your own character's name in place of his and everything will look pretty much the same.

Starting Your Project

All projects are started in the Building Nexus (which is connected directly to the OOC Nexus). Once your project is complete, you can ask a wizard to look it over and to move it to wherever you want it, but for now, head for the Building Nexus.

To begin, simply type +dig. This is a custom command that works only within the Building Nexus. It gets your project off on the right foot by doing all of the following:

1. It creates a starting room (called Azrael's Project - Starting Room).
2. It opens an exit from the Building Nexus to the starting room (called Azrael's Project <Azr>).
3. It opens an exit from the starting room to the Building Nexus (called Out <O>).
4. It gives you ownership of the room and exits so you can customize them as you like.
5. It takes three quota from you, one for the room and one for each exit.

If you type look after this is all done, you will see a new exit (the exit opened in #2 above). This is the entrance to your project, and you can type the alias in the angle brackets (azr for Azrael's project) to enter it. Do that now, and then we'll take a little aside to explain some of the things that +dig does.

Rooms, Exits, and Quota

In the process of building, you will build two kinds of objects: rooms and exits. Rooms are what you might expect them to be; they're the places where your character exists, such as the Building Nexus where he started off building. Exits are the portals that allow you to move from one room to another, and they're very slightly more complex.

Exits are a little bit non-intuitive because, unlike doors in the real world, they're one-way. A single exit can only take you from Room A to Room B, not back from Room B into Room A. To do that, you need a second exit. So, to simulate a door between your living room and your bedroom, you will need to open two exits: one in the living room that leads to the bedroom, and one in the bedroom that leads back into the living room. This is why +dig creates two exits - one goes from the Building Nexus into the starting room, while the other leads the other direction.

This is also why you have three quota taken from you by +dig. Quota is a limit on the amount that you can build. Everyone starts off with 20 quota, and each room, exit, and object that you create takes one quota. You can always check to see how much quota you have and how much you've used by typing @quota.

You can expect to be able to make five or so rooms along with all of their exits and still have a little left over to make a couple other objects. If you have good reason, you can ask a wizard to increase your quota.

Finally, remember that you can @destroy any object you create with @destroy <room, exit, or object>. There is normally a delay involved (which gives you the chance to change your mind if you destroy the wrong thing - do this with @set <room, exit, or object>=!going), and once the object is destroyed, your quota is given back to you.

Customizing Your Room

Now that the explanation is out of the way, let's return to building. Now you're in your starting room (if you're not, use the new exit to get there now). There isn't a lot to it, is there? A name that you probably don't want, a description that just tells you how to write a real description, and not much else. Let's take care of all of this now.

Let's start with the easy part. Most of the rooms in the MUX have a section at the bottom that lists the players, objects, and exits in the room in a nicely formatted way. Your starting room doesn't have this yet. But it's easy to add with the +parent command. This command ties your room to a particular country, and it is the parent room for each country (hence the name of the command) that tells your room how to format that stuff.

+parent is followed by a number that says which country you want your room to be a part of. These countries are listed below.

1. Terre d'Ange
2. Aragonia
3. Caerdicca Unitas
4. Alba & Eire
5. Skaldia

Azrael wants his new project to be in Terre d'Ange, so he types +parent 1. Voila! The room looks a lot better already.

But it still has that lousy name. This is just as easy to fix with the @name command. (The @ indicates that this is a built-in MUX command; the +dig and +parent that you've used so far were custom-built for KushielMUX.) You have to tell @name what you want to rename and what you want to rename it to. Since we want to rename the room that we're standing in, we can use a shortcut: here, which means exactly that. So Azrael could type something like @name here=Azrael's Obelisk - Torture Chamber. (Apparently, he's having a bad day.)

Finally, the description of the room can be changed. This is easy, especially since the description that the room comes with tells you how to change it using the @desc command. So you can type @desc here=<text> and change the room's description to <text> (hopefully, you put something more descriptive there than just <text>). The description can use all of the codes that you normally use in the MUX for paragraphs (%r), tabs (%t), spaces (%b), and colors (see +help colors).

Now that we have our room the way we want it, let's handle those exits.

Customizing Your Exits

Azrael is going to type o to get back out into the Building Nexus, because that's where the exit is that really needs to be fixed up.

From here, he can see that his exit looks like this: Azrael's Project <Azr>. That won't do at all. So the first thing that he will do is change the way that looks.

This is actually the exit's name, and just as we changed the name of the room behind it, we can change the exit's name with @name. But exits are a little trickier, because @name is used not only to change the exit's name but also its aliases. For example, Azrael changes his exit by using @name azr=Azrael's Obelisk <AO>;ao;obelisk;azrael's. Let's look at each piece of that command.

The very first part (after @name) is what is being renamed. For our room above, we used here in this place, but we're not changing the name of the room we're in this time. So instead, we use azr, which is the alias that +dig made for our exit (you can tell because it's what's in the angle brackets). The very first part that comes after the equals sign is the name that will be seen when someone enters the room with the exit. So after Azrael enters his @name command, anyone who enters the Building Nexus will see Azrael's Obelisk <AO> as an exit.

After that first semi-colon comes a list of aliases, each of them separated by semi-colons. You can put anything you want here, but it should obviously make sense. But it's important to make sure that you add as an alias whatever you put in the angle brackets in the name. In this case, that's ao. The name that we used tells people that they can use ao to go through that exit, to it's important to make sure that we actually do include it as an alias!

If you like, you can also add a description to the exit by using the @desc command, just like for the room.

That takes care of how the exit looks and works. But there is so much more that we can do for exits.

Adding Effects to Exits

Right now, our exits are still pretty boring. If you go through the exit, you won't get any message and the people that are watching you will get something boring like "Azrael has left" or "Azrael has arrived." We can change all of these with some more commands. But these commands are very easy to mix up, so pay attention!

Success Messages

There are three commands that you can use to configure your exit to send nicer messages when someone uses it.

@success

The messsage that you see when you go through the exit. Often abbreviated @succ.

@osuccess

The message, prefixed by your name, that people in the same room as you see when you go through the exit. Often abbreviated @osucc.

@odrop

The message, prefixed by your name, that people in the room that you're going to see when you go through the exit.

The first two make a lot of sense. One is a success message, and one is the success message that others (hence the o on the front of it) see. The last one doesn't make much sense though. @odrop is normally the "other drop" message, the message that others see when you drop an object. But since you don't normally drop exits, the designers of the MUX code decided to use it for this special purpose rather than add an extra command just for exits. A good way to remember this one is that it's the message that others see when the exit drops you into the new room.

Where the confusion really comes in is when you have two complimentary exits, one leading one direction and one leading the opposite direction. Then you have six commands (the three above on each of the two exits), and it can be tricky to remember who sees which command. It's especially difficult to remember which @osuccess and which @odrop is being used for which exit. The key here is to remember that they are actually two completely different exits that are used for two completely different purposes.

As a quick example, let's say that you have two rooms, Room A and Room B. Let's say that Room A has an exit leading to Room B called AB. And Room B has an exit leading to Room A called BA. All pretty straightforward.

Any time that you go from Room A to Room B, you are obviously using the exit AB. That means that the @success, @osuccess, and @odrop that are displaying messages are the ones that are on AB. So you know here that when you move from Room A to Room B, using exit AB, then AB's @success is the message that you see, AB's @osuccess is the message that other people in Room A see, and AB's @odrop is the message that people in Room B see when the exit drops you into that room. In this scenario, exit BA doesn't even matter. It's not used at all. It's completely separate. If you went from Room B to Room A, using exit BA, then the opposite would be true - all of BA's messages would be used, and AB wouldn't matter.

Anyway, after all that, let's give an example. Azrael wants his new AO exit to show messages like you were coming in off the street. So he'd set up his exit with these commands:

• @succ ao=You come in off the street and enter the Torture Chamber.
• @osucc ao=disappears through a door in his obelisk.
• @odrop ao=appears in the doorway from the street.

Remember that the last two prefix your name to whatever you enter. So if Azrael uses the AO exit to enter his new torture chamber, he will see "You come in off the street and enter the Torture Chamber." People in the Building Nexus (which would presumably be a street after his project gets moved) would see "Azrael disappears through a door in his obelisk." And people that are actually in the Torture Chamber will see "Azrael appears in the doorway from the street."

Failure Messages

Failure messages are a whole lot easier to deal with, mostly because people in the target room will never see them (since you failed to use the exit). It's a lot easier to deal with a set of messages when they will only be shown to people in one room instead of two.

The only common way that you can fail to use an exit is if it's locked. But you might want to lock your exits (see '+help locking' or 'help @lock' for help with this, as it won't be in this guide), so here are the commands you can use to create messages for them.

@fail

The message that you see when you fail to use an exit.

@ofail

The message, prefixed with your name, that others see when you fail to use an exit.

For example, you could use this set of messages:

• @fail ao=The door appears to be securely locked.
• @ofail ao=tries to open the door to the obelisk, but it seems to be locked.

So let's say Azrael manages to lock his own AO exit in such a way that not even he can get through it. Then, if he's in the Building Nexus and tries to enter his project, he'll see "The door appears to be securely locked." Other people in the Building Nexus will see "Azrael tries to open the door to the obelisk, but it seems to be locked." People that are actually in the obelisk will see nothing, so you don't have to worry about it.

Adding More Rooms

What fun is having just one room? Not much, so let's add an observation room for people to watch what goes on in Azrael's Torture Chamber.

You do this with the @dig command. This is a built-in MUX command that should not be confused with the +dig command that we talked about above. @dig is a convenient, all-in-one command that will not only create a new room for you but will also add exits from where you are to that new room in both directions. It's used like this:

• @dig <new room name>=<to exit list>,<from exit list>

Here, <new room name> is obviously the name of the new room that you're digging. <to exit list> is a list of names and aliases for the exit that goes from your current room to the new room, and <from exit list> is a list of names and aliases for the exit that goes from your new room to the current room. Each of these exit lists is exactly the same as the list that you used in @name above: the list is separated by semi-colons, with the first part being the name as shows up in the room when you look.

Both exit lists are optional. If you leave the second one out, then no exit will be opened from the new room back to your current room. If you leave both out, your new room will have no exits at all (and you'll have to teleport into it until you open some exits in it - see below for opening exits).

So for his observation chamber, Azrael could type this from his Torture Chamber:

• @dig Azrael's Obelisk - Observation Booth=Observation Booth <OB>;ob;obs;booth,Torture Chamber <TC>;tc;torture

In one fell swoop, this will create a new room called Azrael's Obelisk - Observation Booth, an exit called Observation Booth <OB> that leads from the Torture Chamber (where Azrael is when he types the command) to the new room, and an exit in the new room called Torture Chamber <TC> which leads back to the room where Azrael is. Pay close attention to the commas and semi-colons here. The semi-colons separate aliases within each exit, and the exits themselves are separated by commas. It's easy to get them mixed up.

Opening Exits

All of our commands so far have handled exits as a part of building new rooms. But what if we want to only create an exit without creating a room? Maybe Azrael creates a Coat Room for his guests that he wants to connect to both the Observation Booth and the Torture Chamber. When he digs the room, he can only automatically connect it to the room that he digs it from. So how does he connect it to the other room as well?

That's the job of the @open command. But to use this command, you need something else that we haven't talked about: the dbref of the room that you're linking your exit to.

The dbref (database reference) is part of what follows the names of the rooms you own in parentheses. It does not include the letters tacked on the end, though it does include the # at the beginning. For example, if you look at your room and see a name like this: Azrael's Obelisk - Workshop(#3809Rs), then the dbref of the room is #3809.

You need to tell the @open command what room you're connecting to, and you do that with its dbref. Use the command like this:

• @open <to exit list>=<target dbref>,<from exit list>

Once again, the exit lists are exactly the same as was introduced with the @name command above. This time, the first exit list is required, but the second one is optional. If you include it, a corresponding exit coming from the target room to the room you're in will also be opened. If you don't include it, you only get the one-way exit heading to that room.

So if Azrael wants to open an exit from a Coat Room to his Observation Booth, and that booth has a dbref of #3810, here is the command that he would type from the Coat Room:

• @open Observation Booth <OB>;ob;obs;booth=#3810,Coat Room <CR>;cr;coat

This will take care of making exits in both directions.

Changing Exits

Another thing about exits: you can change them around in pretty much any way you want. You can change the room they're in and the room that they link to. Each of these is done in entirely different ways.

If you decide that you want an exit in a different room, just pick it up and move it there. Typing get <exit> will pick the exit up and put it into your inventory. Then you can take it to a new room and type drop <exit>, which will remove it from your inventory, put it into the room, and automatically make it a working exit in that room. This does not change the target of the exit.

To do that, use the @link command. This one has the simple form of @link <exit>=<target dbref>. Once you do that, the exit now will take you to the new room rather than the old. Remember that exits are one-way, though - if you have another exit in the old target room that comes back and you want to change where it is, you'll have to pick it up and move it to the new room.

Fixing Exits

Probably the biggest annoyance that new builders face is "losing" their exits. This is normally caused by one of two things: forgetting to set aliases and not realizing that you have the exit in your inventory. The first is the most common.

Aliases make it possible to reference exits. If they just have their names, they can be very difficult to manipulate. It's also entirely possible to accidentally name two exits exactly the same thing, and then if there are no aliases (or if the aliases are also the same), there's no way to manipulate either of them. Well, actually, there is one way: the dbref, which is always unique.

To "find" an exit you lost or to find out the dbref of one that you named the same as some other exit, you can use this command: @search type=exit. But 'be careful' with this command. Since @search is an expensive command to run, it costs players "pennies" to run it (that way they cannot accidentally run it in a loop forever and bring the game down). You can see how many pennies you have by typing i (for inventory). If you have the 100 pennies (you get an amount every day and can ask a wizard if you need more in a pinch), then you'll get a listing of every exit that you own - including the dbref. Then you can use that dbref in place of its name or alias in any of the exit commands above (e.g., you can rename an exit to add aliases with something like @name #3811=Observation Booth <OB>;ob;obs;booth, using the dbref that you found in place of the name or alias).

Help Files

All of these files discuss concepts that we talked about above.

• help @dig
• help @name
• help @desc
• help @destroy
• help @open
• help @link
• help @success
• help @osuccess
• help @odrop
• help @fail
• help @ofail

You can also look at these help files for some more advanced building concepts.

• help @set
• help @asuccess
• help @afail
• help @lock
• help transparent

There are dozens more (see help commands for a list of all of the commands you can use), but these should get you well on your way.