Vaticus' Building Tutorial

Building on RedWall MUCK

By Vaticus

(Edited and updated by Drakain, Zoe_Lang)

Building on a MUCK is a pretty straight forward process. In order to do this well, there are a few important concepts to be familiar with, and a handful of commands that one should know about. In this tutorial, I will be discussing nearly all the subtleties of building. Please do not feel overwhelmed by the amount of material covered. Many people come to me and say that our building system is too complicated, or requires people to know too much. In reality, there is not a whole lot more that a person needs to know at this site than any other, and I can assure you, this system is infinitely more powerful in what can be done with it. If some of the concepts explained are too confusing at first, don't worry about them. Move on to the next section. There will be plenty of examples throughout, so if you do not understand why something is the way it is at first, that is normal!!! Worry not, with some time, you will get it. At the end of the tutorial is a list of questions that I get asked about all the time. These can also be used to assist you if you don't need to know all the information covered here.

Section #1 -- How do I build?

• Explanation of General Parenting.
• Technical Explanation
• Analogies Explanation
• Direct Example Explanation
• Pictorial Explanation
• How to make a new region.
• Building IC rooms in your region.
• Connecting your rooms to one another.
• Adding description to make things more interesting.

Section #2 -- Building a home; Commands only.

Section #3 -- Other Interesting things that you might want to know about.

• How do I set my home?
• How do I link my house to the main IC world?
• How do I add exit messages to my home?
• How do I use lsedit to describe things?
• How do I use the various flags?
• How do I lock my rooms to specific players or groups?
• How do I allow other people to build their homes in my region?
• How do I use roomtypes?
• How do I create actions in my rooms?
• How do I change the parents of my rooms?
• How do I use regnames?
• How do I make a script?
• How do I use the +locks?

Section #1 -- How do I build?

Explanation of General Parenting.

To begin, a person who wishes to build a room is usually going to type something along the lines of @dig <room>. On many MU*'s, this works with no problem. However, when you type that on RedWall, you may get an error message saying You cannot parent to that room. The reason for this message is that you have to have a parent room built in order to build your rooms.

EVERY room on a MUCK must have a parent room. When you type @dig , the system will try to autoparent your room to a default parent room. Most MUCKs are small, and this can be done with little problem. However, on RedWall, we have over 60,000 rooms in our database. Having that many rooms parented to a single parent would be a horrendous mess. Therefore, we developed the regions system. This allows us to have a very powerful system of organization for rooms.

The region system is just a type of parenting system. The concept of parent rooms can sometimes be a difficult thing to explain, so I am going to explain this is a number of different ways. Virtually everyone I assist can grasp this concept with at least one of these explanations. If you figure it out right away, you can skip to the next section. If the first explainations confuse you, keep reading.

Parenting Explanation #1 -- Technical Explaination (This can be semi confusing if you do not think in a technical manner.)

This is the purely technical explanation. A MUCK's database is made up of six main types of objects. These are players, rooms, exits, objects, programs, and garbage. Each of these objects has to be somewhere. Think of the MUCK as vast open space. An object cannot simply exist 'no where'. It has to be located somewhere. For example, if you put an object called 'sword' in a room, it would be inside that room. However, rooms are really no different than objects. A room is just an object that we happen to be able to exist in. So, each room is INSIDE another room. The room that it is inside is its parent room. At the top of the MUCK is #0, the first room. EVERYTHING in the MUCK is in that room. Inside that room, we placed the Software room, where the programs are stored. Inside of the software room, we have two MORE rooms, the IC Environment and the OOC Environment. In side the IC Enviroment, we have all the top level regions; Mossflower, Southsward, Western Lands, etc. And it goes on from there. Once into the IC environment, each of these areas is called a region. The region is made up of the rooms in the region, and the subregions within the region. For example, Mossflower is a region. There are a lot of rooms in that region; the forest rooms, the meadows, the clearings, etc. These are all rooms IN the region. (That means those rooms are INSIDE the Mossflower Parent.) Also in Mossflower are a number of subregions. An example of this would be RedWall Abbey.

