AberMUD5(6) AberMUD5(6) AberMUD 5 System Manual 1. Introduction 2. AberMUD: Myth and History 3. Features Of The System 4. Installation And Operation 5. Overview Of Game Driver 6. Basic Creation 7. The Room 8. The Object 9. The Player 10. Other Classes 11. Superclassing 12. Structure Of The Interpreter 13. Interpreter Facilities 14. Graphics & Client Support Appendicies A. Interpreter Reference B. Command Reference C. Conclusion Introduction The AberMUD5 system has evolved over the last 4 and a half years from an experiment into editing in game to a full game writing system. Its origins lie in two places. Firstly because I was unhappy with the old AberMUD3 driver, the design of which was fundamentally flawed in that it was constrained to a design initially thought out to get around the limits of GCOS3/TSS on a Honeywell main- frame. AberMUD5 is a single server process rather than a set of co-operating user processes. Leon Thrane had spent a lot of time developing the basics of a multi user game system initially on the Amiga (CIA) and then under Unix (LANCE). In many ways it was the ongo- ing MUD project and it should have been the game the Aber- MUD team produced. It got sidetracked because although crude and nasty AberMUD was there and worked, while LANCE like many carefully planned and designed projects was still being built. In essence it went the way many 'real' research projects go. AberMUD steals its core concepts from LANCE. The idea of subtyping things like rooms is a LANCE concept, as are many of the properties such as soft and hard containers. The main things I left behind were the rules that LANCE enforced - that an object could not be inside itself, that it could not be both a room and an object at the same time and similar structural constraints. AberMUD5 started out on an Amiga, initially as a set of IPC routines and a basic core allowing creation and edit- ing of objects, rooms and players. Once that core was solid the game driver language was added. The driver lan- guage takes ideas from various sources. It uses a simple table driven approach for its basic structure, as this simplifies both parsing and interpretation of the game language. For speed and compactness the driver compiles the game language into a P code. Unlike Lp-MUD (which at this point I had never seen since I was away from the net for a year and a half) the P code can be decompiled back to the original source, so that the source need never be stored. The first port of AberMUD5 was to SCO Xenix as part of a possible commercial sale that never occured. It took only one evening for Ronald Khoo, Eric(*) & me to get it work- ing under Xenix although most of this had to do with Ronald's remarkable skill. When I finally returned to university after a years absence I had three sets of AberMUD sources. The first of these was a fortunate backup taken before I spent a year working commercially for Horrosoft, the second the version including code I had written at Horrorsoft, and the third a commercial and somewhat different variant with a graphi- cal interface that was used for the Elvira game. I was able to produce a limited distribution set of the second version, and also used it to start AberMUD5 running on the university computer society system. The game gained a large number of features at this point, as well as becom- ing much more efficient. With 8 people on a 68010 CPU and 1Mb process spaces you learn what efficient means... Until recently this version was the one distributed and was subject to a fairly annoying set of signed paper license rules. As of version 5.20 however the base set predates my work at Horrorsoft and all the other code was rewritten from a set of specifications of the 5.16 release. This has finally enabled me to release a much freer version of the game driver. The current AberMUD5 (5.21.3) is now based totally on TCP/IP and the older support for named pipe communications and Amiga message queues has been dropped. It runs as a single process which for the AberMUD5 database, a fairly complex 600+ room game, is about 1.3Mb in size with every- thing except the user file loaded into memory. (*) Eric is Ronald's teddy bear Addition by Alex Greenbank. After using the system for 6 months and developing a mud on AberMUD5 (5.21.4), I decided that the system was in need of some improvements and since I thought I could I started to prepare the new release. From my own experience and hearing from other people who used the server I found the current documentation to be lacking in several areas. With the new release I have included a new manual which is the original one edited considerably. New sections have been added, and ones written that were not before. How someone can put something in the contents page and not actually write it is beyond me *:-) A new release (5.21.6) should fix most of the bugs that were included in the original but will probably have some of its own. Any problems should be reffered to alex@cheese.org, I should be able to help you on almost all of your problems. If you have any problems installing, compiling or running the server please contact me at alex@cheese.org for help. I should be able to help with almost all problems. AberMUD: Mythology and History There seem to be no end of strange claims occasionally appearing in rec.games.mud about AberMUD, that in general are far from accurate. Lets start at the beginning o AberMUD is not the first MUD or anything of the sort. I spent a lot of time playing a game called 'Multi User Dungeon' or 'MUD'. It was written in 1979-1981 by Roy Trubshaw and Richard Bartle, and different versions of it contained many of the ideas that a lot of people think were first invented by things like TinyMUD. It was also a game with no mindless vio- lence. Every death was carefully plotted, every vic- tim selected and kill planned. In fact being beaten to death was one of the easier things in MUD. It was no game for wimps either. Dying cost you all your points, and a typical player took a year to a year and half to learn the game well enough to make wiz- ard. o AberMUD wasn't even that original. The game system is heavily influenced by the style of MUD. The initial database for AberMUD1 was a strange and bizarre beast being a mishmash of in-jokes and odd scenes. It actu- ally worked suprisingly well, and many a person died at the hands of a maniac wielding such items as a .44 beetroot. More of the history later o Despite what many people seem to think AberMUD is named after the town where it was written. Most peo- ple know that much but they don't seem to know that a) It is spelt 'Aberystwyth' (which is Welsh for the mouth of the river Ystwyth). b) It is pronouced Aber (with a hard 'A' - like in axe) and doesn't sound like aayber. o What made AberMUD a success wasn't any kind of bril- liance, it was the fact that the games at the time were all written in bizzare languages: MUD in a mix of BCPL and DEC10 assembler, and VaxMUD in VMS for- tran. MUD was certainly a much better system and game at the time. Mostly it was luck that a guy called Vijay from the US asked for a copy, so we gave him one. Since then the world has not looked back. o Although these days it is written in Swansea (though still run in Aberystwyth too), its still AberMUD because in Welsh Swansea is Abertawe (the mouth of the river Tawe). In English its derived from Svenns Ei (Ei being Island), after a viking pirate who used it as a base - so there. A full history of AberMUD and its goings on almost requires a book to describe Aberystwyth, its computing people and indeed a cast who would be regarded as too unbelivable in a fictional account. I think it's worth introducing a few main players of the cast as I try and outline the history of AberMUD. The man upon whom we normally blame the entire thing is Robert Ash, the computer centre systems manager who ,when we asked how we would go about writing a multiuser game on the Honeywell, replied that it couldn't be done. To be fair he always maintains that he meant it couldn't be done in the spare time we had, and I guess he was right since I failed the physics accessory course at Aberystwyth. Any- way, as anyone who has ever kept a pet 'real programmer' will tell you, the last thing you tell a real programmer is that "it can't be done". So we did it. Throughout the history of AberMUD at Aberystwyth Rob was a great help. There are very few system managers who not only didn't mind games on their system so long as it didn't stop real work, but who were actually prepared to sit down with someone and explain the innards of turning screen paging off with a DRL (system call) for a game. Having been told it wasn't possible the next cast member - Leon Thrane (pronounce that with a 'th' sound and he'll sulk)- got busy. Leon had an Amiga 1000 and thus the capa- bility to develop on a sensible machine of his own. He also knew C, while the rest of could muster Z80, 6502, a little 68000, 8085 and BASIC between us, and from our pre- vious escapade of writing a bulletin board had learned B (the predecessor to C) by examples. Leon got a few simple basics working, and we even had about ten rooms before CIA kind of petered out. We ran into too many problems - lack of access to Leon's machine , which, since the alternative was an ACT Sirius running DOS1.? and Lattice C version 1.12, was a major problem. Later on we also lost most access to Leon when he acquired a girlfriend. Leon had also however figured out the basics of socket programming on the computer science vax machine. As this was vanilla 4.2BSD it also involved crashing the vax a few times in the process. We had already written a chat system for the Honeywell using shared files - the only IPC for GCOS3/TSS was in batch not timesharing! and I got bored. After an hour or two I had the ability to walk between channels of the chat system (which already had descriptions for channels). By 6am that morning AberMUD was born. It took a few weeks before it grew into anything serious but rapidly caught on. Within a couple of months it was out of control and had to be split from the bulletin board/chat system because it was too large. This unfortunately messed up a lot of Leon's future work, because it diverted all the other work away from LANCE, his very carefully designed system, which had it been fin- ished would have been one amazing game. As AberMUD progressed and grew two people contributed a lot of bits too it. Jim Finnis (White the 159IQ MegaCre- ator) contributed a large collection of very very silly areas - Charlie & The Chocolate Factory, Milton Keynes, and above all a pair of extremely unpleasant mazes. He also added some pieces to the code, and invented the emote command. Jim is still around occasionally and before he complains I probably ought to point out that the 159IQ Megacreator was our title and part of a joke, rather than his, and that he in fact is a small hairy and fairly quiet person who can be bribed with good whiskey. Don't believe anything he says about me - it might be true. After the first six rooms - including the infamous Aber- MUD1 warning notice 'Anyone going west from here will explode' (well everyone has to try it once don't they) - I asked a very loud 1st year by the name of Richard Acott aka 'the Moog' to design some rooms. He added Doiley Woods of all things, and after I added combat to the system everyone was busy chopping Evil Edna up. The Moog added several other areas to AberMUD1, although almost nothing of his survived into AberMUD2. He is also still very occa- sionally around, although sadly he has passed on into the real world, and is but a shadow of the Aberystwyth folk- lore he created. Several things in the older AberMUD's (that alas were removed by the Americans) come from his exploits - the infamous non-stick glass, and the saga of Veryodd's (ex) door spring to mind. Eventually all our creation got too much for the poor Hon- eywell and AberMUD could no longer be linked (it gave up and the system informed us that the memory limit had been EXCEDEED (yes thats how it was spelt - I guess the design- ers hadn't tested it). Size on the Honeywell was a big problem. You only had 64K of 36bit words per process, and only 256K words in memory at most per copy of timesharing. Timesharing was a very priviliged batch job, and you had to run several of them on the machine because the address space was 18bit. A few special priviledged intersegment operations existed to get around the 256K word limit, but a job could only access one segment. The problem was even worse than this because the Honeywell architecture only had base-limit pairs and no page mapping such as even the PDP11 had. This meant that programs had to be entirely in memory and had to be contiguous. With a few copies of AberMUD running the game response time rapidly fell to about 30 seconds a move because of the amount of swapping involved, and the way the Honeywell penalized awkward large jobs in its scheduling. Thus when we finally hit our 64Kword limit I decided to tidy up the code, make it more efficient and write a 'serious' database. The result of all of that became Aber- MUD2, and when we got access to some nice new sun 3/50 workstations and a new fast compsci machine I spent a week or two porting and then tidying the code for Unix. The Unix version was about ten times as fast and very messy. Mostly because I didn't know C well(only B), and because the B to C conversion was mostly done with vi macros. In fact AberMUD today uses '**' not '*' to terminate things like converse mode because I missed a change. (In B * is like \ in C - thus ** means a single *). By now we had JD helping with the programming and ideas, and he wrote several useful widgets for the Honeywell ver- sion, but wasn't able to do much for the Unix release because as a Physicist he had no access to the Unix machines. JD like most AberMUD writers is still on the net, currently as an unemployed Unix administrator. JD is also worth a lot of description, but he'd only act modest and hide if I did. Once we moved to Unix things sort of took off. The code went to various sites - the first being UCL physics sun network and became quite popular there too. A version ran on a guest account at Southampton for a long period and was very popular (and extremely violent). Then I managed to fail my Physics accessory course and vanished for a year and a bit working for Horrorsoft on 'Personal Night- mare' and then 'Elvira', before finally returning to Swansea. In the intervening period AberMUD had taken off, and vari- ous people had done unspeakable things to AberMUD (like Rich $alz ANSIfying it). I got back in time to watch the first days of TinyMUD unfold on alt.mud, and see the ini- tial announcement for the firt test LpMUD. I'd also writ- ten the initial Amiga version of AberMUD5. Back at university I was side tracked for a while writing YAMA - a sort of portable MUD writing system, but which had an almost assembler like mentatilty and a tendancy to crash if you put bugs in the database code. On the other hand it runs a 300 room game on a 1Mb 286 PC running DOS, and is very portable ( AmigaDOS, MiNT (Atari ST), Sys5 Unix, BSD Unix, Linux, DOS, Windows ). After playing with YAMA for a while I got back to Aber- MUD5, and with the computer society now having a machine I had a host for it. It took 2 months before it would run on the machine with its 1Mb address space and other problems, but it was done. Since then AberMUD5 in its various forms has been added to by several Swansea people and has run continually on the computer society system since. A few months ago the AberMUD driver was rebuilt from the old pre-Horrorsoft system, debugged and expanded giving AberMUD 5.20 and friends which are the current fairly free release. Addition by Alex Greenbank (alex@cheese.org) I have added to the current source to produce a new release that fixes many of the bugs in the 'current' version. A userfile manager will also be included with the source, once I have written it. It might be documented aswell :) Features o TCP/IP networking o Intelligent client, with remote editing facilities o BSX graphics o Relatively low disk/memory requirements (1.5Mb RAM, 2Mb disk for a 600 room game) o Easy to program game language o Inheritance of object behaviour o MudWHO support o Optional registration based game system Features of Release 5.21.6 (Alex Greenbank revision). o Userfile Manager 'uafman' (possibly :) o Many bug fixes from 5.21.5 o Greatly updated manual Installation And Operation The AberMUD5 system is distributed in source form. The normal distribution is a distribution of source code, doc- umentation and initial game universe. To install AberMUD you should unpack the distribution archive with tar. Hav- ing unpacked the system you will have two subdirectories called:- 'DOC' Documentation 'SOURCE' System source code Go into the SOURCE directory and edit the file 'System.h'. This contains the configuration parameters that are hard coded into the game Options ANSI_C You can set this if you are using an ANSI compiler. NO_VOID Your compiler doesn't know what 'void' means. LOG_FILE This defines the name of the file used by both the system and database logging functions SECURE This option restricts some database actions like writing to arbitary filenames. It's for the really paranoid. UNIX Indicate you are compiling for Unix AMIGA Indicate you are compiling for Amiga LINUX Indicate you are compiling for Linux MAXUSER Maximum number of simultaneous players to allow. This value is limited by the number of file descriptors available. On a SUN for example this can be about 250. MAXNAME The longest length of a name a player is allowed. MAXUSERID The maximum length of a userid. Note the comments here - unless you are porting to a system with usernames longer than 32 letters don't alter this. PANSY_MODE The game doesn't delete people when they die off. Instead it halves their score and sets their strength quite low. Some people, especially in the US, prefer this option. REGISTER Ask and log users email addresses. You can alter the database to force registration should you desire that degree of security. TCP_PORT The default port used for connec- tions. The next two ports after this are also used for client and BSX links respectively. USERFILE The file where users are recorded. IMPORTANT: The pass- words used by AberMUD are not crypted. This file should be pro- tected. BOSS1..BOSS5 Set these to the names of charac- ters you wish to be able to use the system as a game controller. You should be very careful with this. The first letter must be capital and the rest lower case. Next check the Makefile is OK for your system. You may have to change the definition of CC in paticular. On SYS5 machines you will probably need to add networking libraries. The distributed Makefile is correct for Linux. Check the ValidLogin.c code. This is a module designed to be user customised to suit your own preferences on login control and maximum user limits. As supplied it permits 20 users between 11pm and 7am, 12 users between 7am and 9pm, 12 from 9pm to 10pm and 16 from 10pm to 11pm. When you have got all this right, you can just type 'make' and eventually you should end up with a set of compiled programs as follows:- server The game driver. This runs games Run_Aber A boot strap program. It discon- nects from the terminal when run, and reboots AberMUD whenever it finishes. FindPW This program can be used to obtain a players password. Reg Reg registers a person. AberMUD5 is normally run using the Run_Aber program. This starts up the server in the background, and should it crash or reset will restart a new server to replace it. The standard AberMUD reset mechanism is implemented in this manner by resetting the server itself every game reset. The Run_Aber program runs the server with the arguments it is supplied with. Thus the arguments to Run_Aber are the same as the arguments to the server itself. The server is a single large program which implements the communications, interpretation and editing of the game world. It is started with a command line of the form ' server '. It begins by loading the supplied universe file into memory then creates its network connec- tions and commences execution. You can select the range of ports used by the program by doing 'server -p '. This is commonly used when you want a seperate game copy for editing and testing. The game oper- ates on three ports. The first services normal telnet con- nections, as well as links to the standard mud clients. The second port uses a special protocol used by AberMUD5, and also now DickMUD, to permit lines to be uploaded and downloaded for local editting. An example client for this protocol is available. The third port runs Bram Stolk's BSX protocol, a crude but workable graphics protocol based on polygon downloads. To use the BSX facilities you will want the BSXmud client from lysator.liu.se. You may also want Muddraw should you wish to do graphical game editing. The other programs FindPW and Reg are small utilities that allow you to manage the user file. They provide the abil- ity to query a users password, and to mark a user as reg- istered, if the REGISTRATION option has been defined. This option is still under test and may or may not work cor- rectly. Overview of the Game Driver. If all you want to do is play with the supplied game and never get your paws dirty now is a good time to stop. I'm going to assume some basic understanding of programming and related ideas. Since this manual is so dire that you'll probably need to explore the source code to figure out what on earth is really going on I don't think that is too unfair. Although the manual has now been updated and now should be alot easier to understand. The original goal of AberMUD5 was that everything in the database would be a 'thing' and have the same basic behaviour. In actual fact there are several differently behaving sets of things within the AberMUD system. Firstly there are words. A word is a set of letters, a value and a type. The sole purpose of the value is to identify synonyms. Any words with the same type and value are synonyms. The game parser understands quite a wide variety of words, although only within a limited command oriented structure. The syntax is best described as sentence :== verb {item} {preposition} {item} | verb {text} | verb {item} {preposition} {text} item:== {ordinate} itemphrase itemphrase:== adjective {itemphrase} | noun The different word types are: verb: Normal command sentences begin with a verb. The parser doesn't understand the English structure 'use item to verb target'. Verb numbers 0-12 are reserved for directions, and 13-199 for game editing commands. adjective: An adjective qualifies a noun to define exactly which item is being referred to. An item can only have one adjective associated with it in the current system. The game allows adjectives and nouns with the same text, and correctly interprets them. noun: Each item within the game has a noun it is associated with. Nouns may be further qualified by adjectives. ordinate: An ordinate is used as the final level of qualification of a specific item. An ordi- nate secifies which of the matching set of items is to be used by number - eg fourth blue sack. preposition: As far as the game system is concered a preposition is any linking word that seper- ates two items within the command given. For example 'to' 'in' and 'from'. pronoun: Words like 'him' and 'her'. The game system tracks and manages the basic English pro- nouns :- him, her, it, them, there, me. When processing the parser substitutes back in the appropriate item for the words. Although these are a tiny subset of the language structure and the parser is easily fooled into interpreting things that would never be said in real English, it is more than adequate for the job, and more powerful than most other game system parsers. The game has some limits however. Firstly it is unable to handle the structure use to . This can be handled easily within the database as we shall see later. Its two much more real limits are the inability to handle <"string"> - for exam- ple say "hello" to eric, and the ability to handle sen- tences of the form , where the noun of item1 is also possibly an adjective. When a prepo- sition is used the parser is cable of handling the second example. The first case is a deliberate choice. To pro- cess say "hello" to eric, you would have to include the quotes. It was felt the ability to avoid quotes outweighed the advantages of handling this sentence form. The second type of thing within the database we have almost met already. When the parser resolves an adjective noun to give something which exists in the game world, it is resolving it to an item, the next in our three types. An item represents some physical or at least metaphysical entity within the game world. Unlike many game systems it makes no seperation between the different basic types , instead each of these types can be attached to the basic item. By working in this fashion game designers get maxi- mum flexibility and ease of use, since they never have to worry 'is this a player or a room', and in addition an item can be two or more of the types. We shall look in detail at items in the next chapter. The final type has to do with the result of someone typing in a command. Something has to explain what the game does when this command is entered This is the role of the database tables. These are sections of game code describ- ing conditions and testing and changing the status of items. It is these which allow the author to control and customise his world. A couple of minor types also float around the game system. The only one of note is the BSX picture, which is a pic- ture for Bram Stolks BSX graphics system. Basic Creation Having had a quick look at what floats around the AberMUD game universe, it is now time to have a look at how you get it there in the first place. Words are added and deleted with two sets of commands. The first add eg addverb, adds a word to the game vocab- ulary. The second del removes a word from the vocab- ulary. Addverb Adds a verb to the games vocabulary. As with all sorts of words two words of the same value and type are synonyms. Verbs with value below 200 are system verbs - for example addverb itself. If you miss out the value the game will pick a suitable unused one. Addord Add an ordinate (n'th) word - such as 1st , 2nd etc. For ordinates the value parameter is the degree of the ordi- nate - thus 1st is 1, 2nd is 2 and so on. Addprep Add a preposition (joining word) to the game database. With these words the value is used to indicate synonyms. If no value is given an unused one is selected. Addadj Add an adjective to the game system. Adjectives are pri- marily used to specify items more precisely. The value is used to determine synonyms only. If no value is given then an unused one is selected. Addnoun Add a noun to the game system. Nouns are primarily used to associate words with items in the game. The value is used to determine synonyms. Values of 10000 or higher are reserved for use by the game system internally. If no value is given a suitable one is selected. The game uses words 10000+ to add words itself when a player enters the game. Addpronoun Add a pronoun to the game system. The value for pronouns is used to indicate the behaviour of the pronoun. While the behaviours available are sufficient for English, if occasionally wrong in application, they may well not be sufficient for foreign language games. The behaviours are:- 1 Me 2 It 3 Them 4 Him 5 Her 6 There Delverb Delnoun Deladj Delprep Delpronoun Delord Delete a word from the game database. If the word is in use you will not be warned and items using that word will report for its text. It is generally a bad idea to remove a word that is in use. It is possible to do delverb addverb. I wouldn't recommend it..... Miscellaneous Commands abort Aborts the game driver, anything you are editing is lost. saveuniverse Save the game to the given name. The previous copy is backed up as .bak in case the save fails and is incomplete. users See who is connected to the game. status Get a status summary. statme See memory status (only if using dlibs fast malloc). quit Leave the game. Normally the game database will override these for play- ers. An archwizard however can always type a : at the start of the line to force it to use only the system words. This is vital in case you redefine everything by mistake, or place ANY ANY ANY DONE in Table 0. Items Once you have added adjectives and nouns, it is then pos- sible to create an item using them. When you create an item it acquires an adjective and a noun. The game system fills in the other properties of the item to suitable ini- tial defaults. The properties of a basic item are: Property Set With Adjective rename {to} Noun rename {to} Name setname text Parent place {at} Next place {at} Child place {at} State setstate <0-3> Perception setperception Lock Not directly alterable Actor setactor Action setaction Classes bexxxx ClassFlags setclass Superclass setsuper The important properties here are the adjective and noun which govern what words match the item. It is a very good idea to make the name match the vocabulary. For normal items use lower case for the name - eg 'the small axe'. The system knows the basic rules for capitalising names and also provides actions for doing so. The Parent, Child and Next fields are maintained by the system as objects move around. They control and describe the location of each item. You can place an item where you like with place . If you have several identical items even down to the adjective and noun, the system provides a syntax that can be used with the game editing commands such as place. Each identical item is #1 adj noun , #2 adj noun etc. #1 is always the most recently created. This is for convenience. Most people find that knowing the most recent are #1 and #2 is easier to work with. The state of an item is a value that can be changed as properties of an item change. It is used in several places by the system. In paticular light sources are normally lit in state 0. A door is open in state 0 , closed in state 1 and locked in state 2. A container is closed in state 1. You can arbitarily set this using setstate. setstate is slightly special in some ways, and this will be explained later (section 10) when we discuss chaining. The perception is the minimum level required to be able to see or refer to an item. It allows you to implement invis- ible things, and also to hide system objects from users. The Lock value is the number of references to this item. While this item is referred to or has contents it cannot be destroyed. Actor is the name of the list of database instructions that will be executed when a command is entered by a user. This is normally 0. Action is the name of the list used when an item is sent a message by another item. For play- ers this defaults to 2. Classes is a list of things an item can be - this includes Room, Player, Object, and Container - which we will deal with later on. Superclass is used for object based inheritance. Basically when a user types a command like 'get axe' the system first looks at the axe to see if it has a get rule. If it does not it looks at its superclass and sees if that has a get rule and so on until there is not a superclass. If it still hasn't found a rule it will try the actor table of the user. Finally it will give up and display 'I don't understand.'. The superclassing is controlled with the commands setsuper Set the superclass of an item. Setting it to itself clears the superclass showsuper Shows the full inheritance heirarchy of an item -eg big axe -> generic-axe -> generic-sharp-weapon -> weapon ClassFlags confusingly enough has nothing to do with the classes like Room, Player. It is a set of user definable flags that can be set on an item - for example to indicate if it is magical. These flags are controlled with the fol- lowing commands. listclass List the classes available. nameclass Name a class. setclass Make an item a member of a class. unsetclass Make an item not a member of a class. To create an item you type 'create adjective noun'. This will create a new item. The properties are defaulted as follows. Parent: NULL (nowhere) Name: the State: 0 Action: 0 Actor: 0 Classes: None SuperClass: None Having created an item you don't want, you will need to delete it. The system only allows you to delete an item that is not in use. An item is in use if it is a player, if it has contents, if it has a type - such as Object, Room etc, if an exit leads to it, or if it is referred to anywhere else in the database. The Locks count will show you the number of times an item is in use. To perform the deletion you type delete If the item is in use you will be told so, and it will not be deleted. Rooms Any item within the game can be made into a room. A room adds a set of rules and properties to the basic item structure. To make something into a room you do 'beroom '. To get rid of its room properties you do 'unroom '. To view the values type 'showroom '. A room has the following properties Short Description: A one line room description used for brief room descriptions. This is set by doing setshort . Long Description: A long description text. This text may be merged with other texts in ways controlled by the flags. This is set by using set- long you wish to read in. If text is blank the current text is provided for editing. To blank a description use */dev/null. (Yes I know its a hack). Flags: A set of optional behaviour modi- fiers for the room. These are set with setrflag Picture: Do not use - an obsolete field. More on graphics later in the BSX section. The flags are: Dark: Without a light source nothing can be seen. Outside: Subject to weather. This is now provided only for use by the database. All builtin weather code is removed. Death: The room causes death on entry. This is kicking off and not losing any points. Its meant for cases where people go stupid directions (like over a waterfall), and you just want to display some text and finish. All the users belongings also conveniently end up lost in the death flagged room. Merge: The room description will be merged with the description of the contents of this room if its join flag is set. Join: See above. An example probably makes this clearer - if you had a boat you could set it to merge and its description to 'You are in a boat.' If you set the join flag on the locations the boat floats around then you will see the rooms out of the boat. DropEMsg: As we will see shortly it is possible to have a message appear as you move from location to location. If this flag is set and such a message is printed the normal description is not displayed. Party: Mortals can emote to their hearts content. Being a room gives other basic properties. A room will be described, complete with its contents all nicely formatted up, using simple database facilities. A room has no size - it is assumed to be of infinite capacity. If you want a room to be size limited you need to make it a container - as we shall see later. The room flags can be listed with listrflags, and named with namerflag may be used by the system in later releases. Any user added room flags should start at the last one and work backwards. Exits While exits are associated with rooms they can be attached to anything. There are three types of exit within the AberMUD5 system. The first is the simple exit. Simple exits are created by doing newexit from_item direction to_item e.g. newexit Big Hall east Side Passage A simple exit can be made to an object or to a room. In the normal form the exit is to a room. In these cases any- thing moving in that direction travels from the one room to the other. If the exit is to an object, the object is assumed to be a door. In this case movement through the exit is only possible if the object is in state 0 (open). Anything moving through such an exit is moved to the item containing the door. Such exits are removed by doing delexit . All other types of exit are removed in this fashion too. A message exit displays some text as the player travels in that direction. A typical use might be a chute which dis- plays cloud of thick dust.'. For such a chute you might not want the room description to appear. In this case you can set the 'dropemsg' flag for the room. To create such an exit do msgexit A currently existing text can be edited by doing msgexit Finally a conditional exit allows you to attach a table of database. These are created with condexit We will deal with tables much much later on. The condexit is only included here for completeness. Note: It is possible to have multiple exit types in the same direction from the same location. What happens if you do this is undefined - so behave and don't do it. Remember, room names are displayed on exits, so don't call rooms 'Ha Ha You Got Killed'. Objects Any item which can be carried around is probably best set to be an object. Many things that can't be carried around are object too. To make something an object type beobject . To remove its object properties type unobject . An object has the following properties which can be viewed by typing showobject . Descriptions: Four descriptions, one for each state. These are set using set- desc . As with rooms *text means load from a file. Its a common trick to use state 3 to hold examine texts for everything. In new.uni (supplied with this distribution) the descriptions are numbered thus 0 Object 'open' 1 Object 'closed' 2 Object 'locked' 3 Object description. These only apply to objects that can be opened/closed/locked, otherwise objects normally stay in state 0. Size: The amount of space the item takes out. Set using setosize. Keep this below about 1000 to avoid weights wrapping over the size of a number and giving odd results. Use the osize command to set this. Weight: The weight of the item (without any contents). The same comments about values apply as with sizes. Use the oweight command to set this. Flags: Flags controlling the behaviour of an object. The flags are: Flannel: In a description the item is tacked onto the end of the room description not listed on a line of its own. NoIt: The item will not automatically become 'it' if seen. Worn: The item is currently worn. Destroyed: Obsolete and unused. CanGet: The item can be picked up. CanWear: The item can be worn. Opens: The item can be opened/closed. LightSource: The item is always a light source Light0: The item is a light source when in state 0 NoSeeCarry: The item cannot be seen when it is being carried. Set this for small items you would not spot on someone. Flags are named with nameoflag . They are listed with listoflags. You can set and unset flags on an object by doing setoflag . Use - to remove a flag. Containers Several other classes are commonly associated with Objects, although they can be used with any type of item. In paticular the container class. To make something a container you use the command BeCon- tainer . To remove its container properties you use the command UnContainer . A container has only two properties Volume: The total item size you can fit in the item. This is set with the command setvolume . Flags: Flags controlling the item. The flags are: Soft: The size of the container increases by the size of its con- tents. For example a bag. seethru: The contents of the item can be seen, also light sources in the item illuminate the parent item. canputin: You may place items in this item with the standard database actions. cangetout: You may take things from this item with the standard database actions. These are seperate for items like post boxes. closes: The item closes, and things can only be removed or placed in it when it is in state 0. The flags are manipulated by using setcflag . As with the other classes - means clear the flag. Container flags may be listed with listcflags , and named with namecflag . A room can also be a container, in which case you will be unable to enter it if you won't fit its volume. Players A player object is not just a game user, but anything which acts of its own volition. A player object has prop- erties allowing it to fight, take damage, carry things and controlling its behaviour a follows. UserKey: -1 for all non users, otherwise the user number. This cannot be altered. Strength: This controls how much damage a player can take. When this is reduced below zero by one of the standard database actions death occurs. Size: The players size. When something is both a player and an object, the object size is used. For users this defaults to 120, but can be set. Weight: The weight of the player. When something is both a player and an object, the object weight is used. For users this defaults to 120 but can be set. Score: Older versions of the system only saved fields within the player structure when a user quit. Thus this field was part of the player structure. It is unused by the sys- tem. Level: This is intended to reflect the ability of the player. The database language pro- vides several functions for testing and acting on this. The only direct effect it has is on carrying ability - which is cal- culated as 10*level+400 units of weight. In addition a player can carry a maximum of 9 distinct items - ignoring things like sack contents. These are hard coded due to speed reasons but may be changed by alter- ing Container.c Flags: A set of flags governing system handling of the game object. The flags are: male The item is male. It will be addressed as him or he, and will set the him pronoun. female The item is female and will set the she pronoun. Setting both male and female is not supported. Setting neither makes the item neuter. brief Indicate to the system that the player wishes to use brief descriptions and mes- sages whenever possible. Little in the game system currently uses this. blind The player is blind and will fail to see some things happening as a result. Events that can be heard will be treated as if they were carried out in the dark. deaf The player is deaf and will not hear any- thing. Visual events are unaffected. The game correctly processes the combination of blind and deafness (I hope!). The following commands alter the player class properties: beplayer Make the item a player. unplayer Remove the player properties of an item. showplayer View the player properties of an item. setpstrength Set the strength of a player. setplevel Set the level of a player. setpscore Set the score of a player. setpsize Set the size of a player. setpweight Set the weight of a player. setpflag Set a flag on a player item. You can remove a flag setting by using -flag. listpflags View the pflags. namepflag Name a player flag. Other Classes Snoop: This class is used to maintain lists of which users are watching which users magically. Snoop allows a user to see exactly what appears on another users display. This class pair is maintained automatically by the system and database actions. Note, snoop will only display output from table code actions, NOT from server based commands. This is to stop lesser people snooping sensitive things that they should not see. Dup: This is used to tag temporary clones of an item. Such clones have to be tagged as when they are destroyed by the database they vanish forever. InOutHere: When a player moves it displays messages of the form: These text strings can be customised in the game database language. The current settings are stored in a InOutHere class. Chain: When the state of an item is changed by the database any item it is chained to also changes to that state. Note that a chain is one way, so that to lock a pair of items to the same state (eg a door) you would chain both to each other. Chains are created with the command chain , and removed with the command unchain . The II command for viewing basic item information displays chains in its list of classes as 'Chain -> ', and this command can thus be used to view chains. UserFlag: UserFlag2: UserText: A total of eight strings, sixteen other items and sixteen numbers can be stored as user flag values by the database. The command showuser displays these values. To min- imise storage they are fragmented into three classes. One holds the first 8 items and values, the second the next 8 items and numbers, the final one holds the text. Thus you should ensure that items needing several of these values generally end up with all flags used falling into one of these categories to minimise memory usage. Share: When you have a set of identical items you can use share to lower memory usage. For example to create a maze you might create 12 items set exits between them, give one a room property and then tell all the others to share it. Any classes an item doesn't posess are fetched from its shared item. It is important to note that anything affect- ing the shared class will affect the one in the item it shares it from. Thus to make a room of a shared item and alter its properties you MUST unshare it first. Shares are constructed by typing share , and removed by using unshare - where item1 is the item which uses classes from item2. As with chains they are shown by the II command. Handy Commands Several handy commands are built into the game system to aid testing and building. In paticular when dumping a large game to generate printouts, the commands showallplayers , showallrooms and showallobjects may prove useful. On especially complicated area is building a door. This requires creating two items, making them objects, naming them, chaining them to each other, placing them somewhere and finally setting exits in both directions. Because this is so messy a single command doorpair , creates a door named adjective noun in both rooms, sets initial descriptions links it all up and creates a bidirectional door between the two rooms. The users command gives a dump of who is playing, from where, and what they are doing. The status command gives an overall summary of system usage and the number of each type of item created. The statme command reports total free memory when using the dlibs memory allocator. This is an option which vastly speeds up the game boot time and improves its running per- formance on machines with broken as designed memory allo- cators. SuperClassing The basis of superclassing is a sort of compression to make sure universes don't get out of hand size wise. Basically when you superclass an item to another item then it will have the same Object/Subject/Daemon item-tables as the item it is superclassed to. As that may have baffled you completely I will include an example. When a player dies (or a mobile) a corpse is left behind. The corpse is DUP'd from a corpse kept in the System Store , this is placed where the person died and desc'd to look as if it was the corpse of ''. This is simple enough but does not need superclassing to achieve it. What does need this extra function is the idea of bounties for killing players. Players can put bounties up for other players, because they may hate them or for whatever reason. When a player is killed their bounty (x coins) is given to the corpse. Not as an object but stored in a userflag. Now when a player examines the corpse it runs the subject table of the corpse , this subject table checks to see if there was a bounty on the player who's corpse it is, if so it rewards the person who examined it with the bounty. The problem of doing this without superclassing is when the corpse is DUP'd the game thinks it is a completely new item , therefore the object/subject/daemon tables for the corpse are empty. Superclassing the DUP'd item to the original makes the DUP'd item have the same subject/object/daemon tables as the original. Therefore the original corpse is programmed with the special examine code and any corpses created by players dying will be able to use this. To get round this without using superclassing would have meant that I would have had to add some code into Table 0, so that if a corpse was examined it would do the correct and appropriate thing. This clutters Table 0. At the current point in time I cannot think of any reason that you may wish to use superclassing. So please consult me if you have an idea that you may need superclassing to implement. Interpreter Structure This is the heart of the game, sure you can use the game as supplied but if you want a better game or you want to modify or change it in any way then you will have to do some table coding. This daunts many people as basically you can really screw up a universe file if you are not careful. I will (if I end up writing them :-) have several sections explaining various parts of table coding. Hopefully it will be a learn as you go method of learning, not relying on any knowledge or previous experience to understand. I will also be using examples of code to give people a easy idea as to what something would be like if implemented into the game. Anyway, on with the Tutorial. Introduction to Tables and Table Coding (The BASICS) There will be some tables associated with the game, some are coded in at server level, i.e. the are assumed and used by the server itself. Although most are universe specific. For example, the tables NewUser (101) and ReturningUser (102) are executed by the server when a new player logs in. This is because it would be impossible to implement this in the game code itself. Therefore these tables are bound to the table numbers. Tables are bound to numbers, it doesn't matter what they are called. It is the number that is unique to each table. You cannot change a number although you can change the name as often as you like. Tables consist of a several things. As said they have a name, this is used to identify them more easily. But the main part of the table are the actual code lines. The tables are executed from the first line until several conditions occour. Either the table runs out of lines to execute or the table is terminated by a special table action. Lines are in the format {} i.e., a verb, 2 nouns, and any number of actions. When lines are executed, they are executed from left to right along the line until they meet a condition that is false. I.e. The verb must match the verb typed. `ANY' is used as a wild- card verb, so that it will always be true and continue. noun1 must match the first noun to be typed. The noun can be a reference to an item or just a noun. Again `ANY' is used as a wild-card. noun2 must match the second noun typed. The noun, again, can be a reference to another item. Again `ANY' is used for a wild-card. Then the actions are executed, some actions always return true and so execution continues. The verb/nouns are the verb/nouns entered at the command line. Although there exist some ways to change what the user entered, these are discussed later. Lots of tables, but which do what? I said earlier that some tables have specific purposes, here is a list and description of what tables do. I will use the numbers here because not everyone has the same table names. Table Description ----- ----------- 0 Executed when a player types a command. 1 Initialise Table. 2 The Daemon table, Daemon actions execute this. 100 Status Table, executed before the prompt is displayed. 101 New player has logged on. 102 Old player has logged on again. 103 Automatically executed when DESC action is called. 104 Automatically executed after DESC, but before items present are displayed. 105 Automatically executed after DESC and after items in the current location have been displayed. Purpose of inbuilt tables Table 0: Command/Execute Every time a user enters a command it first runs this table with the verb/nouns set to what the user entered. If the table runs to the end of the table without being terminated then it will parse the line to the server, this has some commands inbuilt and will attempt to execute these. For a note: Anything that is run by server commands will NOT be displayed via snoop. This is to stop other players seeing things they should not. Table 1: Init[ialise] When the game is booted up then this table will be run before any users will be able to log in. This table is used to set up the contents of game flags such as reset time etc. Also this can be used to call the necessary tables to start mobiles moving etc. Table 2: Daemon When the DAEMON related action commands are issued in the table code then this table will be called with the parameters given. When I discuss daemons this will become more obvious. Table 100: Status Can be used to check things about a player as it is executed just before a prompt is sent to a player. Presently I use this for checking people strength to make sure it does not go over their limit. Check score in the same way (i.e. not over 29000) and to call a table to make sure that their level is the correct one for their score. Table 101: NewUser Executed when a new user logs in. This sets up basic things, i.e. places them at the start room. Does checking to see if the game is actually locked or accepting new logins, and starts of the delayed runtime tables that perform such things as healing, autosaving etc. Table 102: ReturningUser Just like NewUser really, although I do somethings in this table that I wouldn't do in NewUser. For instance, I have two counters. One counts the number of new players and the other counts the number of players that log in. So I can see how busy the game is. Table 103: PreLook Can be used to check for things like blind etc. If this table is terminated before reaching the end then the DESC action will not be performed. I use this to display information about the room via look. I.e. room flags for high levels (creators/wizards). Table 104: PostLook Can be used to tag things on that belong more to the description than the objects inside the room. For instance I call a table which displays the current game weather. The objects in this room are described after this table finishes. Table 105: PostObjectDesc I don't use this table atm, and have commented it out of the code accordingly. It can be used to do things after the objects in the room have been described. Coding Styles Before I go any further into table coding I will talk about coding styles. Yes even something like AberMUD 5 has styles of coding and will probably start a holy war like C coding has (Once True Brace Style, Allman etc). During my time using AberMUD 5 I have come across a several methods of code style programming. There are also two areas of code that have styles. One area are the lines themselves. Here there are two basic styles:- 1) Compound-action lines (CAL) 2) Single action lines (SAL) e.g. a user enters a command and you wish to execute some actions. Using an example of a command. quit ANY ANY LET @Temp 3 ALLDAEMON wizverse ANY ANY DOESACTION $ME {has disconnected.} 4 MESSAGE { } SAVE PCNAME $ME { has been saved.} END { GoodBye!} DONE Or using single action line style... quit ANY ANY LET @Temp 3 quit ANY ANY ALLDAEMON wizverse ANY ANY quit ANY ANY DOESACTION $ME {has disconnected.} 4 quit ANY ANY MESSAGE { } quit ANY ANY SAVE quit ANY ANY PCNAME $ME { has been saved.} quit ANY ANY END {Goodbye!} quit ANY ANY DONE You can imagine the advantages and disadvantages of using either method of programming. On the upside SAL seems more readable and would be easier to change if there was a bug or if you wanted to change say the MESSAGE line. But, used throughout the code, it will make the code larger. How significantly I can't say. Another idea will be discussed after I explain the other area of coding styles. There are yet another 2 styles although not the same idea as the latter but still related. These styles are these:- 1) Pre-event exception (PREE) 2) Post-event reporting (POSR) For example, a command line for a priveleged commmand that also has some requirements or conditions. The PREE version... arch ANY ANY NOT ARCH MESSAGE {I don't understand.} DONE arch ANY ANY AT quiet place MESSAGE {You cannot from this room.} DONE arch ANY ANY PFLAG $ME Coding MESSAGE {You in coding mode!} DONE arch ANY ANY ALLDAEMON arch ANY ANY DONE Or the POSR version, arch ANY ANY ARCH NOT AT quiet place NOT PFLAG $ME Coding ALLDAEMON arch ANY ANY DONE arch ANY ANY NOT ARCH MESSAGE {I don't understand.} DONE arch ANY ANY AT quiet place MESSAGE {You cannot from this room.} DONE arch ANY ANY MESSAGE {You are in Coding mode!} DONE As you can see, the PREE version is more adaptable to the SAL style. Since, after checking all of the false conditions you can then go about the action on single lines, knowing that these commands will only be executed with all of the precon- ditions true. With PREE style you will have to make sure that ALL of the exceptions are covered. Think about all of the attributes the players have and consider all aspects of them, i.e. they must be of the right level to be able to execute the command etc. Table Coding Manual M. MacNaughton (Lager) To understand the table coded interpreter system we must first understand the properties which the interpreter deals with. Each time a command or table is executed the processing continues until everything required has been satisfactorily completed. Once that occurs it will interpret the next queued request. For the duration of each individual execution there are a number of variables the interpreter can use. There are a number of flags, listed by listflag, into which numbers can be copied and copied from. Note that these are not necessarily cleared for ea h new execution. A number of variables can be loaded and changed if required. To demonstrate these first you must understand the three requirements of table code. A line of code must always have :- However if any or all of these are unnecessary and don't affect the functionality of the code, then they chould be replaced by ANY. Each line is processed until either a condition is false, the word DONE is encountered or the table has no more lines in it. Anyway here are the variables and a brief description. $ME :- The item which the interpreter is affecting. For example when a command (table 0) is interpreted $ME is set to the person typing the command. $AC :- Used by Daemon action, more of which later. $RM :- The item containing the initiator of the database action. For example on typing a command the interpreter will store the room you were in in $RM. $1 :- Contains an adjective noun pairing. On typing a command the interpreter stores the first adjective noun pair after the verb in $1. $2 :- Similar to $1, only contains the second pair after the verb. $ :- The user input after the first verb is stored in here. $2 :- The user input after the first noun is stored here. Each interpreter command needs various arguments to execute properly. The listing below shows their characteristics and examples of use. : Takes the name or number of another database as the argument. : Note that $ME, $AC, $RM, $1 and $2 are all items. You can also use the name of any item known to the database. e.g. IS large axe $1 AT $2 : Obviously enough a number. Values can range between -29999 and 29999. Also if you type listflag then use the number beside the flag preceded by an F the value in the flag is used. e.g. LET @flag 18 LET @flag F2 : A text string is used for the argument. These should be enclosed by '{' and '}'. Also {$} and {$2} can be used. e.g. PARSE {$} END {Haha, you're dead!} : Used when a word is required for the argument. Could be a verb, adjective, noun or preposition. : Takes some class as an argument e.g. ISCLASS key ISCLASS boat : Used when something is going to be loaded into $1 or $2. Therefore can only have 2 values. Either 1 or 2. If 1 is used $1 is loaded with the item, similarly for 2. : Pflag, cflag, rflag, oflag One of the first things to be realised is that all inputs should be checked. The major worry is whenever $1 or $2 are loaded with anything. There are a number or commands to enable checking. IF1 (similarly IF2) :- Checks the location of the player for the item. If the player is carrying the item or the item is in the same place then IF1 (IF2) will return true. IF1 checks $1 and IF2 checks $2. e.g. drop ANY ANY IF1 CARRIED $1 DROP $1 DONE If the IF1 was left out then whenever a user mistyped the item to be dropped an error message would be displayed. Sometimes however we wish to check further afield than just the same location. There are two other commands to check the validity of $1 and $2. They are : GETO WHATO In both cases number must be 1 or 2 depending on whether $1 or $2 is to be checked. WHATO checks the entire database. Basically it checks $1 or $2 against every item known to see if it matches . This is useful for goto or tohand or similar, e.g. goto ANY ANY WHATO 1 PLACE $ME $1 DONE tohand ANY ANY WHATO 1 PLACE $1 $ME DONE Please note that all examples are as simple as possible and don't contain any DOESACTION. This is to improve readability. GETO on the other hand only checks whether $1 or $2 are contained inside , e.g. take ANY ANY IF2 GETO 1 $2 TAKEOUT $ $2 DONE Now that checking for objects has been covered it would be a good idea if we could manipulate these objects. There are four commands which, providing all the necessary objects exist, do the appropriate checks automatically. These are GET, DROP, TAKEOUT, PUTIN. GET checks that the object is in the same location and has its canget flag set. An error message is output to the user if the object is not in the same location or cannot be taken for some reason. GET DROP TAKEOUT PUTIN Typical code to implement the get command is :- get ANY ANY IF1 GET $1 DONE get ANY ANY MESSAGE {Get what?} DONE The DROP command works in virtually the same way (although obviously it doesn't have to check the canget flag). Example code :- drop ANY ANY IF1 DROP $1 DONE drop ANY ANY MESSAGE {Drop what?} DONE TAKEOUT and PUTIN work in a similar sort of way. The only difference is that they check that the object that things are to be put in or taken out of is actually a container. TAKEOUT also checks that the flag has a cangetout flag set. PUTIN checks both he canputin flag and also that the container limit would not be breached by putting the object in. Examples - get ANY ANY PREP from IF1 IF2 TAKEOUT $1 $2 DONE put ANY ANY PREP into IF1 IF2 PUTIN $1 $2 DONE In both cases the first item is the item to be moved and the second item is the container into which the item is to be moved. Note also that all four commands send messages to everyone in the room informing them of the action which occurs. Of course on many occasions we don't want simply to manipulate objects which are in the same place. Sometimes actions can depend on the position of caertain objects. To help there are interpreter commands for checking the position of items. AT NOTAT The AT command returns TRUE if the current player, i.e. the player loaded in $ME, is contained inside the item. NOTAT is the reverse of the AT condition. This action is generally applied to rooms. Only a room or a large enough container can directly co tain a player inside them. wave staff ANY AT magic room PLACE $ME start room DONE wave staff ANY NOTAT magic room MESSAGE {You are in the wrong place} DONE It is obvoius that similar commands would be useful for checking if objects are in the correct place. PRESENT ABSENT CARRIED NOTCARR These four commands are listed together because they do similar jobs. ABSENT and NOTCARR are obviously the opposites of PRESENT and CARRIED respectively. PRESENT : This command checks to see if an object is in the same location as the current player, i.e. the player loaded into $ME. The action returns TRUE if the object either shares the same location as the player or is being carried by the pl yer. It returns FALSE if the object is in a container being carried by the player. It also return FALSE if the object is being carried by another player, even though the player may be in the same place. CARRIED : This command is similar to the PRESENT command but only returns TRUE if the player is carrying the object. All the restrictions of PRESENT apply. e.g. unlock door ANY PRESENT door key SETSTATE ANY DOOR 1 DONE break ANY ANY CARRIED sturdy hammer SETSTATE $1 0 DONE It should be noted however that sometimes we wish to check not where an item is in relation to a player but instead in realtion to another item. ISAT ISBY ISIN ISNOTAT ISNOTBY ISNOTIN Obviously ISNOTAT, ISNOTBY and ISNOTIN are just the reverse of ISAT, ISBY and ISIN. ISAT : ISAT is true if item1 is directly contained within item 2. This occurs when if item 2 is a player, item is being carried. Or if item1 is inside item2 which could be say a container or a room. It will return FALSE if for example item1 and item2 are in the same location. ISIN : This function in effect performs the same function as ISAT. However whereas ISAT would return FALSE if item1 was in a container which was contained in item2 ISIN would not. ISIN will return TRUE even if there are layers of cont iners within item2 that contain item1. ISBY : ISBY is TRUE if item1 and item2 share the same location. They could be in the same room or both could be being carried by the same player. It will return FALSE if for example item1 is in a container, the container and item2 bei g carried by the same player. Also if both items are nowhere FALSE is returned even though they are effectively in the same place. search ANY ANY ISAT $1 $2 MESSAGE {It's in the container.} search ANY ANY ISIN $1 $2 MESSAGE {It's in there somewhere.} search ANY ANY ISBY $1 $2 MESSAGE {They are in the same location.} DONE Of course once we have checked the positioning of items we may need to move them around. Sometimes we will need to check first that the object will fit. CANPUT : This command is used to check that item1 can be placed in item2. Item2 can be any sort of game object, container, room, player : it checks that, if item2 is a container, container limits are not breached. If the item is a play r checks are made that the player has the strength to carry, and also the player is not carrying the maximum number of items. get ANY ANY IF1 CANPUT $1 $ME PLACE $1 $ME DONE Now that the mechanism for checking if objects will fit is in place commands are needed to move the object there. SWAP PLACE PUTBY GIVE GOTO CREATE DESTROY SWAP The swap command simply swaps over the location of item1 and item2. Absolutely no checks are made, they are simply swapped. And nobody is informed of the event. swap ANY ANY WHATO 1 WHATO 2 SWAP $1 $2 DONE --o-- PLACE Item1 is placed into item2. No checks are made and nobody is informed. This is fine if item2 is a room, player or container but beware as item2 could be an object. In that case item1 would be placed inside the object. Of course that means there would b no way of removing it for ordinary players. goto ANY ANY IF1 ISROOM $1 PLACE $ME $1 DONE --o-- PUTBY PUTBY is similar to PLACE. The difference is that PUTBY places item1 in the same location as item2. No messages are displayed and no checking for size or weight is done. Item1 is simple moved to the same place as item2. summon ANY ANY IF1 ISPLAYER $1 PUTBY $1 $ME DONE --o-- GIVE GIVE is different to all other commands in this section because checking is used. Item1, which the current $ME must be carrying, is given to item2. Item2 must be able to carry the item, i.e. must be a player whos carrying and weight limits will not be reached. The appropriate people are informed if the action succeeds. Otherwise a message explaining why it failed is given to the current $ME. give ANY ANY IF1 IF2 PREP to GIVE $1 $2 DONE --o-- GOTO GOTO is similar in some ways to PLACE however it has a number of differences. With GOTO the current player (the current $ME) is moved into the item. No checks are done so care must be taken not to move the player into something unsuitable, like an obje t for example. The location is not described to the player. However players at the departure and arrival points are informed of the action occuring. gate ANY ANY IF1 GOTO $1 DONE --o-- CREATE The item is moved to the location containing the current player. No checks are done to see if the item will fit. Note that although it is called CREATE the item must already be known to the database. CREATE does not actually create a new item. --o-- DESTROY The item is moved to the void. Note that if the item uses a temporary duplicate (see DUP later) then it is completely destroyed and removed from the system. {Check whether message are given out or not} REMOVE IN FINAL VERSION. --o-- To complete the section on objects there are just a couple of loose ends to tie up. WEIGH WEIGHT SIZE WEIGH WEIGH simply weighs the item in question and stores the weight in the specified flag. If the item has other items contained in it, e.g. a player or container, then theses items are included in the weight for the item. WEIGHT SIZE WEIGHT sets the weight of the item to the number given. SIZE does the same thing for the size of the item. It is important to be able to deal adequately with states as well. If an item is in state 0 it is open, 1 if it is closed, 2 if it is locked. Although there is also a state 3 this is generally used to store the text for an examination of it. STATE True if the item is in state indicated by number. open ANY ANY IF1 STATE $1 0 MESSAGE {It is already open.} DONE INC DEC INC increments the value of the state by 1. If it is already 3 then nothing happens. DEC decrements the value of the state of the item by 1. If it is already 0 nothing happens. open ANY ANY IF1 STATE $1 1 DEC $1 MESSAGE {It opens.} DONE close ANY ANY IF1 STATE $1 0 INC $1 MESSAGE {You close it.} DONE SETSTATE SETSTATE sets the state of the named item and any item chained to it to be the number. open ANY ANY IF1 STATE $1 1 SETSTATE $1 0 MESSAGE {It opens.} DONE WORN NOTWORN WORN checks to see if $ME is wearing the specified item. $ME must also be carrying the item to be wearing it. NOTWORN is the opposite. electrify ANY ANY NOTWORN golden torc MESSAGE {You can't do that.} DONE electrify ANY ANY WORN golden torc PROCESS doelectrify DONE Obviously to wear things we need some command to process things correctly. REMOVE WEAR WEAR checks to see if the item in question can be worn by the current $ME and checks the items canwear flag is set, and also that the item is an object. If all conditions are satisfied true is returned and other users in the location are informed. If n t an error message is displayed. Similarly for REMOVE. It checks that the current $ME is wearing the item and it can be removed. If the conditions are satisfied then all other users in the location are informed. If not then a suitable error message is displayed. wear ANY ANY IF1 WEAR $1 DONE remove ANY ANY IF1 REMOVE $1 DONE --o-- Checking -------- Obviously to take some actions we need to check certain conditions and the interpreter has a number of commands to make this easier. ISUSER ISPLAYER Both of these check more or less the same thing. However there is a subtle difference. ISUSER will only return true if the item checked is a user i.e. sombody logged onto the game. However ISPLAYER returns true if the item in question is either a user r mobile. tell ANY ANY NOT ISUSER $1 MESSAGE {You can only send messages to other users} DONE fireball ANY ANY NOT ISPLAYER $1 MESSAGE {You can only fireball other players} DONE ISOBJECT ISROOM These are fairly self explanatory, so I'll just illustrate what they do with simple examples. get ANY ANY IF1 NOT ISOBJECT $1 MESSAGE {You can't pick that up!} DONE stat ANY ANY IF1 ISROOM $1 MESSAGE {It's a room!} DONE Players, objects, rooms and containers each have a number of binary flags associated with them which can be set or unset. These are checked by :- PFLAG OFLAG RFLAG CFLAG Checks whether one of the item flags relating to the class of the item is set. If the item does not even belong to that class then false is simply returned. look ANY ANY RFLAG $RM dark MESSAGE {It's dark.} DONE up ANY ANY PFLAG $ME crippled MESSAGE {Your legs aren't working.} DONE get ANY ANY IF1 NOT OFLAG $1 canget MESSAGE {You can't take that.} DONE put ANY ANY IF1 IF2 NOT CFLAG $2 canputin MESSAGE {You can't do that.} DONE ADJ1 ADJ2 I have never found a use for these two commands thus far. However what they do is check either the 1st or 2nd adjective noun pairing and if the adjective corresponds to adj then true is returned. I will not illustrate their usage as I have yet to find ne. NOUN1 NOUN2 Two more rarely used commands. There are generally better ways of checking things hence their unpopularity. However these again check either the first or second adjective noun pairing entered and if the noun corresponds to the noun beside the command t en true is returned. unlock door ANY IF2 NOT NOUN2 door key MESSAGE {You need a key to do that.} DONE PREP This is a slightly more useful statement. It checks to see whether one of the prepositions, e.g. with, into, was used in the command line. take ANY ANY IF1 IF2 CARRIED $2 PREP from TAKEOUT $1 $2 DONE --o-- Flags ----- Aside from flags which relate to objects, rooms or players the interpreter has a number of flags known to it, listed using listflags, into which numbers can be stored and manipulated. Only commands executed by the interpreter can change the numbers sto ed in them. A user cannot change them directly. An example is the flag which stores the minutes to reset. This is set in the initialisation table. Then another table is executed automatically every 60 seconds, which provided the stop reset flag isn't s t, decreases the count by one and once it reaches zero resets the server. Hitting a reset stone for example merely copies one minute into the flag and then the next time the table is called the flag is reduced by one to zero and a reset occurs. Obvious y this is only one of the functions of flags. Almost all maths done by the interpreter is done using flags. So here is an in-depth look at some of the interpreter commands we use to manipulate flags LET Stores the value number in the named flag ANY ANY ANY LET @Reset 120 EQ NOTEQ EQ is true if the value stored in the named flag is equal to the number. NOTEQ is the reverse. ANY ANY ANY EQ @Reset 0 PROCESS Resettable wiz ANY ANY GETLEV $ME @temp NOTEQ @temp 16 Message {I don't understand.} DONE GT LT GT is tru if the value stored in the named flag is greater than the number. Similarly LT is true if the value stored in the named flag is less than the number. wiz ANY ANY GETLEV $ME @temp LT @temp 16 MESSAGE {Only wizards can use this special channel.} DONE tohand ANY ANY IF1 GETLEV $ME @temp GT @temp 15 PLACE $1 $ME DONE ZERO NOTZERO ZERO is equivalent to EQ 0 NOTZERO is equivalent to NOTEQ 0 ANY ANY ANY ZERO @Reset PROCESS Resettable ANY ANY ANY NOTZERO @Reset SUB @Reset 1 Compare EQ with EQF NOTEQ with NOTEQF GT with GTF LT with LTF They work in exactly the same way however rather than checking the value in flag1 against a number it is checked against the value in flag2. Now that we have a means of testing flags we need to deal with how flags get given values in the first place. Although we have met the trivial LET and dealt briefly with WEIGH there are quite a number of other ways of entering value into flags. SET CLEAR SET writesthe value 255 into the named flag. CLEAR writes the value 0 into the named flag. (Table 0) wizlock ANY ANY SET @wizonly wizunlock ANY ANY CLEAR @wizonly (Login Table) ANY ANY ANY NOTZERO @wizonly GETLEV $ME @temp LT @temp 16 END {Sorry, only wizards allowed on just now.} DONE COPYFF Copies the value of flag1 inot flag 2. GETSCORE SETSCORE GETSCORE copies a players score into the named flag. It has not been stated by the programmers what happens if the item is not a player item, so if in doubt always check using ISPLAYER first. SETSCORE sets an item's score to be the value in the lag. Again, if in doubt, err on the side of safety. frob ANY ANY IF1 ISPLAYER $1 GETSCORE $1 @temp ADD @temp 100 SETSCORE $1 @temp DONE GETSTR SETSTR GETSTR copies a players strength into the named flag. Again it is not stated by the programmers exactly what occurs if the item is a non-player. SETSTR sets an items strength to be the value in the flag. ANY ANY ANY GETSTR $ME @temp LT @temp 1 WHEN 0 Death DONE eat ANY ANY IF1 ISCLASS $1 food GETSTR $ME @temp COPYOF $1 0 @temp1 ADDF @temp @temp1 SETSTR $ME @temp PROCESS strlimits DONE GETLEV SETLEV Here at least the programmers have made it clear what happens when the item is a non-player. All non-players have level 0 no matter if, for example, SETLEV 16 was sent to it. GETLEV copies the level of the item into the flag. SETLEV sets the lev l of a player to be the value in the flag. wiz ANY ANY GETLEV $ME @temp LT @temp 16 MESSAGE {Only wizards can use this special channel.} DONE ANY ANY ANY GETSCORE $ME @temp GT @temp 99 LT @temp 300 LET @temp1 2 SETLEV $ME @temp1 Whilst we are on the subject of level, then LEVEL should be mentioned. This is true if the current $ME is at least level number or above wiz ANY ANY NOT LEVEL 16 MESSAGE {No way.} DONE There are a couple of other methods of writing to and from flags however these will be covered in a different section. Now we have the ability to copy things into flags we need to be able to manipulate them. ADD The number is added to the value in the named flag and the result is tored back in the flag. i.e. flag = flag + no. Similarly for :- SUB Subtraction flag = flag - no. MUL Multiplication flag = flag * no. DIV Division flag = flag / no. frob ANY ANY IF1 ISPLAYER $1 GETSCORE $1 @temp ADD @temp 100 SETSCR $1 @temp DONE MOD The mathematical equivalent is flag = flag / no. mod no. i.e. flag is divided by number and the remainder is stored in flag. Two examples - ANY ANY ANY LET @temp 49 MOD @temp 7 It is processed 49/7 = 7 remainder 0 so 0 is stored in @temp ANY ANY ANY LET @temp 100 MOD @temp 8 Now 100/8 = 12 remainder 4, so 4 is stored in @temp Now compare :- ADD with ADDF SUB with SUBF MUL with MULF DIV with DIVF MOD with MODF Here with ADDF, SUBF etc the value in flag2 is used instead of number. Note that in all 5 operations flag2 is unaffected. Only flag1 is ever changed. i.e. ADDF is equivalent to flag1 = flag1 + flag2 RANDOM A random number between 0 and (number-1) is stored in the named flag. Flags can also be changed one bit at a time. An example use of this could be quests. Here we could have 8 bits to represent 8 quests. By initially clearing the flag, we could set the appropriate bit of the flag if a quest is completed. BITCLEAR BITSET BITCLEAR clears the bit number (i.e. makes that bit 0) BITSET on the other hand sets it (i.e. makes it 1) Suppose bit 2 represent the quest, take a star from the heavens, we could have get ANY ANY IF1 IS $1 silver star COPYOF $ME 8 @temp BITSET @temp 2 COPYFO @temp $ME 8 GET $1 DONE BITTEST This return true if the flag bit number is set. For example following on from the last example we could have quests ANY ANY COPYOF $ME 8 @temp quests ANY ANY MSG {Kill a slug without a fight } BITTEST @temp 0 MSG {Completed} quests ANY ANY MESSAGE { } MSG {Recover the holy silver cross } BITTEST @temp 1 MSG {Completed} quests ANY ANY MESSAGE { } MSG {Take a star from the heavens} BITTEST @temp 2 MSG {Completed} | | and so on Typical ouput could be >quests Kill a slug without a fight Completed Recover the holy silver cross Completed Take a star from the heavens Completed As well as flags used by the interpreter, objects and players have 16 flags into which values can be stored. For objects these can hold for example, it's value, or it's effectiveness as a weapon or how much strength it adds on when eaten. For players t ese could be used for storing their quest situation or which guild they are in, for example, 0 for adventurer, 1 for mage, 2 for dark priest and so on. These are written to and read from by COPYOF COPYFO Item = name of item Number = number of flag (0-15) Flag = Name of interpreter flag to store the value in ANY ANY ANY COPYOF $ME 15 @temp EQ @temp 2 MESSAGE {Dark Priest} join mage ANY LET @temp 1 COPYFO @temp $ME 15 DONE To return to a previous topic, as already stated each player, object, container and room has a set of binary flags avilable to it. These are set and unset with the following commands :- PSET PCLEAR OSET OCLEAR RSET RCLEAR CSET CCLEAR Remember that, although if the item is of the appropriate type nothing will happen, it is a good idea to do type checking. A couple of examples of usage :- cure ANY ANY IF1 ISPLAYER $1 PCLEAR $1 crippled DONE paralyse ANY ANY IF1 ISPLAYER $1 PSET $1 crippled DONE There are also some ways of testing certain conditions pertaining to the current $ME IFDEAF IFBLIND CANSEE Trivial IFDEAF and IFBLIND are true if the current $ME is deaf of blind respectivley. CANSEE returns true if the current $ME can see it. They could be carrying it, it could be in the same location, or indeed somebody else in the same location may be ca rying it. look ANY ANY IFBLIND MESSAGE {you can't see.} DONE ANY ANY ANY IFDEAF SETME $AC MESSAGE {He can't hear you!} DONE [A daemon action. Daemon actions are covered later.] IS This is true if item1 is item2. Sound stupid? Well remember items can be $ME, $AC, $1, $2 among other things. drop ANY ANY IF1 IS $1 huge runesword MESSAGE {The runesword refuses to leave your hand.} DONE ISCALLED True is the name of item is the same as the text. Mainly used by the controllers of the game to give themselves special powers. ANY ANY ANY ISCALLED $ME {Lager} PLACE lager's pint $ME CHANCE Has a number in 100 chance of being true, i.e. CHANCE 50 has a 50 in 100 (or 1 in 2) chance of being true. ANY ANY ANY CHANCE 70 PLACE $ME seadog inn ANY ANY ANY PLACE $ME hatchet inn CHANCELEV For every level the current $ME has, CHANCELEV has a number in 100 chance of being true. For example say $ME is level 8 and the line is CHANCELEV 5, then it has an (8*5)=40 in 100 chance of being true. The interpreter has a lot of very powerful commands for dealing with exits. For speed reasons (I assume!) it stores directions as numbers, translating as and when required into n, s, e, w etc. It stores them according to this system :- 0 - North 1 - East 2 - South 3 - West 4 - Up 5 - Down 6 - Northeast 7 - Southeast 8 - Northwest 9 - Southwest 10 - In 11 - Out MOVE Move attempts to move in the direction indicated by the value in flag. Move is very clever. It knows when a move isn't possible, be it because of a locked or closed door or simply an exit not existing. For whatever reason it understands and sends an ap ropriate error message to the user. east ANY ANY LET @temp 1 MOVE @temp DONE up ANY ANY LET @temp 4 MOVE @temp DONE EXITS EXITS displays all possible exits from the item. If the item is not a room then none will be displayed. Archwizards are shown more information. exits ANY ANY EXITS $RM DONE WHERETO This stores the name of the location, reached by going in the direction indicated by no. from item, in either $1 if itemval is 1 or $2 if itemval is 2. north ANY ANY WHERETO $RM 0 1 IF1 IS $1 creators grove MESSAGE {A magical force prevents you from entering the room.} DONE Note that in the above example IF1 is used. This is because if there is no exit north a null string will be stored in $1, which will cause unecessary error messages whenever $1 is tested. CANGOTO This is true if there is an exit from the players current location to the item in question. Flag is loaded with the appropriate number for MOVE moveto ANY ANY IF1 CANGOTO $1 @temp MOVE @temp DONE CANGOBY Similar to CANGOTO. CANGOBY is true if it is possible to move from the current location to the location containing the item. Flag is loaded with the value for the appropriate move. find ANY ANY IF1 NOT PRESENT $1 CANGOBY $1 @temp MOVE @temp DONE DOOREXIT This action scans through all the exits of item1 looking for an exit through door item2. If none exists then flag is set to 255. If an exit does exist then flag is set to the number appropriate for move. *EXAMPLE TO FOLLOW* PEXIT I've found no real use for this command as printing using EXITS is very easy. Anyway PEXIT prints the name of the exit from $RM in the direction number. SETEXIT SETEXIT sets an exit from item1 to item2 in the direction denoted by number. move ANY ANY IF1 IS $1 nig stone STATE $1 1 AT barren mound SETSTATE $1 0 SETEXIT barren mound 5 huge tomb DONE In this case if a stone is moved at the barren mound an exit down is created to the huge tomb. DELEXIT DELEXIT deletes the exit from item in the direction denoted by number. Note that this only deletes the exit in one direction, i.e. if the exit is two way the player can still go in the opposite direction. move ANY ANY IF1 IS $1 big stone STATE $1 0 AT barren mound SETSTATE $1 1 DELEXIT barren mound 5 DONE Now if the stone is moved back the exit is cut once more GETEXIT *Don't understand the difference between this and WHERETO, remind me to find out. OK you're reminded.* Messages Thus far we have looked at a great deal of commands, many of which e.g. GET, MOVE inform users in the relevant locations of the actions which occur. However sometimes we wish to create our own actions and also describe the action to the appropraite peo le, and inform the person initiating the action what it's effect is. We have a huge number of commands to deal with these situations. DOESACTION It informs all other players in the locations that the item did whatever the message says. An example will make it clearer, but first an explanation of what the number is. The number is the total represented by who should be informed :- 1 - Report that 'Someone' carried out the action if they can't be seen, if it is dark or they are invisible for example. Without this set the action won't be seen. 2 - The action is noise based, therefore anybody who is deaf won't be informed. 4 - Only users who are present will be informed of the action. This prevents DOESACTION informing mobiles etc. Should almost always be included with DOESACTION. Number is simply the total of all these flags. cry ANY ANY DOESACTION $ME {breaks down in tears.} 7 DONE bounce ANY ANY DOESACTION $ME {bounces around.} 4 DONE DOESTOPLAYER Same as DOESACTION, except the action is targetted at another player (item 2 ). It supports an extra flag :- 8 - Report action to item 2 even if item 2 is unaware of item 1, i.e. in a totally different location. The output is formatted to item2 as . Note also in this case that 4 doesn't necessarily have to be included, as demonstrated in this example. poison ANY ANY IF1 ISPLAYER $1 DOESACTION $ME {chants a poison spell} 5 DOESTOPLAYER $ME {poisons} $1 9 PROCESS poisons DONE kick ANY ANY IF1 ISPLAYER $1 DOESTOPLAYER $ME {kicks} $1 5 DONE DOESTO Does the same job as DOESTOPLAYER except the output to item2 won't be formatted in the same neat way. Designed for when item2 is not a player. Also supports flag 8. pull ANY ANY IF1 IS $1 ivory lever DOESTO $ME {pulls} $1 5 Process pulllever DONE The thing about DOESACTION and DOESTO is that they don't report anything back to the initiator of the action. To cope with this there are a number of commands to report back with. MESSAGE Prints the text on the current player's ($ME) screen. A new line is added at the end. pull ANY ANY IF1 IS $1 ivory lever DOESTO $ME {pulls} $1 5 MESSAGE {The lever springs back into place.} PROCESS Pulllever DONE MSG The only difference between MSG and MESSAGE is that a new line is not added to the end of MSG's text. We shall see an example next. PRINT Prints the value stored in flag on $ME's screen. A new line is not added. score ANY ANY GETSCORE $ME @temp MSG {Your score is } PRINT @temp MESSAGE { } DONE The output seen on the users screen would be (assume a score of 6300) >score Your score is 6300 > MESSAGETO MSGTO Behave in the same way as MESSAGE and MSG, only instead of the output being sent to $ME it is sent to item. cure ANY ANY IF1 ISPLAYER $1 MESSAGETO $1 {You have been magically cured.} DONE PCNAME Prints the name of the item on the current users ($ME) screen. The first letter of the name of the item is printed as a capital. kiss ANY ANY IF1 IS $1 golden dragon MESSAGE {You kiss the dragon.} PFLAG $ME female PCNAME $1 MESSAGE { kisses you back.} DONE The output would be >kiss dragon You kiss the dragon. The golden dragon kisses you back. > PNAME Again prints the name of the item, however the first letter in this case is not printed as a capital. kiss ANY ANY IF1 ISPLAYER $1 MSG {You kiss } PNAME $1 MESSAGE { } DOESTOPLAYER $ME {kisses } $1 5 DONE The output as seen by $ME would be >kiss cunegonde You kiss cunegonde > As seen by cunegonde > kisses you. POBJ Prints the object description for the item in state . Note that the object doesn't necessarily have to be in that state. If the item is not an object nothing happens. Bearing in mind state 3 is by convention the examine state, we could have ex ANY ANY IF1 POBJ $1 3 DONE Output if item is a player :- >ex cunegonde > Output if item is an object :- >ex gold casket A very heavy, solid gold casket. It is locked by a padlock. > PLOC If the number is zero PLOC prints the short description of the room item. If no. is non-zero then the long description of room item is printed. If item is not a room nothing happens. east ANY ANY LET @temp 1 MOVE @temp east ANY ANY PFLAG $ME brief PLOC $rm 0 DONE east ANY ANY PLOC $RM 1 DONE DESC This describes the current room ($RM) to the current player ($ME). It describes all the objects in the room. Also during any call to this there are two tables (normally called prelook and postlook) which are called, prelook before doing DESC, postlook fterwards. look ANY ANY DESC DONE In addition to messages, it is also possible to change the messages both users and mobiles exhibit whilst entering, leaving or standing in a location. SETIN This changes the players arrival message. The standard is arrives. setin ANY ANY SETIN {$} DONE If the command entered was, setin storms in, then any players in the arrival location would see, storms in, when the character arrived. SETOUT This changes the exit text. Note that the format of this is . The default is, for example, cunegonde goes west. setout ANY ANY SETOUT {$} DONE An example would be if cunegonde typed, setout floats, then characters in any location that cunegonde left would see, for example, cunegonde floats west. SETHERE Sets the text that anybody who is in the same location of the character will see if they do a look. The default is is here, e.g. wintermute is here. sethere ANY ANY SETHERE {$} DONE So if for example wintermute typed sethere stands before you looking hungover, then anybody in the same location doing a look would see, wintermute stands before you looking hungover. GETIN GETOUT GETHERE These commands load the appropriate message, i.e. either entry, exit or here, into {$}. For example if you wished to have a review command that printed the players in, out and here messages then this is how it could be done- review ANY ANY MSG {Name : } PCNAME $ME MESSAGE { } MSG {In : } GETIN $ME MESSAGE {$} MSG {Out : } GETOUT $ME MESSAGE {$} MSG {Here : } GETHERE $ME MESSAGE {$} DONE Typical output would be >review Name : Wintermute In : stumbles in smelling of puke Out : falls over and crawls Here : stands before you looking hungover > For completeness PROMPT This sets the users prompt to be text. setprompt ANY ANY PROMPT {$} DONE >setprompt ----> ----> Something which hasn't been touched upon is classflags. Anything can be given a classflag. Take a boat for example. To work correctly a boat should really be a room, a container and an object. However to simplyfy matters we could make different objects which have the same characteristics, members of a class. Classes are listed by listclasses. SETCLASS Makes item a member of the class. Note that there is a similar command which is not interpreted which is normally used. UNSETCLASS Stops item being a member of a class. bend ANY ANY IF1 IS $1 silver key UNSETCLASS $1 key DONE ISCLASS Tests to see whether item is a member of a certain class. east ANY ANY ISAT $RM sandy beach ISCLASS $RM boat DOESACTION $RM {is rowed east} 4 MESSAGE {You row east.} PLACE $RM winding river DESC DONE So far we have assumed that $ME remains unchanged however there are a number of ways this can change, both directly and indirectly. There are bits in the table where you wish to change $ME to another object and others where you might wish to change int another object. First however- ISME True if the item is the current $ME fireball ANY ANY IF1 ISME $1 MESSAGE {Quit is easier than suicide.} DONE SETME This changes $ME so that it is item. This is useful if you wish some action which you do to set off a reaction which has an effect on everyone else. force ANY ANY LEVEL 16 WHATO 1 SETME $1 PARSE {$2} DONE BECOME The current $ME is logged off and becomes the item. From then on the player is the item. There is no way to return to their 'old' body. become ANY ANY ARCH IF1 BECOME $1 DONE ALIAS The players old body is placed in a state of 'suspended animation' and they take temporary control of item, relinquished with :- UNALIAS Note that UNALIAS returns you to the original body. For example you are lager, you alias to , say, the gold dragon, then the large axe (which is possible). When UNALIAS is called then the user is returned to being lager. Note that in the example if the gold dragon dies then the player is UNALIAS(ed) automatically. alias ANY ANY ARCH IF1 ALIAS $1 DONE unalias ANY ANY ARCH UNALIAS DONE Of course there are times when all you want to do is watch what something else is doing without being aware of it. SNOOP This echos back everything that appears on item's screen. Remember however that almost all of the informational commands only tell other users what has happened so this is really only useful if the item is a user. snoop ANY ANY ARCH WHATO 1 SNOOP $1 DONE UNSNOOP There is a real problem with this comand. The functionality the coder has built into this command doesn't work properly. A direct quote from Manual.01 :- 'If the number is non-zero unsnoop everything this user is currently snooping on. Otherwise cease snooping on item.' Sorry, nope. If the number is zero then UNSNOOP doesn't work. It is therefore impossible to UNSNOOP just 1 specific item. unsnoop ANY ANY ARCH UNSNOOP 1 $RM DONE In other words, never set number to zero. In the current incarnation of the server code, this feature doesn't work. Now that it has been demonstrated just how powerful some of the things that can be done are, a word of warning about names. SETNAME Changes an items name to be that of text. Bear in mind that I mentioned ISCALLED was generally used to implement things only the controllers could use. One way of stopping lesser wizards from using SETNAME to call themselves the name of one of the cont oller s is to check item is not a user with ISUSER, i.e. setname ANY ANY IF1 ISUSER $1 MESSAGE {No way.} DONE Alternatively my method would be to LOG (mentioned later) every use of this command and to remove privelages from anyone misusing the command. Typical use though setname ANY ANY IF1 SETNAME $1 {$2} DONE >setname zombie a zombie Would change The zombie is here. To A zombie is here. ARCH Following on from the previous warning. ARCH checks the name of the player against the names of the five defined archwizards (defined in System.h as BOSS1 up to BOSS5). It is true if the name of the current $ME matches one. SET1 This sets $1 or $2 (depends on whether itemval is 1 or 2) to be the specified item. ANY ANY ANY ISAT $ME light chainmail OFLAG light chainmail worn SET1 2 light chainmail PROCESS Armourworn We sometimes wish to find out what a player or object is carrying. There are a number of commands to deal with this. INVEN This displays the current players inventory (i.e. what they are carrying) on their screen is a format which anybody who has played an Abermud will be instantly familiar with. i ANY ANY INVEN DONE >i You are carrying the large axe, the ice pick and the rubies. > LISTOBJ This displays the contents of item in a similar format to that of INVEN look ANY ANY PREP in IF1 ISCLASS $1 container LISTOBJ $1 DONE >look in sack The musty sack contains the iron rations and the veal. > LISTAT This command does the same thing as LISTOBJ however each object is listed on a line of it's own and the full text description is used. look ANY ANY PREP in IF1 ISCLASS $1 container LISTAT $1 DONE >look in sack The musty sack :- Some iron rations are lying here. A sharp axe lies on the ground here. A tasty piece of veal lies here. > Duplicating DUP Although DUP is one command there are actually two ways of using it. The differenece depends on which value number is given. Basically item is duplicated and either $1 or $2 assigned to the duplicate depending on whether itemval is 1 or 2. However if the number is 1 it is a permanent duplicate, it retains no information on how it was created. It is then treated like any othe item in the game. DESTROY only moves it to the void, it does not destroy it completely. However if the number is 0 it is a temporary duplicate. DESTROY obliterates it. Also if the universe is saved, any temporary duplicates are destroyed before saving. Finally it reatins all the information needed for the following two commands to work DUPOF This is true if item1 is a temporary duplicate of item2. It is not however true if item1 was created by initiating a DUP of item2 with number set to 1. MASTEROF This sets $1 or $2 to be the thing from which item was temporarily DUP(licated) from. If the item was not duplicated in this way then $1 or $2 is set to no item. xerox ANY ANY IF1 DUP $1 1 2 DONE produce flame ANY IF1 DUP small flame 0 2 PLACE $2 $ME WHEN 20 enddone DONE Item Flags As well as everything else which is used for storing data, objects can have up to 8 item flags associated with them. Item flags are storage spaces where the names of other items can be stored. Although their use is not immediately apparent they can be sed to store the name of the current wielded weapon, the name of the person that you are fighting with etc. For example if somebody tries to move then you can check the appropriate item flag and if it is non-empty then the player then the player is in fight so you may not wish him to move. Note that item flags are numbered 0-7. SETIFLAG Stores the name of item2 in the appropriate item flag (denoted by number) of item1. wield ANY ANY IF1 CARRIED $1 COPYOF $1 1 @temp NOTZERO @temp SETIFLAG $ME 2 $1 GETIFLAG This gets whatever is in the appropriate item flag (i.e. item flag number from item) and store it in $1 or $2. Remember item flags can be empty so $1 or $2 should be tested before use with IF1 or IF2. i ANY ANY INVEN GETIFLAG $ME 2 1 i ANY ANY NOT IF1 MESSAGE {You are wielding nothing.} DONE i ANY ANY MSG {You are wielding } PNAME $1 MESSAGE {.} DONE CLEARIFLAG This clears item's appropriate item flag. As well as item flags, players (both mobiles and users) have 8 (numbered 0-7) slots in which text can be stored. For example if giving the player a customized title was desired it could be stored in one of the text spaces. SETUT SETUT stores the text in item's user text slot number. settitle ANY ANY SETUT $ME 2 {$} As an example say Lager enters >settitle the Dark Lagerlord GETUT This stakes the text stored in item's user text slot number and stores it in $ sc ANY ANY MSG {You are known as } PCNAME $ME GETUT $ME 2 MESSAGE {$} Then following on from the previous example, we have >sc You are known as Lager the Dark Lagerlord Killing and Hurting Obviously for a heavily combat based MUD which most of the Abermuds are we need some commands for hurting things. END Sends the text to the current player and then kicks them off the game. No points are lost by the player, however obviously all items the player is carrying are lost. byebye ANY ANY LEVEL 16 WHATO 1 ISUSER $1 SETME $1 END {Somebody doesn't want you here anymore.} DONE KILLOFF END is just an annoyance however compared to KILLOFF. As well as kicking the current player off the game, it wipes out their character as well. Alternatively if PANSY_MODE is defined at compile time then the character is not wiped out, but the score is halved. zap ANY ANY LEVEL 16 WHATO 1 ISUSER $1 SETME $1 KILLOFF {You are struck by a lightning bolt.} DONE HURT Reduces the current player's strength by number. If the strength drops below 0 then the player is killed and is logged out and their character is deleted (or score is halved if PANSY_MODE is defined) For an example on the use of HURT see the section on DAEMON actions, since HURT is usually used inside a DAEMON. CURE The opposite of hurt in that it adds number to the current player's strength. In this example a table is called every 30 seconds. ANY ANY ANY CURE 1 PROCESS Maxstr Here it automatically adds 1 to a players strength every 30 seconds then checks the maximum strength hasn't been exceeded. Room Descriptions Although we have already seen DESC earlier there are some other commands which deal with room description. It is important to remember that there are two different room descriptions, long and short. Finally these won't be covered in great depth as I ha en't yet found an example where they are used. GETLONG GETSHORT Both of these work in the same way. GETLONG copies the long description of item into $. GETSHORT does the same with the short description. If the item isn't a room nothing happens. Similarly there are two commands which perform similar actions for objects. Again I haven't really seen an example of use, with one exception we will see. GETDESC GETNAME GETDESC copies the description of the item when it is in the state number into $. There is actually a use for this. As noted state 3 is by convention used for examination text :- ex ANY ANY IF1 GETDESC $1 3 MESSAGE {$} DONE GETNAME copies the name of the item into $. Note that this can be used on players, objects or rooms. As we will see although PNAME and PCNAME are used for printing names, GETNAME can be used for printing names, GETNAME can be used for storing informati n in the system log. Note also GETDESC can only be used on objects. If the item isn't an object then nothing happens. Parents and Children It is useful occasionally to understand the concept of parents and children. Anything which is contained within an item (be it room, container or player) is considered to be a child of the item. Therefore the thing containing the item is said to be the parent of the item. A sack containing say, veal, rations and a key will be the parent of all three items. Note also that any items carried by players are considered to be contained within the item. GETPARENT Get the item which is the parent of item and store it in $1 or $2 dependant on whether itemval is 1 or 2. This should always be checked before use as an item could have no parent {It could be a room for example). An example of use of this could be:- summon ANY ANY WHATO 1 IF1 GETPARENT $1 2 IF2 RFLAG $2 NoSummon MESSAGE {You can't summon from there.} DONE GETCHILDREN This action takes the first child of item and stores it in either $1 or $2 depending on itemval. Note that item may have no children so this action should always be tested with IF1 or IF2. GETNEXT After the use of GETCHILDREN, GETNEXT stores the next child in either $1 or $2. Another call to GETNEXT stores the next child and so..... (can't think of a decent example) FINDMASTER NEXTMASTER LATER FINDIN NEXTIN Daemon Actions Possibly one of the hardest, but most important aspects of learning how to code the Abermud interpreter is understanding DAEMON actions. The most important thing to note is that all DAEMON actions are written in table 2, which is usually called DAEMON. However a DAEMON action can be called from any table. You could even (heaven forbid) call a DAEMON action from within the DAEMON table. To start with we have the ordinary DAEMON action:- DAEMON The events which occur are as follows. The item becomes $ME. The $ME at the time of the DAEMON call becomes $AC, $1 and $2 are unchanged. $RM becomes the room which $ME is in. And the two text strings $ and $2 are unchanged. Let us consider an example - kill ANY ANY IF1 ISPLAYER $1 DAEMON $1 smash start ANY The following is typical code in the DAEMON table smash ANY ANY SETIFLAG $ME 1 $AC WHEN 2 COMBAT smash ANY ANY SETIFLAG $AC 1 $ME SETME $AC WHEN 2 Combat Basically what happens is that the name of the opponent is stored in one of the item flags (in this case 1) and then the combat table is invoked. The basic daemon action is like a call to another table, albeit with an extra item to handle, namely $AC. It should be obvious that in the main most situations could be handled without the basic DAEMON action, however the ease of use and neatness of code do make it useful. However the beauty of DAEMON actions is that they can be used on a number of items at the same time if they meet certain conditions. ALLDAEMON Note the lack of an item field. This is because the DAEMON action is carried out on all players in the games. i.e. The first player in sequence becomes $ME when the DAEMON action is called, then the second and so on. Note that only users of the game ar included. It would take far too long to process if mobiles were included. This has many uses. A shout command and a who command are just two examples. shout ANY ANY ALLDAEMON shout ANY ANY OK DONE In the DAEMON table shout ANY ANY IS $ME $AC DONE shout ANY ANY GETPARENT $ME 1 GETPARENT $AC 2 IF1 IF2 IS $1 $2 PCNAME $AC MSG { shouts } MESSAGE {$} done shout ANY ANY MSG {Somebody shouts } MESSAGE {$} DONE Note : Every user on the game is processed in the ALLDAEMON action, even the initiator of the ALLDAEMON action. The second line ensures that anybody in the same room as the shouter is told who is shouting. Everybody else sees 'Somebody shouts '. HDAEMON HDAEMON performs a DAEMON action on everything directly contained within the item. Note that everything is dealt with, objects, players, containers etc. Note also that it is only things directly inside item. If, for example, an object is inside a conta ner which is inside a room then it won't be dealt with. say ANY ANY HDAEMON $RM say ANY ANY OK Daemon Table say ANY ANY IS $ME $AC DONE say ANY ANY NOT ISPLAYER $ME DONE say ANY ANY PCNAME $AC MSG { says } MSG {$} MESSAGE {.} DONE TREEDAEMON Similar to HDAEMON. The only difference is that objects inside containers, say, are processed. The DAEMON action is performed on everything which is contained in item to any depth. *Can't think of a suitable example.* CHAINDAEMON A DAEMON action is performed on item and anything chained to item. I've yet to come across an instance where this has been used. CDAEMON Virtually the same as HDAEMON, except the action is only performed on users. i.e. objects, mobiles etc within item are ignored. Say could be rewritten using CDAEMON. The only difference it would make would be if a wizard was aliased to a mobile for exa ple they wouldn't see any of the says. Tables In the processing of the command table it is sometimes necessary to call other sections of code in the form of other tables. In fact in one particular case it i s vital to call another table. This is in the case of a death causing action, of which more ater. PROCESS
In this case processing of the current table is suspended the tablename is processed. After this has been processed then processing resumes with the command after the PROCESS. $ME, $1, $2, $RM etc are unchanged. Basically most things that are put in ot er tables could be written without PROCESS but it makes code more manageable. Also if, for example, certain conditions are met then certain actions occur then the use of PROCESS means that these conditions wouldn't have to be checked on every line of t e table. WHEN
With this command the table is processed in approximately number seconds. Although WHEN 0 can be used the table isn't processed immediately but is queued to be processed as soon as possible after the current processing is finished. As before $ME, $RM, 1, $2 etc are unchanged. This command is vital for death causing actions. Using HURT to kill off something during the processing of the main command table can cause the game to crash or do nasty things. To circumvent this, typically code like this woul be used. Assume we wish to remove 10 str from $ME using HURT ANY ANY ANY GETSTR $ME @temp LT @temp 10 WHEN 0 Death DONE ANY ANY ANY HURT 10 DONE WHEN is used in a great many other situations. Moving mobiles around for example. A typical example :- (*) ANY ANY ANY SETME ANY zombie WHEN 5 MoveMobile MoveMobile would have another WHEN 5 MoveMobile call in it after the movement to enable the mobile to move again, and so on. One final point about tables. There are a number of tables which are called automatically. Table 1 is the initialisation table which is run first of all, indeed (*) would probably be included in it. Table 0 is always the main command table, table 2 con ains all DAEMON actions. Table 100 (?) is run whenever a new player logs on, table 101 (?) is run whenever an existing player logs on. The tables usually called prelook and postlook are run before and after the desc call. DOCLASS Although not a table command it is good practice to include DOCLASSes in their own individual table. DOCLASSes are extremely complicated. The classflag option can be zero or a specific class can be processed. What happens is that everything which is co tained within item which has the appropriate classflag set (or all items if 1 is used) is in turn loaded into $1 or $2 depending on itemval. This is then processed according to these rules. Processing continues on the table which contains the DOCLASS u til a DONE is encountered. Once this occurs $1 or $2 is loaded with ther next item and processing is begun again from the line following the DOCLASS. There are a couple of important rules. You cannot have a DOCLASS within a DOCLASS in the same table. That is to say the following code would not be allowed. example ANY ANY DOCLASS $RM 0 1 example ANY ANY -------------- -------------------------- example ANY ANY DOCLASS $1 alight 2 However if the second DOCLASS was in a different table then this is permitted. So this would be allowed. Table 1 example ANY ANY DOCLASS $RM 0 1 example ANY ANY --------------------- --------------------------------- example ANY ANY PROCESS SecondDoClass SecondDoClass ANY ANY ANY DOCLASS $1 alight 2 | | | The other important point to mention about DOCLASS is that processing stops if an item is moved from the item in the course of execution. This is quite unusual but Alan Cox says in Manual.01 :' This is an unusual situation and since avoiding this would cause a significant slowdown, it was felt best to leave it as it was.' Graphics and client support The server has uses three ports. Assuming TCP_PORT is at the default 5000, they are as follows:- 5000 Normal player connection port. 5001 Client support, for the client used in DickMUD and AberMUD. 5002 BSX Client support. However, the client that is provided with this source has yet to compile for me. So I have no way of testing this. I have only once tested the BSX client support. Of course it worked. To understand these extensions you will have to experiment yourself, read the source and try things out. Appendix A: Interpreter Reference This is a complete reference of the database conditions and actions. It lists each action along with its argu- ments, effect, and failure modes. The argument types are Table The name or number of another database table. Item An item argument takes the value of any item within the game, or of $1 or $2, which are used to indicate the items the player is referring to. Note that some actions change $1 or $2. Actions that do this are clearly marked. In addition to these the values $ME the current player, $AC the initiator of any current daemon driven action, and $RM the location of the current player are available for use. Number The action takes a numeric argument. Num- bers are ranged from -29999 up to 29999, or the name of a flag may be used to indi- cate the value held within that flag is to be used. You can also use the value of a flag although not directly. You must specify the flag as F where number is the number of the flag. See Listflags. Text The action takes a text string delimited by the characters '{' and '}'. Two special strings are available: {$} and {$2} corre- sponding to the user input after the verb, and the user input after the first noun respectively. Word The action takes a word as an argument. When a paticular type of word is required it will be listed as verb, adjective or noun. Class The action takes a class as an argument. The classes used are the class flags which each item posesses and are altered with setclass and unsetclass. The value 0 is also legal and means all items. ItemVal The action takes a value of 1 or 2 as its argument and will load either $1 or $2 with some value as a result of its actions. ClassFlag One of pflag, oflag, cflag, rflag. This is used to indicate a class dependant flag name. Interpreter Action List (Now sorted alphabetically) ABORT Abort the game server instantly. All users are kicked off and the program exits without saving any game world changes. ABSENT The reverse of the present condition. ADD Add number to the value of flag and store the result back in flag. As with all the maths functions no range checking is performed. ADDF Add the value in flag1 to the value in flag2 and store the result back in flag1. ADJ1 True if the first user entered adjective is the given word or a synonym ADJ2 True if the second user entered adjective is the given word or a synonym ALIAS The player gains control over another item, and observes and controls everything it does. For the duration of the aliasing the item is truely the user, and the users old body just sits where it was without a controller. When the player is unaliased or the aliased item dies control returns to the old body. Aliases do not stack, aliasing when aliased and then unaliasing puts you back to the real original user. ALLDAEMON As a daemon except that it is applied to all users on the game system. For speed reasons only user objects are pro- cessed. ARCH True if the player is an ArchWizard. Compiled in the game as one of the BOSS names. Creation commands are compiled in to check for this. AT This action is true if the current player is directly con- tained in the item specified. AUTOVERB When AUTOVERB is set the verb is automatically prepended to any user input that does not begin with a '*' charac- ter. This is ideal for things like converse mode. To can- cel it use AUTOVERB NONE. BECOME The current player is logged out and the user is placed back at the game login prompt. BITCLEAR Clear bit number of the flag. BITSET Set bit number of the flag BITTEST True if bit number of flag is set. BROADCAST Broadcast a text message to everyone on the game. The num- ber value is flags in the same form as DOESACTION. However all the formatting rules about Someone/Name do not apply as no names are added to the text message. It is far better to implement this using the DAEMON table. BSXOBJECT Add a BSX object to the current scene. The object must be present in the table of known BSX images. Number1 is the position and number2 is the depth of the image. Note that object support in the AberMUD 5.23 BSX is not yet com- plete. BSXSCENE Display the requested BSX scene. The scene must be present in the table of BSX images known to the game system. BUG Add a bug report to the system log. CANGOBY As CANGOTO except that this action searches for a move which places you in the same location as item. CANGOTO Tests to see if it is possible for the current item to move to item. If it is possible (ie there is an exit from the current location), then flag is loaded with the direc- tion number for MOVE. CANPUTIN Checks to see if item1 can be placed in item2. It checks to see that container sizes are not breached and that player carrying limits are enforced. The assumption is made that either item1 contains item2 or vice versa. In other cases because this action evaluates more simply than is ideal - for speed - it may allow a container to become over 100% full when another soft container is within it and an item is placed into the soft container from outside of either container. CANSEE True if the current player can perceive item after due consideration of darkness blindness and invisibility rules. CARRIED True if the item is directly contained within the current player. Items that are worn are also counted as carried. CAT The three strings text1, text2, and text3 are concatenated and placed in {$}. The total length must be 512 bytes or less. CCLEAR Clear a container flag on a container item. This has no effect on items that do not have the container class. CDAEMON Send a DAEMON to every user contained within item. CFLAG True if a container item has this container flag set. Non container items never have any container flags set. CHAINDAEMON Perform a DAEMON action (see above) on each item which is chained (with the chain class and command) to this item. CHANCE This action has a number in 100 (ie a percentage) chance of being true. CHANCELEV This condition has a number in 100 chance of being true for each level the player has. Non player items are always level 0. CLASSAT This condition is true if at least one of items direct contents is a member of class. CLEAR Set the value of flag to 0. CLEARIFLAG Set item flag number of item to indicate no item at all. CLS Clear the display. This may or may not do something. COMMAND Change the input that is being processed to match the given words and items. The adjective noun pairs are taken from the items. COMMENT A comment in the database. The comment is ignored at run time. COMVOCAB Change the input that is being processed to match the sup- plied set of words. COPYFF The value in flag1 is placed into flag2. COPYFO Copy the value of flag into user flag number of item. If neccessary the user flag properties will be created for the item. Number ranges from 0-15. COPYOF Extract user flag number from item and store its value in flag. If this flag has not yet been used it will return 0. Number can be from 0-15. CREATE The item is moved to the location containing the player. No messages are displayed. No checks are made to see if the item will fit in its new location. CSET Set a container flag on a container item. This has no effect on items that do not have the container class. CURED The players strength is increased by number. DAEMON The daemon tables for item are invoked in scanning order with verbs and nouns set to the argument. For the duration of the daemon $1, $2 and the previous vocabulary and DOCLASS loops are saved. During the daemon executing $ME is set to item, and $AC to the $ME at the point of daemon invocation. DEBUG Set the debugging level. Level 1 logs every line executed and level 2 logs statement by statement as the interpreter runs. Level 2 is only intended for debugging the game server. DEC Decrement (subtract 1 from) the state of an item. If the state is already 0 nothing happens. DELETE Delete the specified file. If the security define is set this action is forbidden. If the delete files the action returns false. DELEXIT Delete the exit in direction number from item. Number is an exit in the same form as MOVE. DESC Describe the location of the current player including objects, and trapping out to the user control tables called during a room description. DESTROY The item in question is moved to the void. If the item was a temporary clone and has no other references it will be physically destroyed and removed from the system. The destroyed flag is also set for backwards compatibility. DIR Obsolete. DIV Divides the value of flag by number. If you attempt a division by zero the message DIVF Divides the value of flag1 by the value of flag2. If you attempt a division by zero the message DOCLASS This action is used to scan for a set of things within item. If classflag is anything other than 0 only the items with the given class flags are processed. When the action occurs either $1 or $2 as appropriate is set to the first matching item (or nothing if no item matches) and the next statement then executed. From then onwards each time a DONE occurs within that table processing resumes from the line after the line con- taining the DOCLASS action with $1 or $2 set to the next item matching. There are two limits to DOCLASS. You cannot nest doclass requests within a table. Requests in different tables are fine. Thus if inside of a doclass you call a table that does a doclass no harm will occur. The second is that if the action inside of the doclass loop moves the next item in the list of contents of the room containing it to another location the DOCLASS loop will stop at that point without processing further items. This is an unusual situ- ation and since avoiding this would cause a significant slow down it was felt best to leave it as it was. DOESACTION Inform those present that item has performed an action. The way the action is reported, and who is informed is controlled by number which is a set of flags added together as follows. 1 Report that 'Someone' carried out an action if they cannot be seen (for example it is dark). Without this flag set the action will just not be seen. 2 The item is noise based. Deaf people are not informed. 4 Only users who are present will be notified of the event. This action although commonly used by players is very use- ful for inanimate objects too as it saves checking to see who is present and what they can see every time an event occurs. For things like a striking clock DOESACTION is ideal. DOESTO This works in the same way as DOESACTION but the event is targetted at a second item. It supports an extra flag value of 8 which means report the event to the target (item2) even if item2 is not aware of the source, using DOESTOPLAYER Identical to DOESTO except that the output is formatted as when it is reported to item2. DONE Terminate all further consideration of this action and return to the previous table, or if a doclass is in force move onto the next item. If used on CondExits it means that the exit is there. DOOREXIT Scans through all the exits from item1 looking for one which leads via door item2. The direction of this is stored in flag. If one does not exist the flag is set to 255. This action is ideal for handling commands like 'go through the big door'. DROP Drop an item. The item must be carried by the player. It is placed in the location of the player and anyone in that location informed as appopriate. If the item is not car- ried by the player a suitable message is displayed. DUP Item is copied and either $1 or $2 is assigned to it, depending upon itemval. If number is 0 the item will cease to exist next database save or when a DESTROY action is used upon it. If it is 1 the item is a permanent copy. So please do not use permanent copies. DUPOF True if item1 is a duplicate of item2 that was created by the DUP action. Only temporary duplicates remember this information. END Display a message and remove the current player from the game. Using this on a non-user has no effect. This func- tion must not be called inside of the room describe call out tables or the game entry tables. Instead use 'WHEN 0 table-name' to queue up the end. EQ True if flag contains the value number. EQF True if flag1 and flag2 contain the same value. EXITS Display the exits from item. Archwizards get more informa- tion than normal players, and are told where exits lead in full form, and the type of the exit. FIELD Move on to the next X position that is divisible by num- ber. This enables you to lay out tabulated data. FINDIN Loads either $1 or $2 with the first thing in item match- ing the vocabulary words for the either the first or sec- ond user adjective/noun pair. FINDMASTER Loads either $1 or $2 with the first item anywhere in the database matching the vocabulary words for the either the first or second user adjective/noun pair. FLAT Sets {$} to the text for a flag in decimal. FLOAD Load the flags between flag1 and flag2 (inclusive) from a file. If the operation fails the flags are not affected and the condition returns false. Not allowed if SECURE is defined. FORKDUMP Fork off a child of the game server which will exit its users and dump the state of the game world to file . This function is still at a test stage. Does work. -AG FROB Obsolete. FSAVE Save the flags between flag1 and flag2 (inclusive) to file text. If the operation fails the flags are not affected and the condition returns false. Not allowed if SECURE is defined. GET This is one of a small set of actions that perform quite a complex task for user convenience. If you want to tailor the behaviour of your get verb you may well opt not to use this function. The get action checks that the item may be taken and if so takes the item and informs those present what has occured. If the item cannot be taken and a doclass is not in force an error is sent to the player. The things checked are: that the item fits in the player, that it has canget set, and that it is an object. GETCHILDREN Get the first thing contained within item. To walk along this list use GETNEXT after using GETCHILDREN. GETDESC Set {$} to be the description of object item in state num- ber. If it is not an object or number is out range then nothing happens. GETEXIT Copy exit number of item into $1 or $2. If there is no exit it is set to no item. GETHERE Set {$} to be the room description message of a player. GETIFLAG Loads either $1 or $2 with flag number of item. Remember that item flags may be blank in which case $1 or $2 will be set to no item. You should test the result of this action with IF1 or IF2 before using it. GETIN Set {$} to be the room entry message of item. GETLEV Copy the level of a player item into flag. GETLONG Set {$} to be the long description of room item. If it is not a room then nothing happens. GETNAME Sets {$} to the name of item. GETNEXT Set $1 or $2 to be the next item in the list of items con- tained in the location of item. If there are no more then it is set to no item. GETO This works the same way as whato, but looks only at the contents of a specified item. Many verbs look in specific places for their matching items - for example 'take item1 from item2'. This function is intended to help process them. GETOUT Set {$} to be the room exit message of item. GETPARENT Load either $1 or $2 with the thing containing item. If it has no location (it is in the void) then $1 or $2 is set to no item. GETSCORE Copy the score of a player item into flag. GETSHORT Set {$} to be the short description of room item. If it is not a room then nothing happens. GETSTR Copy the strength of a player item into flag. GETSUPER Set either $1 or $2 to be the direct superclass of item. GETUT Items have up to eight user text strings. This function extracts string number from item and places it into {$}. GETVIS Get the visibility (perception) of item and store it in flag. GIVE Give item1 which you must be carrying to player item2 who must be able to carry it. If the conditions are not true a suitable explanation is displayed, if it succeeds the rel- evant people are informed of the action. GOTO Move the player into item. No special checks are done. The location is not described upon arrival, although users in the original and new location of the player are informed of the movement. If you do not wish to inform anyone use PLACE $ME instead. GT True if flag contains a value greater than number. GTF True if flag1 contains a larger value than flag2. HDAEMON As a daemon except that it is applied to all users that are in the same location as item. HURT The players strength is reduced by number points. If it falls below zero the player dies. Because this action can kill the same restrictions on its use apply as to END. Death can either totally delete the player or if PANSY_MODE was defined at server compile time halve their score. Nothing forces the use of HURT, so any other system can be handled by writing your own variant of HURT to han- dle these situations. IF1 True if $1 references an item. IF2 True if $2 references an item. IFBLIND True if the player is blind. IFDARK True if the current location is dark after all light source rules have been computed. IFDEAF True if the player is deaf. This is directly equivalent to testing the deaf flag with PFLAG. INC Increment (add 1 to) the state of an item. If the state is already 3 nothing happens. As with all database state changing actions (but not the driver setstate command), all the items chained also have their state set to the new state of item1. INVEN Display the users inventory. IS True if item1 is item2. This isn't as pointless as it sounds since items can of course be things like $AC, $ME , $1. ISAT This is true if item1 is directly contained within item2. All of the here/present/carried actions can be written using this but are provided seperately for readability and memory saving. ISBY True if item1 and item2 both share the same location. Two items that are both nowhere do not share the same location even though they are effectively in the same place. ISCALLED True if the name of item exactly matches text. This is case dependant. It is of most use for coding things bound to a players name. Remember that a player name has a lead- ing capital. ISCLASS True if item has classflag set. ISIN True if item1 is contained in item2 to any depth. That is unlike the ISAT function this function is true even if there are layers of containers within item2 that contain item1. ISME True if item is the current player (ie $ME). ISNOTAT The reverse of the isat action. ISNOTBY The reverse of the isby condition. ISNOTIN The reverse of the isin action. ISOBJECT True if the item has object properties ISPLAYER True if the item has player properties. ISROOM True if the item has room properties ISUSER True if the item is a user of the game rather than just a game driven object. KILLOFF This action performs identically to the END function except that it totally destroys the character. It is ideal for things like zaps from on high. The restrictions on the use of END apply to this function. LENTEXT Set flag equal to the length in characters of the text string. LET Set the value of flag to be number. LEVEL True if the level property of the current player is at least number. Non players have a level of zero. LISTAT Display a list of the contents of item in long form using the description for the object state, or the here text of a player. Each entry has a line of its own. LISTOBJ Generate an output list of long descriptions of the con- tents of item in a short 'name,name and name.' type for- mat. LOG Write the results of catenating the three strings as a log file entry. A date, time and a few other pieces of system dependent information are written with the record. This is appended to the system log file. LT True if flag contains a value less than number. LTF True if flag1 contains a smaller value than flag2. MASTEROF This sets $1 or $2 to be the thing that item is duplicated from with DUP. If it was not duplicated in this way the value is set to no item. MEANS This sets new verb and noun words for the current input. It does not however alter $1 or $2. Number is obsolete and should be set to 0. MEMBER True if item2 is one of the superclasses of item1. MESSAGE Output a text message on the current players screen (if any). A trailing newline is added. MESSAGETO Output the text followed by newline to item. If item isn't a user then nothing happens. MOBILES Obsolete. MOD Divides the value of flag by number and stores the remain- der in flag. A divison by zero causes an error message to be displayed to the user and logged. MODF Divides the value of flag by number and stores the remain- der in flag. A divison by zero causes an error message to be displayed to the user and logged. MOVE Takes the value of flag and attempts to move in that direction. The directions match the verb number - 100. Move understands exits, conditional exits, message exits, doors, how to describe doors in the dark, what will fit where and how to describe the location if a move succeeds. If the move is not possible a suitable explanation is given. The values are 0 North. 1 East. 2 South. 3 West. 4 Up. 5 Down. 6 NorthEast. 7 SouthEast. 8 NorthWest. 9 SouthWest. 10 In. 11 Out. MSG Output a text message on the current players screen (if any). A trailing newline is not added. MSGTO Output the text to item. If item isn't a user nothing hap- pens. MUL Multiplies the value of flag by number and stores the result back in flag. MULF The contents of flag1 are multiplied by the contents of flag2 and the result is stored in flag1. NARG Obsolete NEEDFIELD Not supported. NEWTEXT Flsuh all the pronouns. NEXTIN Loads either $1 or $2 with the next item in item1 after item2 matching the vocabulary words for the either the first or second user adjective/noun pair. Item2 must not have moved between the last call to NEXTIN or the call to FINDIN and this. NEXTMASTER Loads either $1 or $2 with the next item after item any- where in the database matching the vocabulary words for the either the first or second user adjective/noun pair. NOT Invert the logic of the following condition. Using not before an action makes it always fail (since an action always succeeds). NOTAT This action is true if the current player is not directly contained in the specified item. NOTCARR The reverse of the carried action. NOTDONE Indicate that the event has been processed but could not satisfactorily complete. Superclasses use this to force an event to be handled higher up. The description call out tables use this to indicate various things. If used on CondExits then it means the exit is NOT there. NOTEQ True if flag does not contain the value nunber. NOTEQF True if flag1 and flag2 contain different values. NOTWORN The reverse of the WORN condition. NOTZERO True if flag has a non-zero value. NOUN1 True if the first user entered noun is the given word or a synonym NOUN2 True if the second user entered noun is the given word or a synonym OCLEAR Clear an object flag on an item. If the item is not an object nothing happens. OFLAG True if the item has this object flag set. Non objects are assumed to always have this clear. OSET Set an object flag on an item. If the item is not an object nothing happens. PARSE Suspend current input processing and process text as if it had been input by the current player. After this has pro- cessed continue with the previous vocation. Try to avoid this function. In relative terms it is very very slow. PCLEAR Clears player flag pflag of item. This function has no effect on non player class objects. PCNAME If item is not invisible its name is displayed with the first letter capitalized and the pronouns set to match it. If the item is invisible either Someone or Something is displayed. PEXIT Print the name of an exit. The number matches the numbers for MOVE. PFLAG True if the item has this player flag set. Non players are assumed to always have this clear. PLACE Item1 is placed directly into item2. No checks are made. PLOC If number is zero the short description of room item is displayed, otherwise the long one is. If the item is not a room nothing happens. PNAME If item is not invisible its name is displayed and the pronouns set to match it. If the item is invisible either someone or something is displayed. POBJ Display the object description for item in state number. It the item is not an object nothing happens. The current value of 'it' is updated to reflect this item. POINTS The players score is increased (or if number is negative decreased) by the number of points indicated. PREP True if the user entered preposition is the given word or a synonym PRESENT This is true if the item in question is directly carried (ie directly contained in) the current player, or is in the same place as the current player. In other words if the item is handy. PRINT Display the value of flag on the display of the current player. Unless the current player is a user nothing hap- pens. This is true for all output functions. PROCDAEMON Using the current vocabulary and item values scan the dae- mon table of item, possibly including subclasses. Use this with caution. It is intended to be called from within a daemon. It does no setting of $AC nor the other processing done by the DAEMON actions. PROCESS
Suspend current processing and processes table. Once table is processed continue processing. PROCOBJECT Using the current vocabulary and item values scan the object table of item, possibly including subclasses. PROCSUBJECT Using the current vocabulary and item values scan the sub- ject table of item, possibly including subclasses. PROMPT Set the input prompt of the current player to be the given text string. If the current player is not a user then nothing happens. PRONOUNS Display the current pronouns. PSET Set player flag pflag of item. This function has no effect on non player class objects. PUTBY Item1 is placed in the same location as item2. No messages are displayed and no size or weight checking is done. PUTIN If possible item1 is placed inside item2 and everyone viewing the event is informed. If item2 is not a con- tainer, item2 does not have the canputin flag set, item2 is not closed, item1 will not fit inside item2 or both item1 and item2 are not present the player receives an explanatory error message. PUTO Obsolete call. PWCHANGE This action can only be applied to a user and moves them into password changing mode. After the completion of tables this time the player will be able to change the password. The statements after the PWCHANGE are executed immediately, not after the password changes. RANDOM A random value between 0 and number-1 is stored in flag. Specifying a value of 0 is not permitted and causes an error message. RCLEAR Clear an room flag on an item. If the item is not an room nothing happens. REMOVE Remove an item the player is currently wearing. If the item is not being worn by the player a suitable error mes- sage is displayed. If the item can be removed a message is sent to people present informing them of the event. RESCAN Scan the current table again from the top. This can cause the game to lock up if it loops for ever. If this happens and you want to save the database use the unix kill com- mand to send the server process a SIGFPE, and as part of its crash procedure it will save the current game world as 'gonebang.uni' if possible. RFLAG True if item has the room flag specified set. Non rooms have all these flags assumed to be zero. ROOMS Obsolete. RSET Set an room flag on an item. If the item is not an room nothing happens. RWHODOWN Tell the RWHO server the game is shutting down. RWHOINIT Create an rwho connection and tell the rwho server we are up. The texts are: Game name. Game identity string. IP Address of rwho server. Mudwho server password. RWHOLOGIN Log the user $ME into the RWHO server. The first text string is the short name supplied to the server and must match the RWHOLOGOUT name. The second is a long text of info - eg including a level name. Currently logged in players should call this again every 5 or so minutes to avoid timing out of the rwho server. RWHOLOGOUT Tell the rwho server that the user (name text) has logged out. The user in question must be the current $ME. You may however vary the name so long as it matches the login name. It is common to log people out if they become invis- ible as well as on death, how you work it is up to you. RWHOPING Send an rwho keepalive packet. SAVE Store the current players persona to the user data file. If the save fails this action fails too. SCORE Display the players score in a simple format. This is for compatibility and now obsolete. SET Set the value of flag to 255. SETCLASS Set classflag of item. SETDESC Concatenates the text arguments and assigs the result to the description for state number of item. If the number is invalid or the item is not an object nothing occurs. SETEXIT Set the exit in direction number from item1 to item2. Num- ber is an exit in the same form as MOVE. SETHERE Set the message displayed when the current item is seen within a location description. SETI Set either $1 or $2 to item. SETIFLAG Each item can have up to eight item flags each remembering another item. The SETIFLAG action sets flag number of item1 to contain item2. If number is out of range nothing happens. SETIN Set the message displayed when the current item enters a location. SETLEV Set the level of a player item to the value of flag. SETLONG Set the long description of a room to the catenation of the three text strings. If item is not a room nothing hap- pens. SETME Change the 'current' player - ie $ME - to be item. SETNAME Set the name of item to text. This does not affect the vocabulary of an item so it use it with caution. In addi- tion an item whose text matches one of the archwizard names compiled into the server has the privileges and is that archwizard. Finally never use SETNAME on a user and save them, the save will save the _new_ name and may well destroy the old character. SETOUT Set the message displayed when the current item leaves a location. SETSCORE Set the score of a player item to the value of flag. SETSHORT Set the short description of a room to the catenation of the three text strings. If item is not a room nothing hap- pens. SETSTATE Set the state of item to number. If number is less than zero then zero is used, if it is higher than three then three is used. SETSTR Set the strength of a player item to the value of flag. SETSUPER Set the direct superclass of item1 to be item2. All of the superclasses above that will change to be the superclasses of item2. SETUT Each item can have up to eight user text strings. This function sets string number to the message text. If it is called with an invalid number nothing happens. SHELL The shell function is very powerful but very dangerous. Therefore unless you alter the code all that you can do is use the shell commands cat and date, which are actually emulated by inbuilt database functions. SIZE Set the size of item to number. Either objects or players may have sizes set. It has no effect on other types of item. No checking of maximum weights is done. SNOOP Begin snooping on an item, and seeing exactly what it does. This only works properly if you are snooping on another user. SPRINT Set {$} equal to the decimal string representing flag. Equivalent to FLAT for historical reasons it is now iden- tical. STATE True if the item in question is in state number. States range from 0-3. While it is possible to test against a higher value it is pointless. SUB Subtract number from the value in flag and store the result back in flag. SUBF Subtract the value in flag2 from the value in flag1 and store the result back in flag1. SUBSTR True if text2 is a substring of text1. SWAP Swaps over the location of item1 and item2. No checks on whether the item will fit are made. SWAT Swaps {$} and {$2}. TAKEOUT Providing item1 is inside of item2, item2 is present and item1 can be taken (has canget set and can be carried by the player), it will be moved to the player and people observing the event will be informed. If it cannot be accomplished a suitable explanation will be displayed for the player. TREEDAEMON Caue a DAEMON action (see above) to occur to any user who is contained within or is in fact item. They need not be contained directly. TYPO Add a typo record to the system log. ULOAD Load the first 4 strings and the first 8 userflags of item from the file text. If this fails it returns false. A failure disturbs none of the current values. Not allowed if SECURE is defined. UNALIAS Cease being aliased and return to being the original user. UNSETCLASS Clear classflag of item. UNSNOOP If number is non-zero unsnoop everything this user is cur- rently snooping on. Otherwise cease snooping on item. UNVEIL This expects the {$} string to contain eight comma seper- ated hex numbers, which are computer against number which is a key. Writing a program that computes keys and hex numbers is left to the user. If the keys match then the user becomes the first defined archwizard. There are cer- tain things that can be done with this which are well out of order, notably imbedding convenient access routes to a game database you intend to give away. If this bothers you, edit ActionCode.c , search for Act_Unveil(), and then replace the last line of the function "Set- Name(Me(),BOSS1)" with " SendItem(Me(),"No chance!0)" and recompile. USAVE Save the first 4 strings and the first 8 userflags of item from the file text. If this fails it returns false. A failure disturbs none of the current values. Not allowed if SECURE is defined. USER Invoke a user compiled function. See the source code for details. (UserVector.c) VISIBILITY Change the visibility of item to be number. The number is the minimum level to be able to perceive the item. WEAR Sets an item that the player is carrying to be worn. For this to be done the item must have its canwear flag set and be an object. A message is displayed to people present informing them of the action. If the item cannot be worn an error is displayed. WEIGH Calculate the total weight of item and its contents and store its result in flag. WEIGHT Set the weight of item to number. Either objects or play- ers may have weights set. It has no effect on other types of item. No checking of maximum weights is done. WHATO Number may be 1 or 2 indicating either the first or second adjective noun pair of the input. This action will scan globally for an item matching the adjective noun pair and store it as $1 or $2 as is appropriate. WHEN
Cause table to be invoked in roughly number seconds with $ME set to the current $ME. If the item is totally destroyed (for example a user logging out) any pending WHEN actions are deleted. As WHEN actions are queued doing a WHEN 0 table does not mean now, but as soon as the machine looks at its list of pending jobs. This is when- ever it has nothing to do or at least once every two sec- onds regardless. WHERETO This action looks up the exits from item and selects exit number (see MOVE for a list). If this is a valid exit then $1 or $2 is set to be the location you reach by heading in that direction. If there is no exit $1 or $2 is set to no item. WORN This is true if the current player is wearing the item in question. For this to be true the item must be directly contained within the player and have its worn oflag set. Non objects can never be worn. ZERO True if flag has a value of zero. Command reference A list of all server based commands, the syntax and simple description of the command and its use. Main game control commands Abort Abort the game driver, anything you have edited is lost. The server process is terminated. If you are running using Run_Aber then a new process will be started. Saveuniverse Save the current universe to file . To do this the server forks off a new copy of the game, quits all its users and saves the universe out to a file. Statme Display information about memory allocation when using dlibs fast malloc. Users [1] List all of the users on the game and their IP addresses. Not supplying a 1 afterwards only lists users fully logged in. Supplying the 1 lists all of the user slots whether being used or not. Status Show the number of items, rooms etc. ShowAllRooms Display all of the attributes for each room within the game. ShowAllObjects Same as above but for objects. ShowAllPlayers Same as above but for players. Debugger Sets to be the destination of all debug information. If no item is given then it is taken to be you. User commands These commands are normally implemented in the game server tables, and therefore not executed by the server itself. Brief Run by a user this changes a player flag so that long room descriptions are not shown when they enter a room. Verbose Opposite of Brief. Look Print a description of the current location and its contents. Goto For immortals, this command moves you to the current item. If the item is a room it places you in it, otherwise it places you next to the item. Place For immortals. Places item1 in item2. Invisible For immortals, this makes you invisible to everyone who is a lower level than you. Visible For immortals, makes you visible to all players. Say The basic form of communication. Sends message to all other players in the current location. Vocabulary AddAdj [] Add an adjective to the game system. Adjectives are primarily used to specify items more precisely. The value is used to determine synonyms only. If no value is given the a suitible free one is selected. AddNoun [] Add a noun to the list of words. Nouns are primarily used to associate words with items in the game. The value is used to determine synonyms. Values of 10000 or higher are reserved for use by the game system (this is where users are added into the game at). If no nos is specified then a suitible free one is selected. AddOrdinate Add an oridinate (n'th) word - such as 1st, 2nd etc. For ordinates the value parameter is the degree of the ordinate - thus 1st is 1, 2nd is 2 etc. AddPrep [] Add a preposition (joining word) to the game database. With these words the value is used to indicate synonyms. If no value is given then an unused one is selected. AddPronoun [] Add a pronoun (such as it, him). Most of these are already defined in the universe. The 'Basic Creation' chapter has more on this. AddVerb [] Add a verb to the list of words, if the word already is in the list it will be rejected. If no number is appended to the end it will be added at the first available point. If a number is appened then it will add the verb at that position in the list, therefore it is possible to have several verbs that mean the same thing. i.e n == north l == look k == kill etc. DelAdj DelNoun DelVerb DelOrdinate DelPronoun DelPrep Delete the word from the list of words. ListWords [|<#number>] With no arguments these will list all of the words that the server has been programmed with. Given a word it will list all occurences of this word in the word list and it's number. Given a number it will list all words with of number. Movement North, South, East, West, NorthEast, SouthEast, SouthWest, NorthWest, In, Out, Up, Down. Directions used in moving about in the game. Item Creation Create [] Create an that can be referenced only by noun and optional adjective. For example, you could create two items thus Create dog adj= noun=dog Create small dog adj=small noun=dog The problem with not referencing items with both an adj and a noun is that there is a problem referencing the first dog now. Since a reference to 'dog' will reference the most recently created item of that noun, i.e. small dog. Since the item has no adjective then it has to be referenced via other methods. Rename [] Rename an item to the supplied words. Again an adjective does not have to be supplied but this is advisible. Delete Remove an item from the game, the system will only allow to delete an item if it has no references to it and if it does belong to any game-classes (e.g. room, object etc). To find if an item has any references to it use the 'FindLocks' command. SetName Set the name field of to be . Note this does not affect how the item is referenced. i.e. an item can be called 'the big cat' but could be created and therefore referenced by the adjective small and noun dog. SetDesc Set the description of an items state. An item is in state 0 if it is open, or normal state. State 1 if it is closed. (*) State 2 if it is locked. (*) State 3 is used as the text displayed when the item is examined. (*) If the item doesn't open this does not need to be used. Set Set 's state to be , where is an integer number from 0-3. II II or ItemInfo shows all the information about an item. It shows all the information of the basic item, plus which classes the item belongs to (i.e. Object, Room etc). ListItems [] List the names of all items (if no parameter given), or the last items created. SetActor Set which table is run when a command is to be interpreted for this item. Default's to 0. SetAction Set which table is run as a Daemon table. (See Table Coding tutorials for more information). Which [] Display which item you are actually referencing when typing the adjective/noun combination. SetUFlag Set the value of userflag of to be . SetUItem Set the item held in userflag of to be ShowUser List all of the values/items held in the userflags of . DoorPair Player/Container/Object/Room Flags These flags can be used to tag an item. i.e. a PlayerFlag called Blind or a RoomFlag called Dark. In the following definitions can be replaced with either P for players, R for rooms, C for containers or O for objects. NameFlag Name a flag. ListFlags List the names of the flags. Players BePlayer Give the item the properties of a player. ShowPlayer As above but for players. SetPFlag [-] Set for . If there is a - before the then it will unset the PFlag for . SetPSize Set a players size. SetPWeight Set a players weight. SetPStrength Set a players strength. SetPLevel Set a players level. SetPScore Set a players score (0-30000) SetPerception Set a players perception or visibility. UnPlayer Remove player properties from an object. Containers BeContainer Give the item the properties of a container. ShowContainer Display information about an item that has container properties. SetVolume Set the volume of container to be . SetCFlag [-] Set for . If there is a - before the then it will unset the CFlag for . UnContainer Remove container properties from an object. Objects BeObject Give the item the properties of an object. This will ask you a series of questions about the object. ShowObject As above but for objects. UnObject Remove object properties from an object. SetOFlag [-] Set for . If there is a - before the then it will unset the OFlag for . SetOSize Set the size of an object. SetOWeight Set the weight of an object. ObjEdit Re-edit the object, in the same was as if had just BeObject'd it. Rooms BeRoom Give the item the properties of a room. ShowRoom As above but for rooms. UnRoom Remove the room properties of an item. Before doing this make sure there are no exits to/from the room as these are classed as locks, and will make deletion of the item impossible until they are removed. SetShort Set the short description of a room. SetLong Set the long description of a room. SetRFlag [-] Set for . If there is a - before the then it will unset the RFlag for . NewExit Create a new exit from one room to another. Note that all exits are one way. CondExit
Create an exit from one room to another that is dependant on the execution of a table. If the table ends executing a NOT DONE then the exit does not exist. Otherwise it does exist. MsgExit Create an exit from one room to another, but when a player moves through this exit the supplied text is sent to them. DelExit Delete an exit, the item given is the source of the exit. Advanced creation, classes and superclasses Chain Chain two items together. Read the chapter on classes for more information. Note that chains are one way. UnChain Remove's the chain set by the above command. Share UnShare SetSuperClass Set an items superclass item. To remove a superclass set its superclass item to be itself. i.e. SetSuperClass big stick big stick More information is in the relevant section of the manual. ShowSuperClass Show the superclass of an item. ListClass List all of the classes. NameClass Name a class. SetClass Set an item to be a member of that class. UnsetClass Remove the class membership of an item. Tables Parameters can be used in this way. is a number of a table. is the name of a table.
can be either of the above two. ListTables List all of the tables. DeleteTable
Delete a table. LoadTable [] Load a table from a file. If the table already exists it must be empty, and no name given. If the table does not exist it will create it and the name must be given. EditTable
Edit a table. NewTable Create a new table. SaveTable
Save a table's contents out to a file. NameTable Name, or rename, a table. FindItem Find an item in a table. This does not search item-tables. EditOTable Edit the Object table of an item. EditSTable Edit the Subject table of an item. EditDTable Edit the Deamon table of an item. Flags Parameters can be interpreted in this way. is the number of a flag. is the name of a flag. is either of the above two. ListFlags List all of the flags. Only flags with names are listed. NameFlag Name a flag. UnNameFlag Remove the name of a flag. It will not be shown in ListFlags. ShowFlag [,] Display the current values of a flag or a range of flags. SetFlag Set the value of a flag. TrackFlag Mark a flag for tracking. Up to 4 flags can be tracked at any one time. UnTrackFlag Cease tracking a flag. ListTrack Show which flags are being Tracked at the current time. FindFlag Find all occurences of in the main tables. Subject, Object and Daemon tables of items are not searched. BSX graphics DeleteBSX Delete a BSX picutre. LoadBSX Load a BSX picture from a file. ListBSX List all of the BSX pictures. ShowBSX Display a BSX picture. (Special client needed) SetPicture Set a picture for an item. Conclusion and other comments Thanks to:- Alan Cox & Co. for writing the original version. Malcolm 'Lager' McNaughton (malcy@cheese.org) for the table coding manual which I never got round to writing. Dave 'Flagg' Beynon (flagg@jumper.mcc.ac.uk) for the additional guide. We hope you enjoy using AberMUD 5 and if you have any comments please send them to me. No apologies are made for any spelling, grammatical or factual errors. Send comments to Alex 'Snell' Greenbank (alex@cheese.org)