Builder's Manual
This manual assumes you have either read the Schoolnet Moo player's manual (available on the Schoolnet gopher and web site), you have completely gone through the courses taught by tutor (at the time this tutorial is being written tutor is not completely finished) or you are knowledgeable of all the basic moo commands. These basic commands include say, page, @who, @where, whisper, @move, @join and emote. This manual will explain much of what is required to pass your programmer's test with the exception of using the editors.
The distribution of this document is unlimited as long as it remains unmodified from its original state. This manual was being designed with Schoolnet Moo in mind. Some commands may not work or may be different on other MOOs. This is version 1.0 of this documentation.
INTRODUCTION
Throughout this document I will enclose command which can be typed or the syntax of commands in quotes ('). These are only to help you distinguish a command from the text and are not to be typed.
Many of the commands introduced in this section will not be accessible to you until you have received your Builder's Permit. For more information on receiving one read the next section entitled 'Before you begin'.
All MOOs are based around objects. Each object on the moo is allotted a number, which is used to represent it. All object numbers begin with a # prefix. An example of a valid object number would be '#1'. Everything on the moo is an object from a player to a sign. On a moo every piece of code (a verb) and every property (which is used to store data) are all on objects.
Every object (with the exception of object #12) has one parent. On a moo objects with the same parents will inherit properties and verbs from them. Objects which have the same parent are called children of that object.
This can be compared to a family tree. For example your grand parents would have your parents as children and you would be one of you parents' children. As you would inherit genes from your relatives in real life, on the moo children of an object would inherit its verbs and properties instead.
Now let's take the generic thing as an example, it is used as a parent of all physical objects from a note to a container. It will inherit verbs and properties from the Generic Physical Object (#77), Root Class (#1) and the Generic Object (#12). To find out the parents of an object you can type '@parents ' and to find out the children of an object type '@kids '. For example you can type '@parents #6'.
Every object on the moo is owned by a certain player. Whenever a player creates an object it takes up some of their quota. The quota system was implemented to prevent the moo from taking up too much space and to prevent players from wasting space with useless objects. There are two types of quota object quota, which limits the amount of objects you can create and byte quota which limits the size of objects. To find out how much quota you have type '@quota'. Also you can type '@quota ' to find out how much quota someone else has. An examples of using this command targeted at someone else is as follows, '@quota Daryl'.
Also every object on the moo is located in a different location. The location of an object can be changed by using the @move command. This syntax of this command is '@move to '. This means I could type '@move #1 to #2'. The objects, which are inside another object, are called its contents. To find out what objects another objects contains you can type '@contents '. For example you could type '@contents #3887'.
For more information on the topics discussed in this chapter, you could look in the online help files. The following topics may be useful: @quota, @move, @kids, @parents and @contents
BEFORE YOU BEGIN
Before you can start building you must first become a builder. If you have already gotten you builders' permit you can skip this section but otherwise pay close attention. To become a builder you must take a builder's permit from Administration, which is downtown. If you are not already in the grassy knoll type '@move me to #11'. From there go east, then east again and then north. The next step is to take a builders permit from the promotion wicket. To do that type 'get builder's permit from promotion wicket'. Finally you must type 'accept Daryl's Builder's permit' where you name on the moo takes the place of Daryl. You are now a builder and you can continue on with the tutorial.
For more information on the topics discussed in this chapter, you could look in the online help files. The following topics may be useful: promotion and ranks
GETTING STARTED
In this section I will explain how to get started building and I will help you get familiar with some of the most commonly used objects. It is only possible to create a child of objects that you own or objects, which are set fertile. There are many objects which you can create children of and modify to you own needs. I will be discussing several of those below.
We will begin by create a child of the Generic Thing which can be used for pretty much any object. I will use a coin as an example for demonstrating how the following commands work.
Before we can create anything though we must know which command to use. This command is @create. Its syntax is '@create called ""'. So to actually create a coin I could type '@create $thing called "Coin"'. For that command you will get a response from the server which looks somewhat like this 'You now have Coin with object number 1120 and parent Generic Thing.' This tells you the object's number, which in this case is 1120, and its parent, which is the Generic Thing. Once you have created the object you will find that is it in your contents.
The next step in creating our coin would be to describe it. This description will be seen whenever some looks at your object. The command to describe any object is @describe, its syntax is '@describe as ""'. So to describe the coin you could type '@describe coin as "You see a small shiny silver dollar."' In the example we were able to refer to the object by its name only because the object was near us (in our contents or in the same room). Normally you will have to refer to the object by its object number (in this case #1120). Now you can type 'look coin' and you will see your description.
Another useful feature on objects are messages. They allow you to set the message which, is displayed when a certain action occurs. There are many different messages, which can be set. To get a list for a specific object you can type '@messages '. So using are example of the coin you could type '@messages coin'.
Let's set one message on the object so it will be displayed when something happens to it. The syntax to set a message is '@ is ""'.
Let's start by setting the message that is displayed when someone picks up your coin. The two messages which must be set are otake_succeeded (which is displayed to everyone in the room when some takes the object) and take_succeeded (which is displayed to the player actually taking the object). The o used as a prefix in message names shows that it will be displayed to everyone except the player who actually typed the command.
So to set these messages we would type '@otake_succeeded coin is "%N picks up a coin. He finds that he is now a dollar richer."' and then '@take_succeeded coin is "You pick up a coin. You find that you are now a dollar richer."' In messages when %N is used it is replaced with the name of the player who typed the command. Now when someone tries to pick up you coin they will see those messages. Why don't you try that out?
Now let's head on to another example remember to keep your coin though because it will be useful latter. The next thing that we will make is a bank to keep your money in. We will use the Generic Container instead of the Generic Thing for this object's parent. The Generic Container is normally used for things like boxes, which other objects can be put in. The Generic Container is a child of the Generic Thing.
Ok, following what you learned in the example above, create a child of the Generic Container (#8) called Bank. Next give it a description. Finally when you are done, drop the object.
Using the example above explaining messages, set the message which is displayed when you put an object inside the bank (hint: put and oput) to 'You put a coin into a slot on top of the bank and it falls inside.' and using the previous message modify it so it will be sufficient to be displayed to everyone else in the room.
You may now recycle your coin and bank since you no longer have a need for them. To do this you use the @recycle command. The syntax for this command is '@recycle '. So in the case of the coin and the bank you could type '@recycle coin' and then '@recycle bank'.
For more information on the topics discussed in this chapter, you could look in the online help files. The following topics may be useful: @create, @recycle, @describe and @messages
BUILDING
In this section we will discuss the building of rooms and exits. The only new command which will be introduced is the @dig command which has many different forms. We will use a house for the example in this section.
To begin we will use the simplest syntax for the dig command which is '@dig ""'. We will start our house off with a living room. So we would type '@dig "Living Room"'. The server will then send you a message like 'Living Room (#) built.' Now a good thing to do before you continue would be to move to this room. (Note: This can be done by typing '@move me to ')
Now as you did with your bank and coin a good next step would be to describe it. Now the command require the exact same syntax which is '@describe here as ""'. (note: here is used as a pointer to your current location.)
The next topic to be discussed are exits. Exits allow you to connect two rooms together. So if I wanted to get to the Hallway from the living room, I could make two exits joining the two rooms. So if you went north from the living room, you would find yourself in the hallway and vice versa if you went south from the hallway.
The syntax of the next form is '@dig [,] to '. This will create a new room called and dig an exit to that room where the exit is called and can also be referred to as (Note: It is optional to include the ). So if I typed '@dig north,n to "Hallway"' it would create a room called Hallway and make an exit to the north which would lead to that room. However this form can get quite annoying because it involves extra typing because you must also link the new room back to the original source. So that is where the next form of the @dig command comes in, '@dig [,]|[,] to '. This will pretty much do the same thing except that it will make two exits, will lead to the newly created room while leads from the newly created room to your current location.
So to continue on with our example we will now dig from the living room to the Hallway which will be created. To do this, you would simply type '@dig north,n|south,s to "Hallway"'.
There is one final form of the @dig command which allows you to @dig to a room which already exists. This command uses the exact same syntax as the other commands except that is replaced with the object number of an already created room. So here are the two forms of the @dig command which allow this feature to be used, '@dig [,] to ' and '@dig [,]|[,]'.
For more information on the topics discussed in this chapter, you could look in the online help files. The following topics may be useful: @dig
LOCKING
Locking allows you to secure your objects against other players. For example you could use a lock to stop anyone who isn't carrying a certain object from going through an exit or you could prevent anyone from picking up a particular object. The commands used for locking are @lock and @unlock and in the case of preventing someone from reading a not, encrypt and decrypt.
The syntax of the locking command is @lock with . Where the is the object which you want to lock and key is a statement which is evaluated before a user can perform the action which the object is locked against.
As I explained in the first paragraph of this section a @locking an object can do different things. What locking an object does it dependent on it's parents. Below is a list of the effects on locking for different parents:
+ Locking a $thing will prevent a user from picking it up unless they meet the requirements of the key
+ Locking an $exit will prevent a user from going through it unless they meet the requirements of the key
+ Locking-for-opening (@lock-for-open) will prevent anyone from opening a container unless they meet the requirements.
+ Encrypting a $note will prevent anyone from reading it unless they meet the requirements of the key.
The simplest possible key would be '#1' which would only let a player with the object #1 or an object carrying object #1 use the object. Now if you wanted to do just the opposite of that and prevent a user with object number #1 or a user carrying object #1, you could use '!#1' as the key, meaning not #1.
Now if we wanted to make our key even more specific, like the user had to be carrying both object #2 and #3 we could use the && (and) operator. The condition above could be done using a key like '#2 && #3' meaning #2 and #3. A useful thing that can be done with the and operator is preventing any user whatsoever to use a specified object, this could be done with a statement along the lines of, '#1 && !#1' that means #1 and not #1 which, is impossible because no object and be both an object and not an object.
Another useful logical operator is the || (or) operator. This will allow an object to be locked with one object or another object. So if I specified a key such as '#2 || #3' any player who was referenced by or was carrying either object #2 or #3 would be aloud to use the object.
All of these different expression can be used in combination as in this example, '#1 || #2 && #3' meaning if the player was or was carrying either object #1 or both object #2 and object #3. In a locking expression you can also sure parentheses to enclose statements, as in this statement '#1 && (#2 || #3)'. These parentheses will make your statement look much neater and in some cases change the result.
The ? operator can be used to check the lock of another object and if the player attempting to use the object which used the ? operator passes the lock on the other object which was specified then the expression returns true. So if the key of object #1 was '#1 && !#1' and the key of object #2 was '?#1' then no matter which player tried to use object #1 they would be unsuccessful, now if the key of object #1 was set to '#3' instead and the player trying to use object #2 held the object number #3 then they would be able to use object #2.
Finally let's say that we had object #1 called Green Key which was the parent of both #2 (Red Key) and #3 (Blue Key). If we wanted to lock an object with #1 or any children of it we could use a key something like this '~#1'. This operator will lock an object with the object specified and any of its children.
To undo any locking or encrypting you have done you can use the @unlock (or decrypt) statement. '@unlock #2' would clear any locking which had been done on #2.
Before we move on to other things I will provide several full examples of locking included with an explanation:
@lock door with "#1 && #2 || #3 || ~#4" would lock the door so only someone having the number or carrying object #1 and either having the number or carrying object #2 or object #3 or is carrying a child of #4.
encrypt letter with "#1 || #2 || (#3 && #4) || #5" would encrypt the letter so only someone carrying or having the object number #1, #2, #3 or the numbers #4 and #5.
For more information on the topics discussed in this chapter, you could look in the online help files. The following topics may be useful: @lock, @unlock, encrypt and decrypt
CONCLUSION
Well this brings us to the end of our Builder's Tutorial. I would like to wish you good luck in your Programmer's Test which can be taken by accepting a Programmer's Permit that can be found in Administration (in downtown). Also it may be a good idea to read up on your editor commands before you take the test, there is a good manual available on this subject in the Schoolbook Depository.
For more information on moo programming, you may want to take a look at Odo's Programming Tutorial (available from the Schoolbook Depository) and the indispensable Lambda Moo Programming Manual (available from ftp://ftp.lambda.moo.mud.org/pub/MOO/).
If you have any comments, suggestions, questions or complaints about any part of this tutorial please do not hesitate to contact me. I can be contacted on Schoolnet Moo under the character name Daryl or using e-mail at nstn0416@fox.nstn.ca.