Parenting Explanation #2 -- Analogies Explaination (These make use of a number of different types of analogies of organizations similiar to the parenting/regioning system.)

For those of us who do not think in such a technical manner, I will explain by setting up some analogies. First, the world in a box analogy. You can think of the MUCK as a huge box or container which you place all objects into. The WHOLE MUCK is a box. In that are some smaller boxes. And within each of those smaller boxes are many more even smaller boxes. Each box can contain multiple rooms, objects, and players. Another way to think of it would be from a celestial standpoint. The MUCK is a Universe. In that universe, there are a handful of Super Clusters, (which might be comparable to our OOC and IC environments.) Then, below that, one would find Galaxies of stars, (comparing to our top level regions, Mossflower; West Lands; Northlands; Southsward; Collinsel, etc.) Within each of those, one would find various Star Systems, (which would be smaller regions such as, RedWall Abbey, the Forest, the Dirt Road, etc in Mossflower. Then, you would have planets within each little system, (which would be the actual rooms you see everyday.) Yet another more simple way to explain it would be to compare a region to a house. The region parent is the walls surrounding the house, and all the rooms are 'inside' it. (Be careful on this one, though. Although the analogy is pertaining to walls surrounding a home, outside rooms are IN a region as well. Keep that in mind.

Parenting Explanation #3 -- Pictorial Explanation (A diagram of a number of the MUCKs regions.)

[None|Redwall Map]

Of course, the above picture does not represent ALL the parenting and regioning within RedWall MUCK. That would be far too large to put in here. Although, this will give the general idea.

If at this point, you still do not understand what a region or parent room is, then do not worry about them right now. Just proceed below, and see me in person sometime, or any other geographer and we can try to assist you.

How to make a new region.

In order to create a region, you want to use the command +newregion <region>=<parent>=<regname>.

The above command will create you a region parent that you can use for whatever it is that you are building. Lets say that you are building a home for yourself. For this, your <region> would most likely be the name of your home. An example for that might be Vaticus' Home. The next part is the <parent>. This is the region that your region is located in. (See above explanations if that concept does not make sense.) If you have chosen a location for your home already, then you should use the correct region parent of that area. You can click here to get a current listing of many of the towns available on the MUCK that are accepting homes. Should you not see the area that you are interested in listed there, go to that area on the MUCK itself, and type +showregion here. That will tell you the person who owns the region that you are in. That person will be able to supply you with the correct region parent for you to parent to. Simply #mail them with a request to know what region parent that you should use. (This will be either a DB# or regname.) In the worst case scenario, if you cannot get in contact with the player, or you are building a home and have NO clue where you want for it to go, we have a default, temporary region parent. That parent is $~region. However, please keep in mind that using that parent is not encouraged. If you know where you want to build, you need to parent to the correct region. The last part of the command is the <regname>. This is the registered shortname for your region. I often recommend for these purposes using the same name as your region, or something similar to that which is easy for you to remember. (For a more detailed explanation of regnames, see below.)

Now, you should be ready to create your region. A sample for this command as it would be correctly used would be something like +newregion Vaticus' Home=$~region=VaticusHome. (NOTE: As mentioned above, DO NOT use $~region if you are able to locate the correct parent of the area you are building in.)

Once this first step is complete, you are now ready to begin building the IC rooms within your region.

Building IC Rooms in Your Region.

To build an IC room, the command is @dig <room>=<parent>. The <room> is the name of your room. Perhaps Entryway, or Kitchen, or Path, or Dark Woods, or anything such as that. The <parent> is the region parent that you just created above. (Note: You cannot complete this step without a parent room. If you have not yet created your region parent, please do so now.) You can create as many rooms as you need to in your region. Some regions might have 2 or 3 rooms. Other regions might have 300 rooms. This part does not matter, it depends solely on what you want.

An important thing to note: When you created your region, a room was created called Region Parent: <Your Region>. This is the parent room of your region ONLY. It should NOT be used as part of your region. That room should never be used for IC purposes, it should not serve as an entryway to the region, or a main room, or anything like that. Frankly, with the exception of parenting your IC rooms, you can pretty much ignore the parent entirely. The point is, this is NOT an IC room, there should not be people living there, there is no need for a description, or anything such as that in the PARENT room.

The an example of how to create a new IC room would be something like @dig Entry Hall=$VaticusHome. (I chose VaticusHome as the parent, since that is the regname that I specified when I created my region.) Whatever you use for your regname of the region is what you should use as the parent. Also note, you need to add a $ sign infront of whatever your regname happens to be. You can see I did that above. If you are more comfortable using db#'s, that is fine too. Simply check your @own, and the parent's db# will be listed there for you.

Connecting Your New Rooms to One Another.

There are a number of ways to connect rooms to one another. The easiest way that most people are familiar with is @open. Another way which is a bit more complicated, but also a lot more powerful is @door. I will present both of these two; You choose which works best for you.

The first means of connecting rooms is @open. The syntax for this command is @open <exit> ;<quickkeys>=<destination>. The <exit> is the name of the exit, or in other words, precisely what you see on the MUCK. When walking around, you probably see all sorts of exits, i.e. [D]own the [P]ath OR [N]orth OR [I]nto the [D]en OR [Enter] OR [A]ross the [S]tream, etc. These are all valid exit names. Now, the letters that you see contained within the brackets, [] are what I call the <quickkeys>. These are what cause the exit to actually work. For example, for [D]own the [P]ath, dp are the quickkeys that you would type in. When entering these in the command itself, you use @open [D]own the [P]ath;dp. The last part of this is the <destination>. When you @open an exit, it the exit will START from the room that you are standing IN, and travel to the room that you provide as the destination.

So, lets imagine that I have created two rooms in my region, Entry Hall, (#123456) and Gathering Room, (#123457). First, I would jump to the Entry Hall. There, I would type @open [G]athering [R]oom;gr=#123457. This would open an exit called [G]athering [R]oom, originating from my Entry Hall, and travelling to my Gathering Room. Once I finish this, I would have to goto the gathering room to @open an exit BACK. (Note: You can now use the exit you just created to get there.) Now, while in the gathering room, I would type @open [E]ntry [H]all;eh=#123456. This is going to open an exit called [E]ntry [H]all, originating from the Gathering room, and travelling to my Entry Room.

The other method of connecting rooms that I mentioned was @door. This method has a much longer command syntax, but can do a lot more. For one, unlink @open, @door allows you to open BOTH directions of exits at once. In addition to that, it allows you to create them remotely. So, you do not ever have to jump to either the Entry Room or the Gathering Room to make there. You can be anywhere on the MUCK at this time. The other issue with @door is that it is best used if you are making use of regnames. You can use it without them, but it somewhat defeats the purpose. For this explanation, I will first show it WITH the regnames, although if you want to know what they are, and how they work, see the section below. I will also show how to do it without, for those who prefer that.

The actual command syntax for @door is @door <Room1>=<Exit1>=<Regname1>=<Room2>=<Exit2>=<Regname2>. Recall that you are opening both directions in this. I like to break it into two parts. The first half is the first exit. The second half is the return exit. (I will be using my Entry Hall/Gathering Room example from above.) Now, just recall from @open... First, you have the <Room1>. That would be the regname or db# of the Entry Hall. Then, you have the first exit. Recall, exits have two parts, the <exitname> and the <quickkeys&GT. So, your exitname would be [G]athering [R]oom;gr. (This is since it is going TO the Gathering Room FROM the Entry Hall.) Last would be the regname of the exit. You can either leave this out, or put it in if you wish. If you DO leave it out, dont forget to leave a space for it. Next is the second half. Here we repeat the first process again, backwards. Now, <Room2> is the regname or db# of the Gathering Room. The second exit is the return exit, so here we would use [E]ntry [H]all;eh. Finally, we have the last regname. Again, use it or leave it, that is up to you. Here are some samples below.

@door #123456=[G]athering [R]oom;gr==#123457=[E]ntry [H]all;eh This example uses no regnames. As mentioned above, if you DONT use the regname, do not forget that double == in there. If you leave it out, the program does not know that you are skipping that part of the command.

@door $Rooms/Manor/EntryHall=[G]athering [R]oom;gr=Exits/Manor/EH-GR=$Rooms/Manor/GatheringRoom=[E]ntry [H]all;eh=Exits/Manor/GR-EH This version uses regnames. If you do not understand regnames and would like to, they are covered below. This is necessary for scripting. If you are not scripting, you can probably get by without them.

A few other general notes about exits: Here are some common things to know about making good exits. First, I strongly discourage exits that are ambigous. These types of exits include [B]ack, [O]ut, and other things like this. When you are linking two rooms together, you might be tempted to use these. However, imagine there are four exits leaving from the Gathering Room mentioned above. They might be [K]itchen, [B]edroom, [E]ntry [H]all, and [B]ack. Where does that [B]ack go? By using that, you have created a problem. As long as someone enters from the room where the [B]ack exits goes to, then [B]ack works. But, what if they came from the kitchen into the Gathering Room? It would not make sense for them to go [B]ack somewhere other than the [K]itchen. So, they are not going [B]ack, in this case. Another thing, a lot of people like to just use NSEW directions. This is especially common in outdoor areas. This can tend to get boring, and is not that accurate. I do not know how many animals out there carry their nice little compass and always know which way is North, South, East, or West. Better exits would be ones that are descriptive. Some examples of this would be [O]ver the [L]arge [H]ill, or, [T]hrough the [M]ysterious [C]learing, or things such as that. If you absolutely MUST use NSEW, try to make them more interesting. How about something like [N]orth [A]cross the [S]tream?

Adding Descriptions to Make Things More Interesting.

There is nothing worse than coming upon a room that has the description, You see nothing special. Our goal is to make our rooms interesting, and the way that one does that is through a good description. Remember, we are existing in a text based universe. When you enter a room, the only way that you can tell what you are supposed to be seeing is through a good description. To enter a description, simply type @desc here=<description>. This is probably the easiest command yet. Once you are in there, you can add any information that you want to tell us what we see. First, we will want to know what we are looking at. How large is the area being described? What interesting features can we see? What objects are in the room? What significant activity is there? Once this general information is in place, you want to appeal to the senses. What types of things can we hear going on in the background? Is there any ambient noise? What smells or aromas are in the air?

The key is to make it interesting but not be boring. A good desc for the average room is 6-10 lines in length. If you are much less than that, you really are not telling me enough. I am likely going to be wondering what else is supposed to be there. If you get too much longer than that, it will become too cumbersome. I do not have the time to read massive descriptions all the time. If you really need a long description, at least make use of lsedit, which allows you to create paragraphs, and other useful things to make the desc more readable. (For instruction on lsedit, see below.)

This is generally where I conclude lessons on basic building. Indeed, there are dozens more useful commands to know, but with the few covered above, you are on your way to a good start with building on RedWall. Should you be interested in the more advanced types of things, feel free to continue on now, or come back another time when your mind is fresh and ready to learn again.

Section #2 -- Building a Home, Commands Only.

For those of you who want a recap of all that huge amount of text above, read through these. Note, however, there is no explanation here, so if anything is confusing, you will want to see the above section with step by step instruction.

First Step: Create A Region.

+newregion <region>=<parent>=<regname>

+newregion Vaticus' Home=$~region=VaticusHome

NOTE: As mentioned above, DO NOT use $~region if you are able to locate the correct parent of the area you are building in.

Second Step: Create IC Rooms.

@dig <room>=<parent>

@dig Entry Hall=$VaticusHome

@dig Gathering Room=$VaticusHome

Third Step: Linking these together.

@open <exit> ;<quickkeys>=<destination>

@open [G]athering [R]oom;gr=#123457

AND

@open [E]ntry [H]all;eh=#123456

OR

@door <Room1>=<Exit1>=<Regname1>=<Room2>=<Exit2>=<Regname2>

@door #123456=[G]athering [R]oom;gr==#123457=[E]ntry [H]all;eh

@door $Rooms/Manor/EntryHall=[G]athering [R]oom;gr=Exits/Manor/EH-GR=$Rooms/Manor/GatheringRoom=[E]ntry [H]all;eh=Exits/Manor/GR-EH

Fourth Step: Describing Rooms.

@desc here=<description>

There you have it, building in four easy steps. You can build anything you want knowing just that. Of course, the realm of building CAN go far beyond that. If you are ready for more, I have numerous misc. topics I am presenting below that can be added to supplement your building.

Section #3 -- Other Interesting Things That You Might Wish to Know.

How do I set my home?

Setting your home is a very important thing to do. If you do not, you will end up waking in the crevasse, which is not very desirable. To set your home, you need to first have built a home. Once that is taken care of, you can type @link me=here in the room that you want to wake up in. Note: There are some rooms on the MUCK that you can set as your home that you do not own. Any room that is set with the A-Flag, (Abode), is one of these rooms. In general, however, you will want for your home to be in the place you built as your home.

How do I link my house to the main IC world?

The first step in finding a location for your home that I tell everyone is to walk around. Familiarize yourself with the MUCK. See what is out there, and find an area that suits you. When you find the perfect area that works for you, then you might have a good spot for your home. How do you know if an area is perfect for you? Well, there are a few things to keep in mind. What type of home are you building? Do you have ocean front property? If so, you do not want for your home to be in the middle of the forest. Will your home work well IC'ly in this location? There is no castle mentioned as existing right across from RedWall Abbey in Brian Jacques' books. Therefore, we are no going to allow you to build a castle across the street from RedWall. Also, are you allowed to build in the area? The area around the Abbey and Dirt Road, for example, is restricted from linking. So, this is not a good place to build your home. Once your location is determined, find out what the region parent of the area is. To do so, type +showregion here and see who owns it. Then, ask that person first off, will they let you build in their area? And then, if the answer is yes, they should be able to get you the region parent. Now, unfortunately, there are still a number of areas on the MUCK that are not fully regioned, yet. This does not mean that you cannot build there. That is what the default temp region was created for. This is a case where you can use $~region as your region parent. At least YOUR area is regioned, and when the parent area is ready, your region can easily be placed within it. Finally, once you are finished with this, you can build your place. When it is all ready to go, you need to approach the owner of the region one last time. You cannot link to an area that you do not own. So, you need to have the owner of the region assist you with that. If you have any questions about this process, speak to myself or one of the geographers.

How do I add exit messages to my home?

There are five basic exit messages that can be added to a exits to make them a bit more interesting. These are @succ, @osucc, @odrop, @fail, and @ofail. Each uses the same syntax: @<command> <exit>=<message>. The @succ is the message that you see when you walk through an exit. For the [E]ntry [H]all exit, it might be something like... @succ eh=You walk down the long hallway into the entry hall. The @osucc is the message that everyone else in the room sees when you use the exit. An example might be @osucc eh=walks down the long hallway into the entry hall. Note that this time, I left the beginning of the sentance out. The reason for that is because the system will automatically insert the name of whomever is using the exit right there for you. Next is @odrop. This is the message that the people see in the room you are going TO. So, an example might be @odrop eh=walks in from the gathering room. (The gathering room/entry hall example has been used throughout the entire document for those of you first joining us at this point.) The other two are @fail and @ofail. These work just like the @succ's, but are used for locked exits. Such as, if an exit were locked, you might have a message saying something like You try to open the door, but find it securely locked. These last two are not needed unless the exit being used is locked. Another useful command to use related to these is @check. If you type that in any room, it will look over every exit in the room and tell you which ones are missing specific messages. Also, for those of you who REALLY want to impress someone, you can also @desc your exits. This can come in handy if you want to describe a specific door, or something like that.

How do I use lsedit to describe things?

Lsedit is a very useful thing that allows you to make your descriptions much longer. Not only can they give you more length to work with, but they can also be used to add paragraphs, or ASCII art, or other types of formatting to your descriptions. Be aware, though, lsedit is a wee bit tricky at first, and tends to be buggy with some of its usage. First step is to write your description the way you want it. I recommend for this using another program such as MS Word, WordPerfect, Windows NotePad or WordPad, or any other good Word Processor. Once you do that, return to the MUCK, and type lsedit <object>=<list>. This opens the editor. While in the editor, everything you enter becomes lines in your list. Watch out... Do not be tempted to return pages, or write in other MUCK commands while in the editor. If you do, that will just add itself to your list, making for you a bit of a mess. Also, another quirky thing about the editor is that it does not show you anything that you have typed. So, when you are entering data into it, do not be expecting a response. No, the MUCK is not lagging, you just cannot see what you are entering. Once you have entered all of the desc into the editor, you type .end to conclude your editor session. Now that your list is in place, you need to set it as the desc. The command to do so is @desc <object>={list:<list>}. Make sure the objects and lists used correspond. For both the lsedit, and the @desc commands, the object is the object being described, the list is the name of the list. I often use desc as my listname, if I am writing a desc.

How do I use the various flags?

Flags are something that is useful for various things. Sometimes, when you look at a db#, you may notice a number of letters following it. Those are the object flags. Some of the more common ones that pertain to building are L, J, A, and C. The L flag is what makes a room Link_ok. This means that other people can link exits into your room. If you have an area and are helping someone link their home to it, you will need to have your room set Link_ok. The J flag is what makes a room Jump_ok. This is what determines if a player can jump into your room or not. The A flag is what sets a room Abode. This has three functions. It allows other players to set your room as their home. It allows other players to parent to the room, if it is locked to support that. Finally, it allows for other players to create regions in your area. (Note: If you own a town and want people to live there, you need to have your region parent set A. The last common flag is the C flag. This is what makes a room chown_ok. This can be dangerous. Make sure if you are chowning rooms that immediately after setting the chown flag, chownlock the room. To do so, use @chlock <Object>=<Player>. This will limit the chowning ability to that person. If you do not do this, anyone can chown your object. To set any of the above flags, use @set <Object>=<Flag>. For example, @set here=L. To remove any flag, it is the same, only place a ! in front of the flag. The ! means NOT. So, @set here=!L.

How do I lock my rooms to specific players or groups?

The basic command for locking rooms is @lock. The command syntax for this command is @lock <exit>=<key>. The exit is, of course, the exit that you are locking. The key can be a number of things. A key can be made up of ANY combination of Player Names, Objects, Properties, Skills Groups, and other things. Each item in the key must be seperated by a | symbol. For player names, use the players exact name, but place a * infront of it. For an object, (such as a physical object key that you made,) use the db#. You can also lock to any property. For example, if you wanted only people who are set IC, you would lock to ~status:ic, since that is the appropriate property. Also, you can use skills groups. This allows a whole group of people to be allowed to enter. For for that, use ~skill_list/:*. So, for an example, I will lock my [E]ntry [H]all exit from above to myself, to players who are OOC, to players who are in my staff, and to the object I created called Vaticus' Manor Key, (#123458). To do this, I would type @lock eh=*Vaticus|~status:ooc|~skill_list/buildstaff:*|#123458. There are also the special MPI locks that we have. Each of those can be used through +lock. For instruction on that, as well as the use +lock in general, see below.

How do I allow other people to build their homes in my region?

If you are becoming a region master and want people to be able to build in your region, you need to do a couple of things. First, set your region parent abode. By so doing, now anyone can create subregions in your region. If you wish for only people that you specify to be able to do this, that is fine too. For this, you need to use the region +lock. The command is +lock <Object>=region=<Players>. For a full explanation on the +locks, see below. Once you have done that, your region is now setup to function as a 'town'.

How do I use roomtypes?

Unfortunately, at the time of this writing, +roomtype is not working. However, when functioning, it will become a powerful resource for us. For the record, I will explain its use below, so that it can come into use when it is working. For those of you who have been with the regioning system for a long time, you may recall our previous version to the one we have now had Outdoors, Indoors, and Sky parents. That system had a lot of shortcomings, though, so this new system was developed. Now, for one, you have have an unlimited number of roomtypes at your disposal. A roomtype is just that, a type of room within a region. You can have any type that you like, Indoors, Outdoors, Sky, Underground, Forest, Underwater, etc. You are able to make up any that you like. Why do we need these? Well, there are some functions that you will want to only effect certain types of rooms. For example, when we have our functioning weather system, that will only effect outdoors rooms. Of course, it would not be raining indoors or outside. This is how we tell it to decipher between types of rooms. There are two ways to use this. First, you can use it when creating new rooms from scratch. Now, we will be adding onto our @dig command. (Note: This was always part of @dig, but this is an optional section, so it was not needed above.) The command is now @dig <Room>=<Parent>===<Roomtype>. Yes, that triple === is supposed to be there. Those are other parts of @dig that we will look into another time. For now, just use it as is. Of course, if your room is already in existance, you cannot use that method. Instead, use +roomtype #set <Roomtype>=<Room>.

How do I create actions in my rooms?

There are many ways you can do this, actually. Actions are really exits, and exits are really actions, they’re the same. However, for the purpose of making a regular action, you use you @action command (@act for short). Syntax for this is @action =. Action-name is, quite simply, the name of the action. You run the success (or @fail, if locked against) by typing the action name. Source, is where the object directs data. Now, to not over complicate things, let’s say that in an exit the room you are exiting to is the source. Well, in an action, the source is where you are exiting to (remember that exits and actions are the same). If you do not want your character to be moved, there is a global exit that will help you. It is called $nothing. It is actually a MUF program, which basically goes nowhere, and does nothing, by design. So, if you don’t want to be moved around on the action’s execution, then make $nothing you’re action’s source. To set a message, simply use success/fail as described earlier.

How do I change the parents of my rooms?

Parenting of rooms can be important depending on different things. To move any object anywhere (some restrictions may apply) you can use the @teleport command. Syntax for this command is @teleport =. A short name for @teleport is @tel. This command will move the object, to it’s new location. Since parents are basically rooms within rooms, you are just moving one room inside of another.

How do I use regnames?

Regnames, are “easy references” to other objects. They are stored in properties, for example, $nothing (discussed above) is actually a regname to a program, which is stored in one of the parent room’s as the prop /_reg/nothing:. The $ is prefixed when you refer to an object, so the difference between a name and a regname can be made, much like when referring to a dbref#, you place a # sign before the number, or a * before a player’s name, to refer to a player (although, not always necessary). So, _reg/ is where all the regnames are located, they can be attached to objects, players, parents and so forth.

How do I make a script?

+ Drakain says, "Does anyone know what he meant by "How do I make a script?" I have no idea what to write for this..." (Group chat: staff)

+ Salabim hmmms... (Group chat: staff)

+ Marie says, "Scripting. The pre-writing of commands. Just talk about Notepad/Wordpad, how you can write out all the commands first and check them over and then cut and paste. It's easier in some occasions than going one line of program at a time." (Group chat: staff)

+ Salabim says, "But it sucks if you mess up one command and it messes up completely." (Group chat: staff)

+ Drakain says, "I've decided I'll just paste this little burb we said into it." (Group chat: staff)

How do I use the +locks?

+lock is an interesting command, it allows many things to be done in the game, that were simply not possible with the old flags that you had to @set, and your options were very limited. Basically it will allow you to lock an exit, room or other things, with permissions. For example, you can set who can spoof in a room, who can teleport an object and so forth. Simply typing +lock will give you a list of commands, and you can access a list of locks by typing +lock #list, and that will give you a list of every lock type the muck has, with a brief description of it’s effects adjacent to it.

You can set locks with the syntax +lock ==, much like @locking an exit, with a key, you set the key the same way.

Lastly, you can set a lock open to anyone by using $~Anyone as they key.

See Also

• ‹ +Community Room Listings
• Using the +mapper