Building 103 -- Players and Rooms An Explanation of Basic @Messages and Setup -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- by Wixenstyx@MUCK-U, August, 2002 ARR Type 'read book3=contents' to see what it's about. You open the book and turn to the table of contents. It says: =============================================================== Title Chapter --------------------------------------------------------------- Introduction: Review of 102........................A (2 pages) Setting Up Players.................................B (6 pages) Setting Up Rooms...................................C (7 pages) =============================================================== To read a section, type 'Read Book3=A1' Which will display chapter A, page 1. Chapter A: Introduction -- Review of 102 This is just a quick rundown of the commands covered in 102 and their functions. Command Function @Create Creates a New Thing @Name Changes an Thing's Name @Link Sets the Thing's Home @Lock Determines who may pick up the thing. @Chown Changes the ownership of the Thing to another Player. @Chlock Determines who may @Chown the Thing when it is has a Chown_OK flag set. @Flock Determines who may use {Force:} commands on the Thing. @Success Sets the message the Effective Player sees when he picks up the Thing. @oSuccess Sets the message the rest of the room sees when a Player picks up the Thing. @Drop Sets the message the Effective Player sees when he drops the Thing. @oDrop Sets the message the rest of the room sees when a Player To read the next page, simply type 'next'. drops the Thing. @Fail Sets the message the Effective Player sees when he tries pick up the Locked Thing and doesn't pass the Lock Key. @oFail Sets the message the rest of the room sees when a Player tries to pick up the Locked Thing and doesn't pass the Lock Key. @set Sets and Unsets Flags on the Thing Most of these same commands apply when setting up Players and Rooms as well. So,without further delay, let us move on! ------ End of Introduction This is the last page of this chapter. Chapter B: Setting Up Players -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Now that you've mastered Thing setup, you'll find that the other Database Items are just variations on the theme. Players, for instance, are basically just jazzed-up Things. Setting up your Player involves many of the same messages and commands that you use when setting up an Thing. The difference is in how these messages and commands are handled, given the specialized nature of Players. A. Creating a Player: @Pcreate = The @PCreate command can only be used by Wizards, but I felt it important to note that @PCreate takes care of a number of small issues: 1. Sets the Player's 'value' to whatever the MUCK's designated 'Start_Pennies' value happens to be. 2. Sets the Player's 'Home' to whatever the MUCK's designated 'Player_Start' room happens to be. 3. Moves the new Player to Player_Start. To read the next page, simply type 'next'. Player_start and Start_Pennies are both MUCK attributes that Wizards can tinker with using the '@Tune' command. If you are pursuing the Administration program at some point, you will learn more about this there. B. Customizing a Player: @Commands and @Messages Again, Players are just customized Things, so most of the same @messages and @commands are used for setup. Because Players serve a modified purpose, though, some of the @commands use varied formats, and some of the @messages are shown at unexpected times. @Commands 1. @Name: @name me= Not all MUCKs allow players to rename themselves. If this command IS available, you will be required to present your password before it will work for you. 2. @Link: @link me= This command does the same for Players that it did for Things -- sets their 'home'. In most cases, Players may set their Homes to any room they own OR a room that has its "Abode" (A) flag set. An interesting thing to note -- To read the next page, simply type 'next'. players who are 'killed' in the game are sent home, and the 'Home' command on most MUCKs will also take you home. In both cases, any items your Player carries will also be sent to THEIR homes. 3. @Lock: @lock me= This is where Players begin differing from Things. Because Players cannot be 'picked up' by other players (MUCK Singles' Bars notwithstanding), @LOCK on players was modified. The 'Key' here will determine who may rob you of coins and who may not. The Lock rules remain the same, but most people just @lock me=me and leave it at that. To remove a Lock, type '@Unlock me' 4. @Chown, @Chlock, @Flock None of these commands have applications with Players. Players always own themselves, thus @Chown and @Chownlock are useless. @Forcelock has no effect, either. @Messages 1. @Success/@OSuccess Robbing isn't exactly a big sport on MUCKs these days, but if you happen to decide to try it (Rob -- if they're not @locked against you, you'll get a whole currency unit for your trouble.) and succeed, the @Succ and @OSucc of the player your robbed will be displayed to you and the room, To read the next page, simply type 'next'. respectively. 2. @Fail/@OFail You've probably guessed this by now. When you try to rob a player who has himself @locked to a key you cannot pass, the @Fail and @OFail are the messages you and the room will see. 3. @Drop/@ODrop As a throwback to the early days of MUCKs, when they were designed to be used as Text Adventure games, there is a 'kill' command that is part of the general makeup of a MUCK. Killing a player results in that player being sent home (and sometimes paid an "insurance settlement") and all of his or her belongings being sent to THEIR respective homes. Since Players shouldn't be 'dropped', the MUCK designers of old assigned Drop/ODrop the task of appearing when a someone kills your player. 4. @Desc/@IDesc These @messages behave just as they do with Things. The @IDesc isn't usually necessary, though, as Players just don't usually carry other Players around. It can only be accomplished with the help of an administrator. To read the next page, simply type 'next'. C. Player Flags As with objects, the flags available one some MUCK servers are not always availabe on others. Below is a list of the most commonly available offerings and what they do. Check your local MUCK's helpfiles for more information: Flag Name Flag Effect Author A Player sees dbref#s on objects, even those he does not control. Builder* B Gives Player permission to use Building commands. Color C Enables ANSI-capabilities for the Player (GLOW) Dark* D On some MUCKs, this will hide a player from the WHO list and the contents list of a room. Guest* G Player restricted to rooms set 'Guest'. (GLOW) Haven H Player will not receive Pages. In_Character I Player is listed in WHO listings as 'IC'. Jump_OK J Other players may use Actions/Exits to reach the Player. Kill_OK* K Other players may use the 'kill' command on the Player. Meeper* M Player may use MPI (Glow only.) MuckerN* MN Player has MUF programming capabilities. (N may range from 1-3 or so, depending on the MUCK.) Quell Q Wizard Player will be treated as a Mortal. To read the next page, simply type 'next'. Silent S Player will not see dbref#s, even on items he or she controls. Wizard* WN Player has administrative powers (N is a range from 1-3 or 1-4 on most MUCKs) * -- Denotes Flags that MUST be set by a Wizard in most cases. ----- End Chapter B This is the last page of this chapter. Chapter C: Setting Up Rooms -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rooms make up the 'virtual space' of a MUCK. They are, like Players, modified 'things' that make use of many of the same @commands and @messages as object. Their specialized function, though, means that not all @commands are used, and those that are function in unexpected ways. A. Creating a Room: @DIG Making a new room is, in itself, very simple: just @dig However, this brings us to a more complicated subject called 'Parenting'... Parenting -- An Overview As we've already established, one of the fundamental properties of Rooms is that they can only be contained by other Rooms. This begs the obvious question, though: why would you bother putting one room inside another? The answer is a phenomenon known as 'inheritance'. One room sitting inside another room creates what is sometimes called a MUCK 'environment'. The container room is called a 'Parent', and the room it contains is called a 'Child'. As with MUSH parenting (if you're familiar with that), the Child Room 'inherits' certain attributes from the Parent Room, namely: To read the next page, simply type 'next'. 1. access to Exits/Actions and 2. any information set in properties. What this means is that a player in a Child Room can take advantage of not only the exits/actions that are set on the Child Room itself, but also those set on the Parent room that holds it, the Parent's Parent, and so on up the environment. So..if Room A has an action called 'GoHome' on it, and Room A contains Room B, Players in Room B will also be able to use the 'GoHome' action. Parent Rooms are handy for organizing MUCKs into regions. For instance, if a MUCK is a Role-Play MUCK, MUCK administrators may elect to have one are of the game set up for OOC (out of character) interaction, while another part of the game is set up for IC (In character) interaction. By putting the OOC rooms in an 'OOC Parent', and the IC rooms in an 'IC Parent', the Administrator can control which commands players have access to depending on which area they are in. To set a room's parent, you simply need to @teleport the room into the appropriate parent room. (@tel here=) If you do not own To read the next page, simply type 'next'. the Parent room, you may need to seek the help of an administrator to accomplish this. (Make sure you have the owner's permission first!) You can also set a room's parent on creation by typing: @dig = B. Customizing your Room (@Commands and @Messages) @Commands: 1. @Name: @name here= Pretty obvious -- this renames the room, just as it does with other Database Items. No special parameters or arguments required. 2. @Link: @link here= This is interesting. @Linking a room to something (a Room or an Thing) sets up what is known as a "DropTo". This means that when a Player in the Room drops an thing, that thing will be transferred to the Room's 'DropTo'. There only exception would be an thing that has a 'sticky' flag set, as such an thing would be teleported to its home, not the DropTo. To remove a DropTo, type: @unlink here 3. @Lock: @lock here= To read the next page, simply type 'next'. @Locking a room determines who can and who cannot see the room's description. Strange, yes, but true. To remove a Lock, type '@Unlock here' 4. @ChownLock: @Chlock here= As with things, this determines who may @Chown the room if the Room has a Chown_Ok flag set. @Messages 1. @Success/@Osuccess These messages are displayed when a player successfully looks at the room. A caveat here -- @Osuccess messages on rooms tend to become very annoying very quickly, so most Builders do not use them. @Success, on the other hand, is very nearly always used, but only to trigger a MUF program that will display the Obvious Exits in a room. (@succ here=@$ObvExits, in most cases.) 2. @Fail/@OFail These messages are displayed when a player fails to pass the Room Lock. The room's description is not displayed when the player types 'look'. Locking a room against someone is rarely useful, though, so again, these messages are rarely used. To read the next page, simply type 'next'. 3. @Drop/@ODrop If a room has its Dropto set, the @drop and @odrop will be displayed when a player drops an object in the room and the object is transferred to the DropTo location. 4. @Desc/@IDesc @Describing the room sets the room description everyone sees. @IDescriptions have no practical applications on Rooms. D. Room Flags The following chart displays the flags that may be set on Rooms and their effects. As always, flags differ from MUCK to MUCK, so check your local MUCK's helpfiles for more information. Flag Name Flag Effect Abode A Any player may @link themselves to the room. Builder B Players may not use personal exits while in the room. Chown_OK C Players may take ownership of the room, if they pass the ChownLock key. Dark D Room will not display its inventory. Guest G Allows players set 'Guest' to enter. To read the next page, simply type 'next'. Haven H Players may not use the 'Kill' command in the room. Jump_OK J Players may use personal exits to reach the room. Link_OK L Players may link exits/actions to the room. Meeper M Room Desc/@messages will parse MPI commands (Glow) Sticky S If a DropTo is set, Objects dropped in the room will be transported to it only when all Players leave the room. Tinker T Wizards of lower levels may examine but not change Room settings (Glow) E. Sample Room Script [--------------------- Begin Example ---------------------] @dig My Room (should tell you the dbref# of your new room) @tel me=#1234 (dbref of My Room) @tel here=#1233 (dbref of your Parent room, if you have one) @desc here=You are in my room! @link here=My Briefcase @lock here=me @succ here=You look around. @osucc here=looks around the room. @fail here=You look around, but you can't see anything! @ofail here=looks around, but can't see anything! To read the next page, simply type 'next'. @drop here=You drop your object, and it disappears in a flash of light! @odrop here=drops something. It disappears in a flash of light! [----------------------- End Example ---------------------] In the next book (104) we'll discuss Actions/Exits! So stay tuned! ---- End Chapter C This is the last page of this chapter.