Welcome to
___________ ___ _____________________________________
/___ __/ /__/ /____________________________________/
> / ___ ________ _______ ________
/ / / / / ___ / / ____/ / __ )
/ / / / / / / / / /__ / /_ / /
/ / / / / <__/ / / ___/ / __ <
/ / / / \____ / / /___ / / \ \
/__/ /__/ / / /______/ /__/ \__\ MUCK
___________________ / /
/______________________ / A 100% Anthropomorphic TinyMU*
|
Here is a basic walkthrough of building your character on TigerMUCK. First, I'll demonstrate how to set up your character's description, gender, and all those little tidbits that come in handy. Of course, since being homeless can be kinda cold, you'll also learn how to build a home on this MUCK. Some of the MUF and programs here are a little different than other MUCKs. The general theme of the area is a laid-back sort of rural town, where everybody knows everyone else, and is a perfect place for first-time MUCKers. Friendly and helpful people, peaceful and quiet, and a fairly basic programming structure that you don't have to be an expert to use. Just one to understand. ;)
To separate the commands from the normal text so they stand out if you just want to skim through it, I've set the commands in a lovely shade of green, and the normal text in the standard black. If, however, you'd like to skip the walkthrough and have a complete list of commands for your convenience, they can be found at the end of the document, or by clicking here.
The furst and most basic settings would be your species and gender, which can be seen using the ws or whospe commands. TigerMUCK is a social MUCK with basically only one rule regarding species. No humans. Any other species is allowed, like dragons, wolves, bunnies, raccoons, etcetera. To set your chosen species, just type @set me=species: and type your chosen species after the colon. It's the same way with gender, although the command is @set me=sex: or @set me=gender: and just type male, female, boy, girl, herm, or whatever you would prefur. An extra little something that doesn't really have a specific place would be the say set. Should you rather purr or bark something than say it, it's fairly easy to set up. @set me=say_prefix:purr sets what you see when you speak, as you purr, "<text>" while with @set me=osay_prefix:purrs others see, '<name> purrs, "<text>"'. Don't forget the tense for each, as they're not automatically set.
Here's an example of what the whole deal would look like when typed up on the buffer.
Another setting that isn't really important, but is more of a just-for-fun type thing would be your smell. Typing this out can be a little more tricky, because scents can be hard to describe. Several furs tend to go almost poetic when writing up their scents, while most that I've seen just put 'smells like a -' and whatever their species is. The command for snuffling a fur would be sniff <name> or smell <name>, and the way you set your scent is by typing @set me=_scent: and whatever you want to smell like. You can also tell when somebody's sniffed you by typing in: @set me=_smell_notify:[>> %n just sniffed you! <<] An explanation on the notify and what the %n stands for can be found lower in this document.
A desc is pretty much mandatory. It demonstrates your writing ability, shows a bit of your personality, and helps furs know what your character looks like. To read a character's description, all you have to do is type look <name> and the words will scroll up on your screen. The list editor is a wonderful tool for editing descriptions. It has a more-or-less unlimited output, making for a chance to get pretty descriptive. It's advisable to keep your desc to less than 20 lines of 75 chars/line. That way those with dumb terms/raw telnet don't get flooded with more than will easily fit on a screen. Also, when it goes to multiple screens, most people tend to skip over your carefully written out description. To open the list editor, all you have to do is type lsedit me=mydesc and it'll bring up a prompt for you to start typing. As you input your desrpition, and you realize you want to change a line you just added, or want to remove it for some reason, just type .del and it'll remove the line most recently input. (There's a period (.) typed before every command in the list editor. If you forget the period, it'll just be added to your desc.) However, if you would like to cancel the entire process and not save your work, just type .abort and you'll go back to the normal MUCKing. Once you're finished and satisfied with how it turned out, type .end and it'll save whatever changes you've made. If you need help while in the editor, .h will bring up the help file on the program. Here's an example of a fairly decent layout, using my own normal fur morph. I chose to lay it out in three paragraphs, but it can be written however you feel. . Anyways, since the text will wrap on the page, I'll put a little <enter> whenever I press, you guessed it, enter.
Now that you have your description all typed out, I suppose you'd like to apply it to yourself. Well, that's the easy part, but there's a simple setting so that you can tell when someone has looked at you. It's a quick and simple bit of MPI scripting added to your settings as well as your description. No, you don't have to reopen the list editor, this is added separately since it's a programming thread.
Furst you have to set the message for when someone looks at you. Just type @set me=_desc_notify_looked:[{name:me} just looked at you!] into the buffer and the message for you is set into place. What you'd actually be seeing, instead of {name:me} would be the name of whoever is looking. The {} demark a section of MPI code which reads the name of the fur looking at you and displays that in it's place. Instead of having the {name:me}, you could also type %N and that would accomplish almost the same thing, although tends to be altered with a simple command. An addition to that is for letting the looker know that you know they took a look. The setting for that is @set me=_desc_notify_looker:[%n knows you looked.] which as you can see is pretty much the same, excpet for a couple details. The refers to your name this time, and is set that way to be dynamic just in case you feel like changing your name. Now to make these two commands active and attach your description at the same time. Basically, you just have to type @desc me={look-notify:{list:mydesc}} and everything there is set. What you actually have there is a short dollop of MPI script. The look-notify tells the MUCK to display the notify comments which have been typed earlier, and the list:mydesc tells the program to look through your morph list and display the one titled 'mydesc'. Simple, no? If you prefer the simple bare-bones command structure, just click here for the demonstration.
There are several options when building or choosing a home. There's an apartment complex overlooking the beach on the east side of TigerMUCK, and is owned by Mourdrin. To claim a home, just page #mail him with a request for an unoccupied apartment. The other option is to just make it yourself, which isn't as hard as you'd think.
Preferably, you shouldn't build a home floating off in space that is disconnected from the primary MUCK area. Part of what we're trying to do is have a feel for a real community rather than a bunch of disconnected chat rooms, so please plan your home out completely before building it. Another thing is before you've even started building, page Tigerwolf and ask him if you can link your home to a certain spot somewhere in the main area of the MUCK, such as branching off of one of the currently constructed roads. It's best to ask beforehand, so you don't find out later that it's already full.
First step, of course, is to make something. Typing @dig home makes a room labeled 'home', for example. If this is done successfully, you should get 'room "home" created with dbref#<number>' Remember that number, you'll need it repeatedly. The only way to get to this room so you can edit it a little more comfortably would be to set it as your home. Just type in @link me=#<dbref#> where <dbref#> is actually the number of your room. Once that's set, the command gohome or home will take you to your brand new pad. Just as a suggestion, it would be a good idea if you called it So-and-so's lair, or something similar. Don't want a muckfull of 'home' rooms.
Now that you've built your home, it would be probably be nice to describe it just in case visitors might come by. Describing the room is just like describing yourself. Just type lsedit <room name>=roomdesc and the rest is already covered. Again, as just a note, it would be advisable to type out the rough draft of the room's desc on a word processor before loading it into the MUCK. Since the room doesn't need a look-notify, the command for attaching the description is @desc home={list:roomdesc}
Unlike on most mucks, TigerMUCK doesn't have a program for making exits visible in your room description, so it has to be done by hand. Just add the rooms to another line in the description, as well as their location. for example, one line of the exits for the central park looks like this: Exits: Tiger Blvd (n) Veterinarian's Office (ne)
Now here's the fun part. Either building a simple one-room cave or elaborate mansion complete with a surrounding countryside, you will have to find out a few more niggling details about building. For instance, is it outside or inside? What quadrant of the MUCK is it in? As soon as your home is planned, and the location thought out, you have to pay attention to this for all included rooms because there is an MPI that should be added to every room as it's being built. To relate if the room is indoors, you have to type @dig <room name>=$indoor, adding it to the digging command. If the room is outdoors, then you put @dig <room name>=$<parent>. The parent name has to be one of five places: foxlane, pantherdrive, river, tigerroad, or wolfrun. You really need to specify which section your home or building is in, and label each room as such, using the command .
If you would like to leave the house and don't know how to get out, just type in the command park and it'll bring you right back to the central park. To review the commands in this section, just click here.
There's a 'look trap' in the server so that furs can decorate a room with lookable objects without actually creating an entire object. Saves on db space and won't run up the fur's object quota. Preferably, @creating things should be limited to real and needed objects. It's fairly simple, and instead of taking several lines of code to construct, only takes one line for each separate object. Say, for instance, you would like to make a lamp, but don't want to do through the process of building the lamp, linking it to the room, locking it to yourself, etc. All you would need to type is @set here=_details/lamp;lantern;light:You see a bright shining lantern. That would create a detail on the room of a lamp you could look at by using look lamp, or look lantern, or look light, and get the result, "You see a bright shining lantern." Simple enough. And this can be done with just about anything.
Building furniture is like creating any other object. It's a very short list of instructions, the only one requiring much thought being your chosen description for whatever you may be building. Anything could be made, from desk lamps to four-poster beds. It would be best to keep the object furniture minimal, you can easily just add the small decorative stuff to the room's description.
Anyways, first step is @create couch which creates an object entitled 'couch'. The couch is placed in the collections of objects you're carrying, usually known as the inventory, type inv to check. The command drop couch to let it fall in the room with you, and @link couch=here sets that room as it's home. To keep others from lifting your couch and carrying it away, type @lock couch=me and nobody else can be able to pick it up.
To describe your couch, all you need to do is type @desc couch=<text>. The lseditor isn't needed for simple objects, because the description of them shouldn't take up very much space. For simple objects, you should have a fairly simple description, since there isn't much point to being detail-oriented about a thingy that very few furs are likely to look too closely at.
Anyways, back to the matter at hand. Here's the command list of what I just said, in case anything was missed.
Chances are, if you want to show off your building skills to all and sundry, you'll want to make more than one room. It's fairly simple, and the only thing besides just @digging a bunch of rooms would be setting exits and making certain they work.
Say you're standing in a room you just built. Already have it set to the proper environment and all that. Opening an exit between the two takes a simple command, which sets the exits in both rooms simultaneously. mbl <dir>=<destination db#> Where <dir> is one of the eight cardinal points (n, ne, e, se, s, etc.) This is best for an outdoor environment, where the directions are usually done by the compass. Indoors can be done like that as well, but another way is to go by room names or however you like. the 'mbl' command also does in/out. Quite handy, eh? :)
If, however, you would like an exit that cane use multiple commands to get through (west, w, in, door), then you'd still have to open the exit manually. Say, you'd like to open a door from your kitchen to the dining area, and you would like the dining area to be east of it. Type @open east;e;d;dine;dining=#12345 where #12345 actually is the dbref# of the dining room. This'll open a one-way door from the kitchen to the dining room. To make the exit go both ways, go through the door into the dining room and repeat the procedure, only with the exit being something like west;w;k;kitchen=#31245 and #31245 is actually the number of the kitchen.
If you like, here's the command list for your viewing pleasure.
Exits have four basic properties that make them interesting. @succ, @osucc, @drop, and @odrop. The @succ is what is visible to you as an action or exit is successfully used, the @osucc is what is visible to others in the original room as an exit or action is used, the fur's name is ~always~ prepended to the @osucc and @odrop. The @drop and @odrop work the same way, except that they are at the end of an exit, what is used as you enter the next room. These are also always attached to the exits. As an example, when someone goes through an exit and you want the message "X enters the bathroom, looking in dire need to answer a call of nature" to be visible to the rest of the room, while for the fur in question, you want it to simply say, "you enter the bathroom," the commands go like this. @succ <exit#> = You enter the bathroom and @osucc <exit#> = enters the bathroom, looking in dire need to answer a call of nature. The @drop and @odrop work the same way. If you want it to say, "You've entered the bathroom, enjoy!" to the fur entering, while you want it to say "X has just entered the bathroom. Better make yourself modest!" to those already occupying the room, the process is nearly identical. @drop <exit#> = You've entered the bathroom, enjoy! and @odrop <exit#> = has just entered the bathroom. Better make yourself modest!.
Here's the command list for your viewing pleasure.
Another convenience is locking the door, in case you want to have an exit only you can use, or wish for some guaranteed privacy. There are two methods, one which requires a 'key' to get past, and the other which is set to specific players. For instance, @lock <exit>=Tigerwolf_is_God:yes. The only way a person could pass is if they have done @set me = Tigerwolf_is_God:yes. The other method filters out everyone except those you've specifically chosen. For instance, say you want to lock an exit against everyone, except yourself and two friends, let's say Bob and Frank. You enter in the command, @lock <exit>=me|*Bob|*Frank and don't forget the |*.
As are normal exits, locked ones are able to be modified with @succ, @osucc, @fail, and so on. The @fail is if the person is ~not~ set to go through the exit, and displays as such.
There's a couple useful building globals on TigerMuck, labeled exitcheck (ec), make-bdirectional-link (mbl), and quickexit (qe).
Exitcheck shows what exits in a room or parent are missing messages. For instance, if you've done a bunch of building, and you might have forgotten to set the @succ etc. on the exit, then you can use this to be absolutely certain whether you have or not. The command is used as either ec <room> for one specific room, or ec #allrooms to check the exits on all the rooms you own.
Mbl is used as a shortcut to make an exit head to one room from the one
you're in, and have a return exit at the same time. However, it's only for use
with the cardinal directions. (N, NE, E, SE, S, SW, W, NW) Any other exit name
will get you an error message. The syntax for this command is mbl
<exit>=<roomname>, and you must be standing in one of the rooms to
be linked to do so.
Quickexit is a bit more complex than the other two, and is used for quickly
setting the desc, @succ, @osucc, @odrop, and should the exit be locked, also
prompts for the @fail and @ofail messages, which have been explained above.
qe <exit> is the first method, which will
start the process for the given exit. With each prompt, you input the proper
text into it, and if there's already a setting for that, then it will display
the previous message and give you the option to either change it, or leave as the original text. If
you don't want to change anything, then just type in a . to leave it unchanged.
qe #here cycles through all the exits in the given room, saving you
a bit of time if you wish to do all of them at once.
Here's the command list for your viewing pleasure.
To give that couch, or Tiffany lamp, or old shoe that your zombie chews on some personality, there are a couple simple processes for attatching an entertaining action to anything, and even to an object that isn't really there. (see look trap) A perfect example would be a cannon for the vintage pirate ship SeaWolf is building on the muck. She wanted a cannon for the ship to shoot at Mourdrin's apartments, just to have fun. The cannon was intended to 'load' and 'fire', one not necessarily following the other.
The cannon was built as any other object, @create cannon.After making this and creating a simple description hinting at the two actions that are to be attached to it @desc cannon = A solid iron cannon, just waiting for someone to 'load' it and 'fire'. Then, I created the first action. @act load = cannon which creates an action called 'load' and attaches it to the cannon The action is given a dbref# of it's own. Usually, it's easier to refer to an object by it's number so if there's something else in the same room with the same name, you won't be getting any weird error messages. Once this is done, I put @link load = #828 which attaches it to nil, and basically makes it to be a blind exit. If you forget this step, the @succ and @osucc won't work. To make the action have any meaning, the message for the person loading the cannon was set @succ load = You load the cannon! while the message for the others in the room was set as @osucc load = loads the cannon! Everybody step back!
The next action, 'fire' was created in much the same manner. @act fire = cannon to create it and attach it to the cannon. Then @link fire = #828 to keep it from heading anywhere. The success messages were different, of course, as it's for a different action. The message seen by the fur firing off the cannon was set @succ fire = You fire off the cannon! while the message set for the other furs in the room was set as @osucc = fires off the cannon! The ball goes whooshing high overhead before landing somewhere inland and obliterating some poor random furs home. Awwww. ;)
Here's the command list for
your viewing pleasure.
Page copyright © Ben Raccoon. All the stuff involving TigerMUCK is © Tigerwolf.
Thanks to EverGuest, Uck, SeaWolf, GrayWolf, Sass, and Kenti for their help, and TigerWolf and Dragon for their patience and assistance.