*** Star Trekmuse Help Documentation *** V2.4 ** Please note : This HELP document is a direct rip-off of the original MUSH-help documents, and those who updated this document wish to take no credit for the bulk of the work done here. For the most part, the ideas/commands presented in the manual are up-to-date with the current Trekmuse commands. If you have any problems, on Trek or any other MU*, be sure to check your local on-line Help Document for rule clarification. -- Edited by qImDaQ -- aladdin@u.washington.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= TABLE OF CONTENTS Section Topic ======= ===== 0.0 New Edition "Improvements" 1.0 Introduction 1.1 History 1.2 MUSE Overview 1.3 Objectives 2.0 Attribute Lists 2.1 New Attributes 2.2 New Flags 3.0 General MUSE Commands 3.1 Commands Not Supported 3.2 Changes to Old Commands 3.3 More Commands 4.0 Puppets 4.1 @Force and Objects 4.2 The PUPPET Flag 4.3 @Sweep 4.4 The KEY Flag 4.5 New Commands - @Attach and @Detach 5.0 Action Lists 5.1 Common Action Lists 5.2 Grouping Commands using {} 5.3 Costs of Running Machines 6.0 Other Triggers 6.1 @Listen/@Ahear 6.2 @Halt 6.3 Wildcards/Variables 6.4 Cost and APAY 6.5 Charges 7.0 Commands and Functions 7.1 @Wait 7.2 @Switch 7.3 Introduction to Functions 7.4 Functions RAND() and TIME() 8.0 Programming Machines 8.1 VA - VZ, WA - WZ, XA - XZ 8.2 @Trigger 8.3 Using Registers for Storage 8.4 Numeric Functions 8.5 Functions That Manipulate Strings 9.0 User-Defined Commands 9.1 How They Work 9.2 Security 10.0 Making Programming Easier Through Functions 10.1 Example 1 10.2 Example 2 10.3 Example 3 10.4 To Sum Up =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 0 Upgrades found in this edition -- Keyed to changes in TrekMUSE code -- Additional examples added -- Help keyed to more programming help 1 Introduction 1.1 History TinyMUSH was written as a direct result of the original TinyMUD's crash and burn due to terminal database bloat. This problem was solved in MUSH by using more efficient methods of data storage as well as the implementation of a destroy command, which allowed for the removal of unwanted objects from the database. After the @destroy command was implemented, additional features were added, either from the author's own ideas or player's requests. It was not unusual to see one's suggestion running on MUSH the next day, or even in several hours. During this time, MUSH began wandering from site to site. It started at smelt.berkeley.edu, and then moved to sigh.berkeley.edu. After a brief vacation in Kentucky, it returned to sigh. However, sigh was later removed from service after a failed OS upgrade, and TinyMUSH, as of this writing, is no more (although there is a backup of it's data base.) Fortunately, several other MUSHs have come online. The two major ones, TinyTIM and TinyCWRU, have added their own home-grown modifications to the original MUSH, which may at a later date become "official." This manual will attempt to cover these additions as well. Not included in this version of the manual are the last additions that were made on TinyMUSH, since they have not made it to any other MUSH (PernMUSH has many upgrades not listed here, for instance). The MUSE that you now play on is a further upgrade of this original coding, and includes many new features. However, many of the basic ideas found in MUSH's and MUCK's work in the MUSE, there are just more commands and a wider range of uses. This document has been geared specifically towards the Trekmuse, though it can be used as a standard template of information for practically any MU*. 1.2 MUSE Overview Programming in TinyMUSE can be likened to traditional object oriented programming. All actions are achieved as a result of objects reactions to their environment and to each other. Objects can modify themselves and each other, as well as create new objects (spawn processes) that can handle a task and then terminate (destroy themselves.) Some low-level math is provided, as well as 78+ "registers" per object which can either hold data or program code. Objects can also perform most of the actions that real players can, so that they can interact with players. Objects can be set to respond to a number of different stimuli, such as things they "see" or hear, receiving credits, being dropped or killed. This allows for the creation of autonomous machines which can be running even if a player is not logged in. These machines can fulfill many of the purposes that robots were used for on TinyMUD, and allows mere mortals to create robot-like objects. A quick nomenclature of objects in MUSE (in hopes of establishing up a standard.) An object which is under the direct control of a player and/or is relaying what it hears back to its owner is called a puppet. Objects which are "running a program" so to speak are called machines. Machines may interact with players, react to what they hear, or may just go about randomly ignoring the outside world. Robots are either players that are under the control of a remote program (such as Julia of TinyMUD fame) or special players which are under the control of other players. Quite often people will refer to machines as "bots," but are not to be confused with the genuine article. MUSE resembles a "shell scripting" language more than anything else. If all of the above seems a bit complex, don't worry. Programming in MUSE is usually simple if you know the commands, and now that you have this manual, you will. The Trekmuse itself has been around since 1990, and its source code has been sufficiently modified that its code no longer has much "MUSE" connection, and as such is called the Trekmuse rather than TrekMUSE. 1.3 Manual Objectives and Assumptions First, this manual assumes you know the basics of TinyMUD. If you have never been on a TinyMUD (or one of its derivatives) before, it is highly recommended that you get a manual on TinyMUD and learn the basic commands before you try any of the advanced material in this manual. A introductory guide to TinyMUD is probably available from the same place you got this document. Most, if not all of the commands in MUD should work on MUSE. Just so long as you know how to look, move, examine, page, talk, pose, etc., this manual will get you going. If you are what is affectionately referred to as a "total newbie", you may want to spend some time on the MU* first, getting used to the basics. This document will take you very far very quickly in the world of MU* Programming. Second, this manual is not designed to give away all of the "tricks of the trade" in MUSE programming. It is impossible to cover everything that can be built in MUSE in a finite document. Just remember that all the things in MUSE are made up of the commands in this document, and you should be able to figure out a way to do just about anything. The majority of this manual is excerpts from session logs of Croaker creating and doing various things. To clarify just what is going on, the following conventions will be observed. The extracts from the script will be sectioned off from the text by a header line consisting of two dashed lines around a statement of what the example shows. A greater-than sign, ">", at the beginning of a line will indicate text typed in by the player (me.) If you wish to duplicate the example, you should type the text after the ">." Please note, to avoid confusion, if the typed text "wraps around" the screen (i.e. is continued on the next line) there will not be a ">" on the next line. Also, the output from a command will be separated from the next command by a blank line. All comments added in later for clarification listed will be enclosed in a ">>" and "<<." Finally, to indicate the end of an example session will be another dashed line. -------------------------------- Example: an example session -------------------------------- >"This would be a command that I typed in. You say "This would be a command that I typed in." >> This is a comment, and the text directly above is the << >> output from MUSE in response to my command << -------------------------------- And the bottom bar ends the session. Several more notes. A lot of the things in here are much easier to do if you are running a client program. I won't go into creating TinyTalk macros and such, but be aware that they can make your MUSEing experience a lot easier. Also, through out the following sections, I may use the term "player" with respect to commands. All commands also work for objects (whether they are operating autonomously or under player control.) The use of the word "player" in these sections therefore means "players and objects" except where stated otherwise. To be concise, I will use the terms TinyMUSE and MUSE interchangeably. Also, MUD will refer to TinyMUD, not the original MUD or AberMUD or WhateverMUD. Lastly, most commands listed within this manual also work to some extent on other systems, but in many instances I will refer to "Trekmuse". Whenever I refer to "Trekmuse", I am referring explicitly to the coding within the Trekmuse. If I merely use "MUSE", then I am referring to all MUSE's in general, in one form or another. 2 Attribute Lists Attribute lists are what makes MUSE go. Simply stated, they are a place in an object where information can be stored. MUD had attribute lists of a sort, like the description (@desc) or success message (@succ.) There are many more attribute lists in MUSE, and they are much more powerful. Here, they not only store messages, but also commands and numbers. The attributes are set in the same method as they are in mud, namely: @ = like: @desc me = A toad. @sex me = Male? @race me = Zarg! Additionally, some MU*'s contain the ability to set player-defined attributes, which must be set and referenced differently -- using the '&' command : & = Example : &clothes me=Blue suit with a red tie. The Trekmuse currently does not have user-defined attributes, but we're planning on putting those in soon. @Lock is a special case of an attribute. With the exception of @Lock, any attribute could actually be filled with anything (words, numbers, symbols, etc), and the system wouldn't care (unless it's an Action Attribute, see section 5.1). So, you could "@desc me=aoiuant1290958lakwjtlqwe5", and no one would care, though it wouldn't make any sense. @Lock is different because you can only @lock yourself to something that exists (You couldn't @lock yourself to "aoiuant1290958lakwjtlqwe5" unless it actually existed as an object). 2.1 New Attributes There are several new attributes in the MUSE that are new from MUSH's and MUCK's. In addition to SUCC, FAIL, DROP, and KILL (to name a few), the MUSE has the following new attributes : EFAIL, LEAVE, and ENTER. The Trekmuse also has the following new attributes : BEAMOUT, OBEAMOUT, BEAMIN, OBEAMIN, TITLE. These three new attributes work exactly like the SUCC, OSUCC, and ASUCC attributes. The EFAIL message is shown to someone who fails to enter an object, the LEAVE is shown when someone leaves an object, and the ENTER is shown when someone succesfully enters an object. The Four BEAM* attributes are messages that you can set to be triggered whenever the object is teleported. The OBEAMOUT message is seen by the other people in the room that the object or player is @tel'ing out of, the BEAMOUT attribute is seen only the the player. OBEAMIN and BEAMIN are similar, only they are not seen until the player/object is @tel'd to the new room. -------------------------------- Example: EFAIL and OEFAIL -------------------------------- >> My assistant, Mocker... << >look me Mocker(#3506Pc) You see nothing special. Lock:Mocker&!Mocker Last:Mon Jul 23 21:23:03 1990 Carrying: glass of beer >@efail me=Hey, you pervert! Stay out! Set. >@oefail me=just tried to climb inside me! What a sicko! Set. >> Now, from my perspective...<< Mocker says "Hey Croaker, climb inside me and I'll carry you around!!" >enter Mocker Hey, you pervert! Stay out! >> From Mocker's... << "Hey Croaker, climb inside me and I'll carry you around!! You say "Hey Croaker, climb inside me and I'll carry you around!!" Croaker just tried to climb inside me! What a sicko! This occured because Mocker was LOCKED against Croaker, so could he could not enter. Setting the ENTER_OK flag (see section 2.2) will get around this. ----------------------- Example : BEAMOUT ----------------------- @beamout me=The scene dissolves in a spray of red sparks. @beamin me=A new scene forms in front of you... @obeamout me=disappears in a reddish spray of sparks. @obeamin me=transports into the room. >> Now to show what happens when @tel somewhere... << >> From my perspective... << >@tel home The scene dissolves in a spray of red sparks. A new scene forms in front of you... Croaker's Home(#1283RHAL) Croaker's home... wanna make something of it? Contents: Maria Table Bed Obvious Exits: Out >> From Maria's perspective... << Croaker transports into the room. Croaker has arrived. -------------------------------- There are several other player attributes of importance in the MUSE, namely LAST, SEX, RACE, CLASS and ORGANIZATION. LAST is visible to all, and indicates the time of your last session on the MUSE. SEX and RACE are player-settable attributes that (fairly obviously) help distinguish the player by race and sex. CLASS is a unique feature of MUSE's, and is comparable to the idea of "rank". Gone are the days when you can only be a player or a wizard. The CLASS attribute (settable only by high-ranking players) dictates what powers a player has over the objects around him. Higher ranking players may be able to examine objects from a distance, while low-ranking players may only examine what is in the same room as they. Gaining rank is not meant to be the goal of the MUSE, it is merely useful in stratifying the players in a MUSE where some sort of order is preferable. The last attribute, ORGANIZATION, is also wizard-settable only, and is the real distinguishing feature between races. ORGANIZATIONS are the heart and soul of the power system in the MUSE. Everyone in the MUSE will either be "attached" to a organization or "unattached". When attached, you are either part of the main ORGANIZATION or part of a SUBORGANIZATION of an upper ORGANIZATION. You have powers based on your rank over only those people in your ORGANIZATION or SUBORGANIZATION and those in any SUBORGANIZATION attached to your ORGANIZATION or SUBORGANIZATION. Players have no power over anyone above you in rank in your ORGANIZATION or in any ORGANIZATION above you, or over anyone "attached" to any organization outside of yours. (New) Players that are "unattached" to any organization are treated as a special case. It will probably be in your best interest to join a particular ORGANIZATION, based on its merits and leaders. The idea of ORGANIZATIONS will probably become clearer as you play. Unattached players will have a organization of "none". -------------------------------- Example: player Shiva -------------------------------- >look shiva The god of @destruction. Sex:male Organization:The Lawless Depths of Space Class:Yeoman Last:Fri Jul 20 18:07:53 1991 Carrying: Tan for Shiva Shiva's *SUNBURN* >>note the LAST, ORGANIZATION, CLASS, and SEX attributes << -------------------------------- 2.2 New Flags Several new flags have also been added, and old ones changed. Below is a brief list of them and their purposes. The commands that are effected by them will explain them in full. The letter that symbolizes the flag (which is usually displayed after the object's number when you look at it) appears after the flag's name in parenthesis. Note that many of these have been changed significantly within Trekmuse and may not apply to all MU*s! Abode (A) Allows a player to set their home in a room, but no longer allows them to teleport to it. Dark (D) If dark is set on an exit, the exit's name will not be displayed in the "obvious exits" list of the room. This can also be set on objects to keep them out of sight and on rooms to make all of its contents invisible. NOTE -- a room set DARK wil not report the arrival of players (Ie., with "* has arrived.") Players set DARK cannot be located with the @Whereis command. Enter_ok (e) Setting this flag on a player or object allows objects that don't belong to them to be given to them, and allows objects or players to enter them. A player can enter an object set ENTER_OK in the Trekmuse even if it is locked against them (so they can't pick it up). Going (G) This flag is set on a room that is about to be destroyed. It can be reset to save the room from destruction. (@set here=!GOING) Key (K) When set, this flag prevents puppets from picking up an object. Also, prevents non-players (all objects) from triggering an object set KEY. Jump_Ok (J) This flag, director-settable only, allows any player to teleport himself or any object he owns into the room marked Jump_Ok. Light (l) Objects and exits set LIGHT will be visible even in DARK rooms. No meaning for players or rooms. Visible (v) Objects set VISIBLE can be examined by any player as if that player owned the object. Link_Ok (L) Settable on rooms only, this flag allows others to link exits to (but not from) this room. Does not allow players to set their homes there (That's what the ABODE flag does) Quiet (q) Players set QUIET will not hear objects being triggered outside of the room they are in. Useful if you own a lot of objects and don't need to know everytime they are triggered. Hide (h) Players set HIDE will not appear on the WHO list. Wizards can still see HIDDEN players, and all can see how many hidden players are on at any time (shown on the WHO list as "There are X hidden players.") Haven (H) Rooms set with the HAVEN flag disallow player killing in them. Players set HAVEN cannot be paged. Objects set HAVEN will not work (a good way to halt run-away objects). Mortal (m) Players set with this flag will not be able to use the powers normally granted to them by their rank. For instance, Captains set MORTAL would be charged 250 credits for an announcement, etc. Sticky (S) Objects set STICKY will go home when dropped. Rooms set STICKY will delay the drop-to in the room until the last person has left. No_Tel (T) Anything set with this flag will be unable to @tel, be @tel'd, summoned, or in any way moved. Used for the effects of certain weapons, and things like the transporters. Also called PLAYER_CORPSE. There are, of course, more flags than this. Consult the HELP files within the MUSE for a complete list. 3 General MUSE commands Almost all the commands in TinyMUD remain in MUSE. However, MUSE has many improvements in commands over MUD, both in modifications of old commands and totally new commands. 3.1 Commands not supported rob The rob command is not in MUSE anymore. This is part of the "kinder and gentler" MUD campaign. Just ask an officer if you really need money. Directors and Admirals can "rob" by giving negative amounts of money. kill Kill has been removed for a short while. Don't ask why. I hope to see it back in sometime in the near future. (Not that anyone ever dies in the Trek universe anyways :) 3.2 Changes to old commands Several commands have been modified from the old MUD form. @dig Dig has been modified so a direction can be specified when digging a room. This means that a room can be dug, and exit opened and linked to the new room with one command. This extended syntax is: @dig = [;][,[;alias]] where direction is the direction (or directions) to open in the current room and attach to the new room. Note, a return exit is created if the comma is used. You may have as many aliases on an exit as you wish. -------------------------------- Example: Digging, opening, and linking -------------------------------- >look Croaker's Robot Lab(#3061R) The robot testing grounds. Obvious exits: rhombus west east north aus >@dig Test Room=test;t;testing,Out;o Test Room created with room number 5662. test;t;testing Opened. Trying to link test;t;testing... Linked. Out;o Opened. Trying to link Out;o... Linked. >look Croaker's Robot Lab(#3061R) The robot testing grounds. Obvious exits: test rhombus west east north aus >>Test now shows up in the list of exits. Aliases will not show up unless<< >>the exit is examined, for cleanlinesses sake.<< >test Test Room(#5662R) Obvious exits: Out -------------------------------- Related to the @dig command is a feature in MUSE which warns you of unlinked rooms. This prevents the problem of creating a room and then "losing" it (by way of forgetting the object number.) The database is checked every ten minutes for unlinked rooms (as well as rooms to be @destroyed) and will notify the owner of each unlinked room found with a message indicating the object number of the rogue room. It is possible that you could create a room and be almost ready to link to it when MUSE complains about you having an unlinked room. Don't worry, it just means that the database was checked for unlinked rooms between the time you created the room and the time you took to link to it. This message can be eliminated on the MUSE by setting the floating flag on the room. This feature and the FLOATING flag have been eliminated from the Trekmuse. -------------------------------- Example: Detached room warning -------------------------------- >@dig detached room >> several minutes later... << You own a disconnected room, detached room(#5595) -------------------------------- Examine: The examine command now will tell you who the owner of an object is if you do not own it. If you own an object, examine works as before. -------------------------------- Example: examine objects for owner. -------------------------------- >e superbear SuperBear is owned by BearMan >e bearman BearMan is owned by BearMan -------------------------------- Kill Two changes have been made in the kill command. First, it is possible to kill objects. Killing an object has exactly the same effect as killing a player: the object goes home, it gets half of what it cost you to kill it. Killing an object will stop all of its actions (see the @halt command.) Second, you cannot kill an object in a room controlled by its owner. This is so objects in puzzles and such cannot be killed. Also, you cannot kill a player in rooms they own. @link @link is used to link an exit or object to a room. Exits may be UNLINKED and then re-linked to a different room (as opposed to @destroying the exit and then @opening a new one). Unlinked exits can be stolen, so be careful! @Linking an object to a room sets the object's home there. You can also @link objects to objects (only if set link_ok, or you own them both). In this manner you can create an object and set its home to you, or link yourself to a room (if set ABODE) to set your home there. @linking a room to another room sets its DROP-TO, which means that any objects dropped in that room will go to the Drop-To room. If a room is also set STICKY, dropped objects will wait to go to their drop-tos until the last player has left the room. Using @link's opposite command, @unlink, you may Unlink any player or object linked to a room if you own the room, but not necessarily the object/player! When a room gets destroyed, any exits linked to that room are unlinked, and any linked from that room are destroyed, all automatically in the Trekmuse. If the destination room of an object is destroyed and the exit is not, that exit will sometimes be relinked to room #0 and be renamed 'Limbo'. If you see one of your exits like this, destroy it. @lock It is possible to lock objects/exits against attributes (see the section attributes and flags) such as the sex of the player. The command syntax is: @lock = : is a text string to match. Text matching uses the standard wildcards "*" and "?". For example, "s?x" will match "sex", "sax", "sox", or any other three letter word starting with s and ending with x. "*s" will match any word ending in s, and "*s*" will match any word with at least one s in it. The section on Listen and Ahear will deal with these extensively. -------------------------------- Example: locking an exit to attributes -------------------------------- >> Create a Ladies Room << >@dig Ladies room=Ladies Ladies room created with room number 5671. Opened. Trying to link... Linked. >@lock ladies=sex:f* Locked. >>females (or any sex beginning with f) only! << >@fail ladies=Hey you pervert! >> Try to go in << >ladies Hey you pervert! >> Try a quick sex change << >@sex me=female Set. >ladies Ladies room(#5671R) >> Now I can go in << -------------------------------- There are also some new LOCK commands within the Trekmuse. They are: "Is" Locks, "Carry" Locks, and Indirect Locks. INDIRECT LOCKS : These locks "follow" an object's locks. The syntax for it is : @lock =@ Setting an indirect lock on an item will lock that item to the same lock as the item it's set to lock. So, if you typed @lock door=@key, then the door would be locked to whatever the key is locked to, and that lock would change automatically as the lock on the key changes. This makes security passes/doors very easily possible. IS LOCKS : "Is" locks require that in order for an item to pass a lock, it must actually BE the item-- carrying the item won't let you through the door. The syntax is : @lock == Normally, if you lock a door to a Key, then the key and anyone carrying the key can get through the door. If set with an "Is" lock, though, only the key can get through. CARRY LOCKS : Are the opposite of "Is" locks-- in order to pass the lock on an object or door, you must be carrying the object it is carry locked to. Syntax is : @lock =+ If you carry locked a door to you, then only someone who's carrying you could get through, you could not get through on your own (seeing as you cannot "carry" yourself and go anywhere). Note that IS and CARRY locks are basically half of the normal lock (which allows you to be OR carry the item it's locked to). Say (and ":") MUSE treats some characters specially, for use in functions and parameter substitution. The percent sign and square brackets (%, [, and ]) are replaced by function or parameter values when printed out. This means that if you try and use the %, [, or ] characters you will get strange results. In order to say something containing any of these characters you should put a backslash character before them. -------------------------------- Example: using %,[, and ] with say -------------------------------- >"MUSE is 100% better than MUSH You say "MUSE is 100 better than MUSH" >"MUSE is 100\% better than MUSH You say "MUSE is 100% better than MUSH" >:This [thing] is in brackets Croaker This thing is in brackets" >:This \[thing\] is in brackets Croaker This [thing] is in brackets" -------------------------------- There are actually a number of ways to get these characters. The "%" will work in the place of the "\" character, so "%%", "%[" and "%]" will work. However, the setup of functions(which utilize the square brackets) has been radically changed, so this entire section may be irrelevant. There is also a different form of the pose command available on TinyTIM. The ";" command acts just like the regular pose ":", but it does not add a space between the user and the action sequence. This is useful for typing possessives, etc. >;'s voice squeaks! Croaker's voice squeaks! >;fallsdownquickly. Croakerfallsdownquickly. -------------------------------- @tel There have been a number of changes with teleport. First, you can now teleport yourself or any object you own to any room you own from anywhere (before, only a wizard could @tel players.) Also, you can teleport into any room that has the jump_ok flag set (see the section on flags and attributes for more.) You may also @tel to any room that is connected to the same ORGANIZATION as you or any SUBORGANIZATION of yours that is not locked against you. This allows for speedy travel from place to place in a MUSE, but creates certain problems for puzzle builders (see the appendix on building considerations.) The syntax of the command is: @tel = -------------------------------- >look Croaker's Robot Lab(#3061R) The robot testing grounds. Obvious exits: west east north aus >@tel me=#941 Drawing Room(#941R) This is a comfortable room, with windows looking out into the garden to the east, and out onto the front lawn to the north. To the south is a doorway that doesn't seem to lead anywhere. There is a sign reading "rec room" over it. There are numerous chairs and couches lying about, what seems to be a bar in the west wall (next to a door.) A grandfather clock ticks sedatly in one corner. Contents: The stereo system(#2276) Obvious exits: bar rec west -------------------------------- It is also possible to "push" a player out an exit using the @tel command, if you own the room and the exit. The syntax of this is: @tel = This, of course, is just the thing for those unwanted house guests... -------------------------------- Example: "pushing" things out exits -------------------------------- >look Croaker's Robot Lab(#3061RHA) The robot testing grounds. Contents: Cinema Obvious exits: Pit o' Death west east north aus >>Since this is my place, I can push Cinema (which I don't own) << >>out through an exit << >@tel cinema=pit o' death Cinema has left. >look Croaker's Robot Lab(#3061RHA) The robot testing grounds. Obvious exits: Pit o' Death west east north aus >> Let's go see where Cinema ended up... << >pit o' death The Town Rhombus You are in a pleasant town square, which is shaded by many old red oaks.Pebbled paths lead off in all directions, and the grass is healthy and well cared for. Set between the trees are various old statues, mostly made of marble. Contents: Cinema Onex exit magnet(#5636L) Obvious exits: Southwest Bulletin Southeast South West East North -------------------------------- 3.3 More Commands This section deals with some more commands of general interest. Those that are more suited to building machines will be detailed later. @clone: Clone will make an exact duplicate of an object you own and place it in the room where you are. This is handy, since it saves on having to laboriously copy an object's description and other attributes. Cloning an object costs the same as creating the object the old fashioned way (i.e. usually 10 credits) -------------------------------- Example: cloning objects -------------------------------- >@create generic object Created. >look Croaker's Robot Lab(#3061R) The robot testing grounds. Obvious exits: west east north aus >@clone generic object >look Croaker's Robot Lab(#3061R) The robot testing grounds. Contents: generic object(#5635) Obvious exits: west east north aus >> a copy of the object has appeared << >i You are carrying: generic object(#5622) TinyMUSE crash helmet(#1759) -------------------------------- You can @clone objects even if they are not in your possession or in the same room as you. In a sense, you can create a "platonic pattern" and then knock off as many copies as you want, while keeping the original in an out of the way place. This principle can be used in creating vending machines. Examples of vending machines will be given in the section on basic machines. -------------------------------- Example: cloning by number -------------------------------- >> The generic object is located in a room far away...<< >look Croaker's Robot Lab(#3061R) The robot testing grounds. Obvious exits: west east north aus >i You are carrying: TinyMUSE crash helmet(#1759) You have 1864113 Credits. >> Nothing up my sleeve... << >@clone #5622 look Croaker's Robot Lab(#3061R) The robot testing grounds. Contents: generic object(#5635) Obvious exits: west east north aus >> and there is a copy of it... << -------------------------------- @destroy: One of the first commands in MUSE. This command will allow a player to destroy an object that belongs to them or has the destroy_ok flag set. The player is refunded the cost of creating the object, and the object's number is released for future use (therefore you really can't tell the relative age of an object by it's object number.) All objects (rooms, exits, etc) can be destroyed, though players and robots take a special wizard-only command, @nuke. -------------------------------- Example: destroy an object -------------------------------- >@create generic object Created. >@destroy generic object You get your 10 credit deposit back for generic object. Destroyed. -------------------------------- -------------------------------- Example: set the destroy_ok flag -------------------------------- >@create generic object Created. >@set generic = destroy_ok Flag set. >look generic object generic object(#5635d) >>now it can be destroyed, unfortunately, no one else was around...<< >@nuke me Permission denied. >> whew! << -------------------------------- Destroying a room is a little different. Room removal takes a little while (up to ten minutes) do to the database design, as well as to allow for owners to destroy the rooms they are in. When a @destroy command is given for a room, the command sets the target room's going flag. The owner can reset this flag in order to save the room. Rooms to be destroyed must have two or less exits leading out of them. All exits leading out of a destroyed room are also destroyed. Exits leading into the room, however, must be eliminated by you, or they will be unlinked once the room is destroyed, and thus stealable. A room will not be allowed to be destroyed if there are 3 or more exits leading into it (so you have to go around and clean the exits, first). -------------------------------- Example: room destruction -------------------------------- >@destroy here The room shakes and begins to crumble. You will be rewarded shortly for Test Room. >out Croaker's Robot Lab(#3061R) The robot testing grounds. Obvious exits: test rhombus west east north aus >test Test Room(#5662RG) Obvious exits: out >out Croaker's Robot Lab(#3061R) The robot testing grounds. Obvious exits: test rhombus west east north aus >> time passes... << >look Croaker's Robot Lab(#3061R) The robot testing grounds. Obvious exits: rhombus west east north aus >>notice that test has disappeared<< -------------------------------- -------------------------------- Example: canceling destruction -------------------------------- >@dig test=test test created with room number 5772. Opened. Trying to link... Linked. >look Croaker's Robot Lab(#3061R) The robot testing grounds. Obvious exits: test rhombus west east north aus >test test(#5772R) >@destroy here The room shakes and begins to crumble. You will be rewarded shortly for test. >look test(#5772RG) >@set here=!going Your room has been spared from destruction. -------------------------------- Every once in a while there comes along a player who is too annoying to be allowed to stay. Often @boot is used (wiz-only). It merely disconnects the player (who may immediately re-connect). If they get pesky, the wizard may use @nuke. -------------------------------- Example: the Wizard's wrath -------------------------------- tinyjerk has arrived. tinyjerk stomps on Wizard's foot! >@boot tinyjerk tinyjerk has disconnected. >> a moment later... << tinyjerk has connected. tinyjerk spits in Wizard's hair. >@nuke tinyjerk tinyjerk is reduced to a pile of radioactive waste. tinyjerk has disconnected. >> all gone! This command is rarely used, though, so don't worry << -------------------------------- @edit: The edit command allows you modify an attribute without having to totally rewrite it. This aids in the creation of machines, which quite often have complex attributes which would be a major pain to re-enter. It also means that you fix spelling errors in @descs with ease (so now there's no excuse for misspelling!) The syntax is: @edit /=, If you wish to edit part of a string that contains a comma, surround each part of the edit component with {}'s. That is, to edit around commas, the syntax is : @edit /={},{} -------------------------------- Example: using @edit to modify an attribute -------------------------------- >>Let's make a minor change to my @desc << >look me Croaker(#346Pc) Pretty normal looking for a 5' 10" bipedal toad wearing a tweed jacket and a deerstalker cap. His pockets bulge with various tools: virtual reality inverters, ether clamps, foobar manipulators and an Xacto(tm) knife. He can usually be found alternatly staring off into the distance mumbling to himself and scribbling notes on a yellow pad. There is an "amphibious and proud!" button on one lapel of his jackett, aand a "warts are a myth!" button on the other. >@edit me/desc={jackett, aand},{jacket, and} set. >> So I don't have to do two separate @edit's, each around the comma << >look me Croaker(#346Pc) Pretty normal looking for a 5' 10" bipedal toad wearing a tweed jacket and a deerstalker cap. His pockets bulge with various tools: virtual reality inverters, aether clamps, foobar manipulators, and an Xacto(tm) knife. He can usually be found alternatly staring off into the distance mumbling to himself and scribbling notes on a yellow pad. There is an "amphibious and proud!" button on one lapel of his jacket, and a "warts are a myth!" button on the other. This makes @editing much, much easier... There are two special symbols in @edit, as well.... @edit / = ^, @edit / = $, If you use the carat (^), then the will be inserted at the FRONT of the attribute string, before whatever is there. No space is added between the new and the old, unless you add it. If you use the string ($), the is added to the END of the string, again with no space between the strings unless you add it, ie @edit / = $,< text> Of course you do not inlude the <>'s in the string. -------------------------------- @Alias @alias is a way to set, well, an alias on yourself so that people can page you, etc with an easier to spell, perhaps simpler name. In many cases, people's names in MU*'s are long and complex, and often can be a pain to spell out. Having to type the ! into Zarg! every time you want to page him can be a pain, so Zarg! could type "@alias me=zarg", and now people could page him with or without the !. You can also connect to your character at the beginning of your MU* session by typing your alias instead of your full character name. Note that Aliases are like player names -- they must be one-of-a-kind. No player's alias may match another's alias, and no alias may be the same as another player's character name. Also, as a general rule, keep your alias down to some logical psuedo-name, certainly not more complex than your character name but NEVER use a one- letter alias. If your character's name it "Joe", then perhaps you just don't need an alias! If your name was "Richelieu", however, having an alias of "Rich" makes a lot of sense. @Does / @Huhto These two registers' original purposes have been shrouded in myth, and are (in the Trekmuse, at least), only Dummy Registers (like the VA-VZ) registers for you to place information, perhaps to trigger or use in some programming. Note that the @Huhto register is director-settable only. Trekmuse therefore does NOT support the @use/@does commands. @Entrances This command can be typed alone or with parameters, your choice. Alone, this command will tell you all exits, rooms, and objects that are linked to the room you are in (if you own the room). An object is linked to a room if its home is set there. A room is linked to another room if its DROP-TO is set there. It also tells you any exit INTO the room, regardless if there is a returning exit out. This command is a great way to see if anyone has a back door into your room. You can also type @entrances or to get a list of all rooms/objects/exits that are linked to you or any object you own (if referenced by DB #, or name if it's in the same room). You cannot normally use this command in rooms or on objects that you do not own. Use of this command costs 100 Credits. 4 Puppets The use of puppets is the easiest of the advanced features to use in MUSE, and also one of the most amusing. Two simple capabilities constitute the puppet: the @force command, and the puppet flag. 4.1 The @force command and objects In TinyMUD, only a wizard could use force, and then it could only be used on other players. The @force command forces an object or player to perform a command exactly as if they had typed it in. You can make objects walk, talk, @create objects and even @force other objects you own. The usual syntax of the @force command is: @force = can be a name of an object you own, as long as you are in the same rooms as it is. Otherwise, you must use the object number to control it. Since it is used so often in MUSE, the @force command now has a shorthand syntax: The in this form has the same restriction as the above form of the command. -------------------------------- Example: forcing an object -------------------------------- >@create test puppet Created. >drop test Dropped. >look test test puppet(#4306) You see nothing special. >@force test=:jumps up and down and waves. test puppet jumps up and down and waves. >@force test=@create sub-puppet look puppet test puppet(#4306) You see nothing special. Carrying: sub-puppet(#4307) -------------------------------- You can have puppets move about, as well, as long as you remember that you have to reference them by object number after they have left the room you are it. -------------------------------- Example: making a puppet move -------------------------------- >@force test=north test puppet has left. >@force test=south I don't see that here. Sorry. You can only force players and things. >> This is MUSE's way of telling you it cannot find what you << >> want to force << >look Croaker's Robot Lab(#3061R) The robot testing grounds. Contents: Obvious exits: west east north aus >>remember, test is to the north of us<< >@force #4306=south >look Croaker's Robot Lab(#3061R) The robot testing grounds. Contents: test puppet(#4306) Obvious exits: west east north aus >> and test is back. << -------------------------------- Note that TinyMUSE does not announce the arrival of the test object. This is because the object cannot hear anything; that is, it cannot relay information or react to anything it hears. Only objects that can hear things (like private conversations) will be announced when they arrive. There are two classes of objects that can overhear conversations, and we'll tackle the simplest form of these next. 4.2 The Puppet Flag and Objects By setting the puppet flag on an object, the owner enables the object to relay all it hears back to him or her. What the puppet hears will be relayed to the owner, with a lead in to the line of text to differentiate it from the things the player might be hearing normally (or for that matter, might be hearing from another puppet.) The effects of puppets is rather surreal at times. It is not too uncommon to come across a room full of puppets talking to each other, their owners being elsewhere and doing other things while still joining in on the conversation. -------------------------------- Example: puppet output -------------------------------- >@create Croaker's test puppet Created. >@lock Croaker's=me Locked. >> always a good idea.<< >@set croaker's=puppet Croaker's test puppet grows ears and can now hear. >> you will always see this command when the puppet bit is set<< Flag set. >drop croaker's Croaker's test puppet> Dropped. >> There is the first output we see from the puppet<< Croaker's test puppet has arrived. Dropped. >look croaker's Croaker's test puppet(#5086p) You see nothing special. >>remember the puppet's number...<< >#5086 s >> send it to the town square<< Croaker's test puppet> You go to the town Rhombus. Croaker's test puppet goes south to the town Rhombus. Croaker's test puppet has left. Croaker's test puppet> The Town Rhombus Croaker's test puppet> You are in a pleasant town square, which is shaded by many old red oaks. Pebbled paths lead off in all directions, and the grass is healthy and well cared for. Set between the trees are various old >> truncated for brevity << Croaker's test puppet> Contents: Croaker's test puppet> Martha Croaker's test puppet> Gonzo Croaker's test puppet> Gus Croaker's test puppet> Desdi Croaker's test puppet> Tweeni Croaker's test puppet> White Rabbit Croaker's test puppet> Alice Croaker's test puppet> Onex Croaker's test puppet> Lucas Croaker's test puppet> Obvious exits: Croaker's test puppet> Southwest Bulletin Southeast South West East North >#5086 "Be nice, you're being recorded for the documentation... Croaker's test puppet> You say "Be nice, you're being recorded for the documentation..." Croaker's test puppet> Gonzo says "smile, youre on candid camera!" >#5086="candid puppet... Croaker's test puppet> Huh? (Type "help" for help.) >> you even get error messages relayed to you<< >#5086 "candid puppet Croaker's test puppet> You say "candid puppet" Croaker's test puppet> White Rabbit twitches his nose. Croaker's test puppet> Gonzo considers hacking /filedump into his tinytalk for benefit of all puppets present >#5086 n Croaker's test puppet> You walk toward government center Croaker's test puppet has arrived. Croaker's test puppet> Government center -------------------------------- MUSE also prevents objects from impersonating players... -------------------------------- Example: no impersonating allowed -------------------------------- >@create Wizard Created. >drop Wizard Dropped. >look Wizard Wizard(#5139) You see nothing special. >@force Wizard="The Wizard licks the nearest Klingon's ridges! You are under arrest for impersonating a player! >@force Wizard=:tap dances You are under arrest for impersonating a player! -------------------------------- Puppets will not relay any information to you about what they see if they are in the same room as you... you will see if someone whispers to one, though. Similarly, any @listen they may have set on them will not function if you are in the same room. This is not true for robots, which is why they are sometimes preferable. It should be important to note that if you are creating an object, the puppet flag is a great trouble-shooting device-- set your object PUPPET and trigger it... you may get an indication of where an error is occuring in your programming. Also, for full debugging, set an object both PUPPET and DARK and then it will relay EVERYTHING it does when it queues a command... much more useful for debugging than for simple use as a puppet. Of course a puppet set DARK is not invisible to the eye or an @sweep (See the next section). 4.3 Sort of New command: @sweep Since objects can now hear things, private conversation on MUSE becomes a little more difficult. Fortunately there is a command to help out. The @sweep command will tell you all of the possible objects which can overhear your conversation, such as players (whether logged in or not), puppets, and some machines (which, as usual, will be covered in another section.) After you sweep an area and find it empty (except for those in on the conversation) will can be sure you are secure. Even dark people and object will show up on it. Should any object enter the room that can hear, or if one of the objects in a room already is set up to hear, you will see a message tipping you off. Only objects that can hear (including players) are announced by MUSE as they enter a room, and if the owner of an object enables it to hear, you will get a message to the effect that the object has grown ears and can hear. -------------------------------- Example of the @sweep command -------------------------------- >look Government center The Government center, to the east is the Temple of Chaos, to the north is the temple, to the west is the Presidential Palace. This doesn't seem like your typical goverment center, infact you don't see any government here at all. Contents: SuperBear Katie NOTE TO AUSTRALIAN MUSEERS Sign pointing South west to the science museum Post office is south east Sign pointing North east to the Puzzle Paradise. Obvious exits: sw se ne west east north south >@sweep Croaker is listening. VAX9000 is listening. SuperBear is listening. Katie is listening. anonymous is listening. milo is listening. nessus2 is listening. Faradon is listening. radio_man is listening. Microwiz is listening. -------------------------------- Most of the listening objects in the above were players who were not logged in. Even so, you can see that the objects SuperBear and Katie (whatever they might be) are listening. 4.4 Puppets and Puzzles: The Key Flag Puppets have the potential of allowing cheating in puzzles. There is little excitement in having a puppet (or even a machine) go through a puzzle picking up all of the keys and solving the puzzle, or allow a player to cheat by being in two places at once (effectively) and ruining the solution. The key flag can prevent this. If an object has its key flag set, a puppet cannot pick it up, while real players still can. In addition, any object with the key flag set automatically goes home should the person carrying it @teleport away. This prevents people from stealing the keys and rendering the puzzle unsolvable. One more use of the KEY flag is new to Trekmuse : No object set KEY can be triggered by anything that is not owned by itself. IE. Only a player can trigger an object set KEY. This means that no puppet (much less normal object) can trigger a $command on an object set KEY. -------------------------------- Example: key flag -------------------------------- >@create object Created. >@va object=$HI:say Hi! <-- For more info on $commands, see section 9.1 Set. >@set object=key Flag set. >drop object Dropped. >@create puppet Created. >@set puppet=puppet puppet grows ears and can now hear. Flag set. >drop puppet puppet> Dropped. puppet has arrived. Dropped. >@force puppet=get object puppet> You can't pick that up. >@force puppet=hi puppet> Permission denied. >hi object says "Hi!" >get object Taken. -------------------------------- 4.5 New Commands -- @Attach and @Detach @attach This command may be used by anyone to @attach any willing player or object they own into their own organization or any suborganization attached to their organization. You may not @attach another player's object to any organization, nor may you @attach anything or anyone to any organization outside your own, nor may you @attach any player of higher rank. When you @attach something to your organization, its organization is set identical to yours. If someone is already organized, you must @detach them first. @detach This command may be used to @detach someone from your suborganization to the special "none" organization case. This must be done before anything can be re-@attached to any other organization. When an object is chowned, it is automatically @detached. You may not @detach another player's objects, any player above you in rank or organization, or any player outside of your organization. 5 Action Lists Action lists are what make machines in MUSE possible. Simply put, an action list is a string of commands stored in an attribute of an object which are executed after certain conditions are met. These commands run as if they were typed in by the object. Action lists are the "programs" that objects in MUSE run. Each attribute can be considered as, say, a line of a BASIC program. Each attribute can accomplish many things, including triggering itself again, or even rewriting itself or another attribute. Each action list has to be triggered in some way. The most common action lists are associated with attributes that you are familiar with from MUD. These are ASUCC, AFAIL, ADROP, and AKILL. 5.1 Common action lists: ASUCC, AFAIL, ADROP, and AKILL In MUD, when an object is successfully "used" (that is, picked up) two things happen. The message stored in the SUCC attribute is sent to the player who picked the object up, and the message stored in OSUCC is displayed to all other players in the room. In MUSE, a third thing occurs, the commands stored in the ASUCC attribute (if there are any) are executed. As you can probably guess, the commands in AFAIL will be run when someone fails to use an object (tries to pick it up but can't), AKILL will be run if an object is killed, and ADROP will be run if an object is dropped. The actual structure of an action list is simply a string of commands as you would enter them to perform the desired operation. The commands are separated by a semicolon, ";", and for the most part are executed in the order they were entered (i.e. left to right.) Therefore, an attribute is "programmed" thus: @ = command1;command2;command3... There is no need for an "end" statement, execution of the action list stops when the end of the list is reached. Command1 will be executed, and then command2 and so forth. You can clear an attribute by setting it to nothing. -------------------------------- Example: Adrop -------------------------------- >@create superball Created. >@drop superball=You bounce the superball on the floor. Set. >@adrop superball=n;s;n;s;n;s;:stops bouncing and lands at your feet. Set. >>when dropped, the superball will north and then south several times << >>print out the message that it has stopped, and then terminate << >>execution << >drop superball You bounce the superball on the floor. superball goes to the north end of the lab. superball has left. superball goes to the north end of the lab. superball has left. superball goes to the north end of the lab. superball has left. superball stops bouncing and lands at your feet. >>remember, we don't see the superball come back since it << >>cannot hear << -------------------------------- -------------------------------- Example: Afail -------------------------------- >>have the ball print out a message and then go north<< >@afail superball=:rolls away from %N;n Set. >>make sure I'll fail when I try to pick it up << >@lock superball=me&!me Locked. >look Croaker's Robot Lab(#3061R) The robot testing grounds. Contents: superball(#5088) simple ahear machine(#4284) Obvious exits: west east north aus >get superball You can't pick that up. superball rolls away from Croaker superball goes to the north end of the lab. superball has left. -------------------------------- -------------------------------- Example: Asucc -------------------------------- >> Set the ball so I can get it again << >@unlock superball Unlocked. >> have the ball page me when it is taken (a good << >> burglar alarm)<< >@asucc superball=page croaker=someone picked me up! Set. >get superball Taken. You sense that superball is looking for you in Croaker someone picked me up! -------------------------------- -------------------------------- Example: Akill -------------------------------- >>Back in section #2, I tried to enter Mocker. He's back for revenge<< >>From Mocker's perspective << >> Mocker goes back to the robot lab and... << >>sets his akill to send him back to the robot lab from his << >>home to kill me back<< >@akill me=s;robot lab;kill croaker=100 Set. "Go ahead, make my day! You say "Go ahead, make my day!" >> My perspective, again... << Mocker says "Go ahead, make my day!" kill mocker=100 Ow! Hey! What did I ever do to you? Mocker has left. Mocker has arrived. >> Mocker's akill takes over and brings him back almost immediately<< >> Mocker's perspective, again... << Croaker has killed me! That Jerk! Croaker killed you! Your insurance policy pays 50 credits. Mocker's room(#3505R) Obvious exits: s >>Now Mocker's akill acts as autopilot and moves him to the << >>robot lab<< Croaker's Workshop This room is entirely white, with a black grid on the walls, ceileing,and floor. It gives you the impression of being in a a room made out of graph paper. The only furniture is a few work benches crowded with various dimensional stabilizers, reality wrenches, foobar manipulators. There are several doors leading in random directions, some of them seem to be leaning against a wall. Obvious exits: Robot Lab North port3 port2 port1 east Croaker's Robot Lab The robot testing grounds. Contents: Croaker Obvious exits: west east north aus You found a credit! Sorry. >> Revenge is not his... << -------------------------------- You'll notice that Mocker could not kill me in a room that I control. Had it been someone other player's room, he could have gone through with his murder plot. AKILL only takes effect after you are sent home, so you have to go back to where you were if you want an eye for an eye. 5.2 Command Grouping: using the {} Suppose you want to have an object reprogram itself, and then continue with some operation. The problem you run in to is how to differentiate between the commands you want to store in another attribute and the commands you want this attribute to execute. For example: @adrop ball="now you can't get me!; @afail me=:rolls away; north; @lock me=me&!me The problem is that the ADROP should store the north, not execute it (as it will in its present form.) To solve this problem, MUSE allows you to defer the execution of some statements by enclosing them in braces (almost universally known as "squiggly brackets.") All commands in the braces are skipped, and if an attribute is set to the contents of a pair of braces the braces will be removed and the commands in them will be stored in the attribute. Our above example would become: @adrop ball="now you can't get me!;@afail me={:rolls away;north};@lock me=me&!me After dropping it, the ball's AFAIL will be set to the contents of the braces. -------------------------------- Example: deferring commands -------------------------------- >@create test object Created. >> have the object rewrite its ADROP after being dropped << >@adrop test object=@adrop me={:goes boom!;@destroy me};"If you drop me again, I'll explode! Set. >drop test object Dropped. test object says "If you drop me again, I'll explode!" >look test object test object(#5666) You see nothing special. Adrop::goes boom!;@destroy me >get test object Taken. >drop test object Dropped. test object goes boom! You get your 10 credit deposit back for test object. -------------------------------- 5.3 Cost of Running a machine Like most things in the real world, machines in MUSE cost money to run. It costs 1/64 of a credit for each command a robot executes in addition to any costs those commands normally has (i.e. kill or @create.) The reason for this cost is an attempt to keep machines from slowing the system down with unnecessary commands. A machine that sits in a room and says "zootlewurtle" to itself will slowly use up your supply of money, and a machine that repeatedly creates or clones objects will burn up your money faster, and a machine that kills itself repeatedly will drain your credit supply in no time. You should therefore be careful of leaving a runaway machine. Machines that sit around and wait for certain things to happen (like being dropped) will not use any credits while sitting idle, and are thus economical. 6 Other triggers and attributes: LISTEN COST and CHARGES This section will discuss two new triggers and the attributes they affect. LISTEN will allow machines to react to what they hear, and COST will allow them to react to being given a certain amount of credits. Also introduced is a way to limit the number of times an object can be used by using the CHARGES attribute. 6.1 LISTEN and AHEAR By far one of the most flexible set of attributes for creating machines is the LISTEN and AHEAR pair. These attributes allow the machine to respond to things they hear, such as what players or other machines say or do. This allows a machine to respond to a spoken command, or wait for a message like "blank has arrived." The LISTEN attribute is set to a string that the machine is to respond to. Almost always this string includes wildcard characters to allow the machine to be triggered by a single key word or phrase in a lengthy string. Wildcards should be familiar to anyone using DOS or Unix systems. The wildcard "*" matches any number of characters in a string. The string "s*" will match any string beginning with the letter s. The string "*hello*" matches any string where the word "hello" appears, like "croaker says 'hello there!'." The wildcard "?" will match a single character. The string "*s?t*" matches the string "sit", "he sat", or "his time" (a single space matching as the "?" in this case.) Note that this is very different from "*s*t*" which will match a string like "some time." LISTEN is set as any other attribute, namely: @listen = such as: @listen foo = *kill * Which will match any occurrence of the word "kill" which is followed by a space (i.e., it would not match the string "shiva killed foo.") When the string in the LISTEN attribute matches a string the object hears, the action list in the AHEAR attribute is run similar to the way ASUCC is run if an object is picked up. For example: @ahear foo = "now now, let's not have any violence" would have the machine foo respond to a string like "let's kill the wizard!" with a calming message. -------------------------------- Example: Using LISTEN and AHEAR -------------------------------- >>Create a simple machine to run west then east upon << >>hearing the phrase "trigger phrase" << >@create simple ahear machine Created. >@listen simple = *phrase* Set. >@ahear simple=west;east Set. >look simple simple ahear machine(#4284) You see nothing special. Listen:*phrase* Ahear:west;east >"trigger phrase! You say "trigger phrase!" simple ahear machine runs like the wind into New Main Street to the west. simple ahear machine has left. simple ahear machine has arrived. >>now a simple hear-respond machine...<< >@ahear simple=say I heard the word! Set. >look simple simple ahear machine(#4284) You see nothing special. Ahear:say I heard the word! Listen:*word* >"Now I say the word... You say "Now I say the word..." simple ahear machine says "I heard the word!" -------------------------------- You'll notice that in the last part of that example that the machine did not go into an infinite feedback loop event though its output contains the phrase to trigger it. This is because the AHEAR action list is only run if a string that was not generated by the machine itself matches the string in the LISTEN attribute. Usually, this is what you want, since otherwise it is very easy to get into a feedback loop where the machine constantly re-triggers itself. There are two more attributes related to LISTEN: AMHEAR and AAHEAR for those occasions that you want a machine to be able to trigger itself by saying something. AMHEAR will only respond to strings generated by the machine (i.e. the exact opposite of ahear.) AAHEAR will react to all strings, whether generated by itself of something else. These attributes can be used to do things like have the AKILL or ADROP trigger further actions by whispering to itself. There are better ways to do this, however (see the section on extra attributes and the trigger command.) -------------------------------- Example: AMHEAR and AAHEAR -------------------------------- >>reset the ahear so it won't interfere<< >@ahear simple= Set. >@amhear simple=say I heard the word! Set. >"word You say "word" >>nothing happens, since the object didn't generate << >>it itself, but of we force it to say "word"...<< >@force #4284="word simple ahear machine says "word" simple ahear machine says "I heard the word!" simple ahear machine says "I heard the word!" . . . >>and we get into an infinite feedback loop<< >>the only thing to do is to kill, @halt, or << >>@destroy the object << . . . simple ahear machine says "I heard the word!" simple ahear machine says "I heard the word!" simple ahear machine says "I heard the word!" simple ahear machine says "I heard the word!" >@halt >>now reset AMHEAR and do the same thing for AAHEAR<< >@amhear simple = Set. >@aahear simple = say I heard the word! Set. >"word You say "word" simple ahear machine says "I heard the word!" simple ahear machine says "I heard the word!" simple ahear machine says "I heard the word!" simple ahear machine says "I heard the word!" simple ahear machine says "I heard the word!" simple ahear machine says "I heard the word!" >kill simple = 100 simple ahear machine says "I heard the word!" You killed simple ahear machine! >>Notice both I and it could trigger it off...<< -------------------------------- 6.2 Runaway objects and the @halt command At this point, it would be a very Good Thing(tm) to explain how to stop one of the aforementioned runaway machines. As can be seen above, one can either kill a runaway, or use the @halt command on it. There are drawbacks to both methods, however. Killing an object will stop what it's currently doing, but will trigger its AKILL attribute. Normally this is fine, but if the AKILL was what sent it into an infinite loop in the first place, killing it will be of no avail. The @halt command, which is simply given without any parameters, will halt all of the objects you own. This means that not only will the malfunctioning machine be stopped, but all of the machines you may have doing their thing will also stop their operations. It does not affect any machines "waiting around" with LISTEN attributes and such, however, just those that are actually doing something at the moment. To digress for a moment, it may be helpful to explain what happens when an object triggers itself. Suppose half way through its AKILL action list an object whispers a phrase to itself which triggers its AMHEAR action list. The AMHEAR action list is not run immediately, but is placed into a queue of action lists to be run later. Only after the AKILL has finished will the AMHEAR action list be allowed to run (assuming that there was no other action lists queued before the AMHEAR.) Either killing or @halting an object will remove all the action lists i n the object's queue and terminate the currently running action list. Killing the object stops just that object (but, of course, will trigger its AKILL, if any), while @halt will stop all the objects you own. Note that there are several other ways to stop out of control objects. You can @destroy them, or you can run out of money. -------------------------------- Example: runaway object -------------------------------- >> Note: don't be an idiot. Never do this on purpose...<< >@create loop killer Created. >@akill loop killer="another iteration!;kill me=100 Set. >drop loop killer Dropped. >@link loop killer=here Home set. >kill loop killer=100 Halted. You killed loop killer! loop killer says "another iteration!" Halted. loop killer killed loop killer! loop killer says "another iteration!" Halted. loop killer killed loop killer! loop killer says "another iteration!" Halted. loop killer killed loop killer! loop killer says "another iteration!" Halted. loop killer killed loop killer! loop killer says "another iteration!" Halted. loop killer killed loop killer! loop killer says "another iteration!" Halted. loop killer killed loop killer! loop killer says "another iteration!" Halted. loop killer killed loop killer! >@halt loop killer says "another iteration!" Halted. -------------------------------- Note that "Halted." is printed out every time loop kills itself. This is because it is being halted by killing itself. However, the AKILL action list gets run after the object is killed and is thus restarted. The @halt command or waiting for me to go broke were the only two alternatives since killing the thing would only set it off again. I would have eventually run out of money, since I lost 50 credits every time it killed itself (killing itself cost 100, and it got 50 back.) Overall, running that object cost me about 500 credits. 6.3 Wildcards and Variables When a string is matched by the string in the LISTEN attribute, the characters matched by the wildcards are not simply discarded. The sub- strings matched by the wildcards are placed in nine variables, numbered 0 to 9, and can be retrieved by using the function v(). Functions will be discussed later, but for now it is enough to know that putting [v(0)] in a string places the substring matched by the first wildcard in the LISTEN attribute into the action list. The substring matched by the second wildcard can be had by putting a [v(1)] in the AHEAR, and so forth up to [v(9)]. The normal variables in MUD such as %N, which holds the name of the object responsible for triggering the action, can be had in this manner as well, by placing [v(n)] in the string. In fact, [v(n)] is set up for every trigger, not just LISTEN, and so could be used in an ASUCC, OSUCC, SUCC, or similar attribute. Do NOT use [%n] -- this is not defined. So, the legal substitutions for are : %n, v(n), [v(n)]. A little experimentation will reveal the differences. Mainly, %N is always substituted by the system IMMEDIATELY when the register is read. V(N) is not replaced by the system until it is read. The difference between [v(n)] and v(n) is that the one with the []'s is a function, the other is not. So you can use v(n) inside a get() function, but not [v(n)]. When used in an attribute, the variables 0-9 and N will be replaced with the text they store. This allows the machine to respond to what, specifically, was said or done to set it off, and to know who was responsible for triggering it. The section on functions will give a clearer explanation as to what exactly v() and the [] mean, and how to use them precisely. -------------------------------- Example: Using variables -------------------------------- >look simple simple ahear machine(#4284) You see nothing special. Aahear:say I heard the word! Listen:*word* >@aahear simple= Set. >@ahear simple=say After word, I heard: %1 Set. >"Now after word it will print this You say "Now after word it will print this" simple ahear machine says "After word, I heard: it will print this"" ------------------------------------- Notice in the last example there was an extra quote. The quote was included since it was part of the string that was matched by the wildcard. Many times you want to eliminate this trailing quote. The next example demonstrates how to do this. -------------------------------- Example: eliminating the trailing quote -------------------------------- >@ahear simple="I heard: %1 Set. >@listen simple=*this*" Set. >"notice that after this there is no extra quote You say "notice that after this there is no extra quote" simple ahear machine says "I heard: there is no extra quote" >>and the extra quote is gone << -------------------------------- The wildcard ability is very powerful. You can specify a input format and have the LISTEN attribute parse a line that matches. For example, you could have the machine accept three parameters which are separated by, say, commas or colons. -------------------------------- Example: using LISTEN to parse a string -------------------------------- >@listen simple=*hear*,*,* Set. >@ahear simple=say var0 = %0; say var1 = %1; say var2 = %2; say var3 = %3 Set. >"It will hear this, that, and the other thing. You say "It will hear this, that, and the other thing." simple ahear machine says "var0 = Croaker says "It will" simple ahear machine says "var1 = this" simple ahear machine says "var2 = that" simple ahear machine says "var3 = and the other thing."" -------------------------------- Here's an application of the AHEAR and LISTEN attributes. I was curious to see how many people (if any) had ventured through my Drawing Room (which is directly off the Room of Junk and Killing.) The object in this example does this. It takes a "photo" of the person who walks through the room. Before making the photo, any old photo of them is destroyed so that the camera won't have duplicate copies of each person. As you can see, it works, and a few people have actually stumbled into my place. -------------------------------- Example Object: surveillance camera -------------------------------- >look a survalence A survalence camera(#863) This is just an ordinary camera, but it looks a little out of place here. Feel someone's watching you? Ahear:@destroy picture of %0;@create picture of %0 Listen:*has arrived* Carrying: picture of Croaker(#4487) picture of Butler(#7495) picture of Sugar(#6090) picture of Number_Ten_Ox(#5279) picture of Khamul(#4782) picture of spooz(#5702) picture of Mocker(#4757) picture of(#4485) -------------------------------- ************************ *** THIS SORT OF CAMERA, WHILE FUNCTIONAL, IS _NOT_ ENCOURAGED *** *** WITHIN THE TREKMUSE. *** The reason for this is that many, many people like to make cameras like this, and so many, many objects are wasted on pictures that do nothing. There are other ways to make cameras that use no objects... See section 10.3 for the way to program one properly. -------------------------------- 6.4 COST and APAY The COST and APAY attributes work exactly like LISTEN and AHEAR, except that COST is a number of credits an object has to be given before it will trigger APAY. This allows vending machines that can charge for the cost of the objects they make (or even be able to make a profit if you set the COST higher than the number of credits needed to run the machine.) The COST attribute has to be set to the number of credits that the object needs to be given for it to trigger APAY. APAY contains the action list that will be run when the machine is given the amount of credits specified in COST. Attempting to give the machine less than the COST amount will garner the player a snide little error message (and no credits will be given to the object.) Any excess over the COST amount will be returned to the player as change. This is automatic, so you don't have to worry about programming your machine to handle these situations. COST also has two other attributes associated with it: PAY and OPAY. These work like SUCC and OSUCC, the player giving credits will see the message stored in the PAY attribute, and everyone else will see the message in the OPAY attribute. This allows for more flexibility in creating success messages. Note that the commands @clone, give, and the chown_ok and destroy_ok flags are very useful in creating vending machines. -------------------------------- Example: COST and APAY -------------------------------- >@create stuff vendor Created. >@cost stuff=10 Set. >@pay stuff=Thank you for buying some stuff. Set. >@apay stuff =@create stuff;@set stuff = destroy_ok; @adrop stuff = {:implodes!;@destroy me};give %N=stuff Set. >drop stuff vendor Dropped. >give stuff vendor=10 You get 0 in change. Thank you for buying some stuff. >stuff vendor gave you stuff. look stuff stuff(#5142d) You see nothing special. Adrop::implodes!;@destroy me >drop stuff Dropped. stuff implodes! You get your 10 credit deposit back for stuff. >give stuff vendor=5 Feeling poor today? >give stuff vendor=15 You get 5 in change. Thank you for buying some stuff. stuff vendor gave you stuff. -------------------------------- 6.5 Restricting the number of uses: CHARGES The CHARGES and RUNOUT attribute pair allow for an item to be used for a certain number of times and then perform some action, like going home or @destroying itself. This can be used to create magic wands that turn to dust and other such limited use items. The CHARGES attribute is set to the number of times an object can be successfully used. A "use" in this case involves triggering any of the AHEAR, ADROP, ASUCC, etc. attributes. Each time the object is used, the CHARGES attribute is reduced by one. If the object is used when the CHARGES attribute equals zero, the action list in the RUNOUT attribute is run. The RUNOUT attribute can do anything, like @destroy the object, force it to go home, whatever. Remember, though, that if the object is to be used again it is going to have to have its CHARGES attribute reset. NOTE THAT ONLY @TRIGGERS WILL COST THE CHARGES ATTRIBUTE TO DECREASE! -------------------------------- Example: CHARGES and RUNOUT -------------------------------- >@create foo Created. >@charges foo=3 Set. >@runout foo="Bye now!;@destroy me Set. >@asucc foo="I'll run out soon! Set. >drop foo Dropped. >get foo Taken. foo says "I'll run out soon!" >drop foo Dropped. >get foo Taken. foo says "I'll run out soon!" >drop foo Dropped. >get foo Taken. foo says "I'll run out soon!" >drop foo Dropped. >get foo Taken. foo says "Bye now!" Halted. You get your 10 credit deposit back for foo. -------------------------------- 7 Commands and Functions for Machines The commands and functions in this section are generally only helpful when used in machines. These commands allow the machines to wait a period of time before performing actions, a decision making command, and functions to get the date and generate random numbers. 7.1 Delaying Commands with the @wait command The @wait command can be used to specify a period of time to wait before executing a command. This allows a machine to break up it's execution over a period of time, instead of operating as fast as possible. A machine that wanders from room to room at full tilt is much more annoying and is a greater drain on the system (not to mention your bank account) than one that moves once every few minutes. The syntax if the @wait command is: @wait