AberMUD5(6) AberMUD5(6) AAbbeerrMMUUDD 55..2211..33 SSyysstteemm MMaannuuaall 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. Interpreter Structure 12. Basic Interpreter Facilities 13. Superclassing 14. Advanced Interpreter Facilities 15. Graphics & Client Support AAppppeennddiicciieess A. Interpreter Reference B. Command Reference IInnttrroodduuccttiioonn 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 16 May 1993 1 AberMUD5(6) AberMUD5(6) 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 AAbbeerrMMUUDD:: MMyytthhoollooggyy aanndd HHiissttoorryy 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 16 May 1993 2 AberMUD5(6) AberMUD5(6) 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 16 May 1993 3 AberMUD5(6) AberMUD5(6) 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 16 May 1993 4 AberMUD5(6) AberMUD5(6) 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 16 May 1993 5 AberMUD5(6) AberMUD5(6) 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 16 May 1993 6 AberMUD5(6) AberMUD5(6) release. FFeeaattuurreess 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 IInnssttaallllaattiioonn AAnndd OOppeerraattiioonn 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 three subdirectories called:- 'DOC' Documentation 'SOURCE' System source code 'UNIVERSE' Supplied game universe Go into the SOURCE directory and edit the file 'System.h'. This contains the configuration parameters that are hard coded into the game OOppttiioonnss 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 16 May 1993 7 AberMUD5(6) AberMUD5(6) 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 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. _I_M_P_O_R_T_A_N_T_: 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 16 May 1993 8 AberMUD5(6) AberMUD5(6) 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 16 May 1993 9 AberMUD5(6) AberMUD5(6) 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 _R_E_G_I_S_T_R_A_T_I_O_N option has been defined. This option is still under test and may or may not work cor- rectly. OOvveerrvviieeww ooff tthhee GGaammee DDrriivveerr.. 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. 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 16 May 1993 10 AberMUD5(6) AberMUD5(6) 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 16 May 1993 11 AberMUD5(6) AberMUD5(6) 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. BBaassiicc CCrreeaattiioonn 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. _A_d_d_v_e_r_b _<_t_e_x_t_> _<_v_a_l_u_e_> 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. _A_d_d_o_r_d_i_n_a_t_e _<_t_e_x_t_> _<_v_a_l_u_e_> 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. _A_d_d_p_r_e_p_o_s_i_t_i_o_n _<_t_e_x_t_> _<_v_a_l_u_e_> 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. _A_d_d_a_d_j_e_c_t_i_v_e _<_t_e_x_t_> _<_v_a_l_u_e_> 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. _A_d_d_n_o_u_n _<_t_e_x_t_> _<_v_a_l_u_e_> 16 May 1993 12 AberMUD5(6) AberMUD5(6) 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. _A_d_d_p_r_o_n_o_u_n _<_t_e_x_t_> _<_v_a_l_u_e_> 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 _D_e_l_v_e_r_b _<_t_e_x_t_> _D_e_l_n_o_u_n _<_t_e_x_t_> _D_e_l_a_d_j_e_c_t_i_v_e _<_t_e_x_t_> _D_e_l_p_r_e_p _<_t_e_x_t_> _D_e_l_p_r_o_n_o_u_n _<_t_e_x_t_> _D_e_l_o_r_d_i_n_a_t_e _<_t_e_x_t_> 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..... MMiisscceellllaanneeoouuss CCoommmmaannddss 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. 16 May 1993 13 AberMUD5(6) AberMUD5(6) 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! IItteemmss 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 16 May 1993 14 AberMUD5(6) AberMUD5(6) 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 16 May 1993 15 AberMUD5(6) AberMUD5(6) 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 _d_e_l_e_t_e _<_i_t_e_m_n_a_m_e_> 16 May 1993 16 AberMUD5(6) AberMUD5(6) If the item is in use you will be told so, and it will not be deleted. RRoooommss 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 _s_e_t_s_h_o_r_t _<_i_t_e_m_> _<_t_e_x_t_>_. 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 _s_e_t_- _l_o_n_g _<_i_t_e_m_> _<_t_e_x_t_> 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 _s_e_t_r_f_l_a_g _<_r_o_o_m_> _<_f_l_a_g_s_> 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 16 May 1993 17 AberMUD5(6) AberMUD5(6) 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. 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 _n_a_m_e_r_f_l_a_g _<_n_u_m_b_e_r_> _<_n_a_m_e_> may be used by the system in later releases. Any user added room flags should start at the last one and work backwards. EExxiittss 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 _n_e_w_e_x_i_t _f_r_o_m___i_t_e_m _d_i_r_e_c_t_i_o_n _t_o___i_t_e_m 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 _d_e_l_e_x_i_t _<_f_r_o_m_r_o_m_> _<_d_i_r_e_c_t_i_o_n_>_. All other types of exit are removed in this fashion too. A message exit displays some text as the player travels in 16 May 1993 18 AberMUD5(6) AberMUD5(6) 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 _m_s_g_e_x_i_t _<_f_r_o_m___i_t_e_m_> _<_d_i_r_e_c_t_i_o_n_> _<_t_o___i_t_e_m_> _<_t_e_x_t_._._._._._._._._._._._> A currently existing text can be edited by doing _m_s_g_e_x_i_t _<_f_r_o_m___i_t_e_m_> _<_d_i_r_e_c_t_i_o_n_> Finally a conditional exit allows you to attach a table of database. These are created with _c_o_n_d_e_x_i_t _<_f_r_o_m___i_t_e_m_> _<_d_i_r_e_c_t_i_o_n_> _<_t_o___i_t_e_m_> _<_t_a_b_l_e___n_a_m_e_> We will deal with tables much much later on. The condexit is only included here for completeness. _N_o_t_e_: 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. OObbjjeeccttss 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 _b_e_o_b_j_e_c_t _<_i_t_e_m_>_. To remove its object properties type _u_n_o_b_j_e_c_t _<_i_t_e_m_>_. An object has the following properties which can be viewed by typing _s_h_o_w_o_b_j_e_c_t _<_i_t_e_m_>_. Descriptions: Four descriptions, one for each state. These are set using _s_e_t_- _d_e_s_c _<_i_t_e_m_> _<_s_t_a_t_e_> _<_t_e_x_t_>_. As with rooms *text means load from a file. Its a common trick to use state 3 to hold examine texts for everything. 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 _o_s_i_z_e _<_i_t_e_m_> _<_v_a_l_u_e_> command to set this. Weight: The weight of the item (without any contents). The same comments about values apply as with sizes. Use the _o_w_e_i_g_h_t _<_i_t_e_m_> _<_v_a_l_u_e_> command to set this. 16 May 1993 19 AberMUD5(6) AberMUD5(6) 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. 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 _n_a_m_e_o_f_l_a_g _<_n_u_m_b_e_r_> _<_t_e_x_t_>_. They are listed with _l_i_s_t_o_f_l_a_g_s_. You can set and unset flags on an object by doing _s_e_t_o_f_l_a_g _<_i_t_e_m_> _<_f_l_a_g_n_a_m_e_>_. Use - to remove a flag. CCoonnttaaiinneerrss 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 _B_e_C_o_n_- _t_a_i_n_e_r _<_i_t_e_m_>_. To remove its container properties you use the command _U_n_C_o_n_t_a_i_n_e_r _<_i_t_e_m_>_. A container has only two properties Volume: The total item size you can fit in the item. This is set with the command _s_e_t_v_o_l_u_m_e _<_i_t_e_m_> _<_v_a_l_u_e_>_. Flags: Flags controlling the item. The flags are: 16 May 1993 20 AberMUD5(6) AberMUD5(6) 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 _s_e_t_c_f_l_a_g _<_i_t_e_m_> _<_f_l_a_g_n_a_m_e_>_. As with the other classes - means clear the flag. Container flags may be listed with _l_i_s_t_c_f_l_a_g_s , and named with _n_a_m_e_c_f_l_a_g _<_n_u_m_b_e_r_> _<_n_a_m_e_>_. A room can also be a container, in which case you will be unable to enter it if you won't fit its volume. PPllaayyeerrss 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 16 May 1993 21 AberMUD5(6) AberMUD5(6) 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: _b_e_p_l_a_y_e_r _<_i_t_e_m_> 16 May 1993 22 AberMUD5(6) AberMUD5(6) Make the item a player. _u_n_p_l_a_y_e_r _<_i_t_e_m_> Remove the player properties of an item. _s_h_o_w_p_l_a_y_e_r _<_i_t_e_m_> View the player properties of an item. _s_e_t_p_s_t_r_e_n_g_t_h _<_i_t_e_m_> _<_v_a_l_u_e_> Set the strength of a player. _s_e_t_p_l_e_v_e_l _<_i_t_e_m_> _<_v_a_l_u_e_> Set the level of a player. _s_e_t_p_s_c_o_r_e _<_i_t_e_m_> _<_v_a_l_u_e_> Set the score of a player. _s_e_t_p_s_i_z_e _<_i_t_e_m_> _<_v_a_l_u_e_> Set the size of a player. _s_e_t_p_w_e_i_g_h_t _<_i_t_e_m_> _<_v_a_l_u_e_> Set the weight of a player. _s_e_t_p_f_l_a_g _<_i_t_e_m_> _<_f_l_a_g_> Set a flag on a player item. You can remove a flag setting by using -flag. _l_i_s_t_p_f_l_a_g_s View the pflags. _n_a_m_e_p_f_l_a_g _<_n_u_m_b_e_r_> _<_n_a_m_e_> Name a player flag. OOtthheerr CCllaasssseess _S_n_o_o_p_: 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. _D_u_p_: 16 May 1993 23 AberMUD5(6) AberMUD5(6) 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. _I_n_O_u_t_H_e_r_e_: 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. _C_h_a_i_n_: 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 _c_h_a_i_n _<_s_o_u_r_- _c_e_i_t_e_m_> _<_t_a_r_g_e_t_i_t_e_m_> , and removed with the command _u_n_c_h_a_i_n _<_s_o_u_r_c_e_i_t_e_m_> _<_t_a_r_g_e_t_i_t_e_m_>_. The _I_I 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. _U_s_e_r_F_l_a_g_: _U_s_e_r_F_l_a_g_2_: _U_s_e_r_T_e_x_t_: A total of eight strings, sixteen other items and sixteen numbers can be stored as user flag values by the database. The command _s_h_o_w_u_s_e_r _<_i_t_e_m_> 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. _S_h_a_r_e_: 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 _M_U_S_T unshare it first. Shares are constructed by typing _s_h_a_r_e _<_i_t_e_m_1_> _<_i_t_e_m_2_> , and removed by using _u_n_s_h_a_r_e _<_i_t_e_m_1_> _<_i_t_e_m_2_> - where item1 is the item which uses classes from item2. As with chains they are shown by the _I_I command. 16 May 1993 24 AberMUD5(6) AberMUD5(6) HHaannddyy CCoommmmaannddss 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 _s_h_o_w_a_l_l_p_l_a_y_e_r_s , _s_h_o_w_a_l_l_r_o_o_m_s and _s_h_o_w_a_l_l_o_b_j_e_c_t_s 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 _d_o_o_r_p_a_i_r _<_a_d_j_e_c_t_i_v_e_> _<_n_o_u_n_> _<_f_r_o_m_r_o_o_m_> _<_d_i_r_e_c_t_i_o_n_> _<_t_o_r_o_o_m_> , 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 _u_s_e_r_s command gives a dump of who is playing, from where, and what they are doing. The _s_t_a_t_u_s command gives an overall summary of system usage and the number of each item created. The _s_t_a_t_m_e 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. AAppppeennddiixx AA:: IInntteerrpprreetteerr RReeffeerreennccee 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. IP Flag 16 The action takes an 16 May 1993 25 AberMUD5(6) AberMUD5(6) argument which is the number or name of a flag within the game system. Using the Fn syntax here will generate a reference to a flag of a flag, that is the value of the flag whose number is held in flag n. 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 _v_e_r_b_, _a_d_j_e_c_t_i_v_e or _n_o_u_n_. 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. IInntteerrpprreetteerr AAccttiioonn LLiisstt _A_T _<_i_t_e_m_> This action is true if the current player is directly con- tained in the item specified. _N_O_T_A_T _<_i_t_e_m_> This action is true if the current player is not directly contained in the specified item. _P_R_E_S_E_N_T _<_i_t_e_m_> 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. _A_B_S_E_N_T _<_i_t_e_m_> The reverse of the present condition. 16 May 1993 26 AberMUD5(6) AberMUD5(6) _W_O_R_N _<_i_t_e_m_> 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. _N_O_T_W_O_R_N _<_i_t_e_m_> The reverse of the WORN condition. _C_A_R_R_I_E_D _<_i_t_e_m_> True if the item is directly contained within the current player. Items that are worn are also counted as carried. _N_O_T_C_A_R_R _<_i_t_e_m_> The reverse of the carried action. _I_S_A_T _<_i_t_e_m_1_> _<_i_t_e_m_2_> 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. _I_S_N_O_T_A_T _<_i_t_e_m_1_> _<_i_t_e_m_2_> The reverse of the isat action. _I_S_B_Y _<_i_t_e_m_1_> _<_i_t_e_m_2_> 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. _I_S_N_O_T_B_Y _<_i_t_e_m_1_> _<_i_t_e_m_2_> The reverse of the isby condition. _Z_E_R_O _<_f_l_a_g_> True if flag has a value of zero. _N_O_T_Z_E_R_O _<_f_l_a_g_> True if flag has a non-zero value. _E_Q _<_f_l_a_g_> _<_n_u_m_b_e_r_> True if flag contains the value number. _N_O_T_E_Q _<_f_l_a_g_> _<_n_u_m_b_e_r_> 16 May 1993 27 AberMUD5(6) AberMUD5(6) True if flag does not contain the value nunber. _G_T _<_f_l_a_g_> _<_n_u_m_b_e_r_> True if flag contains a value greater than number. _L_T _<_f_l_a_g_> _<_n_u_m_b_e_r_> True if flag contains a value less than number. _E_Q_F _<_f_l_a_g_1_> _<_f_l_a_g_2_> True if flag1 and flag2 contain the same value. _N_O_T_E_Q_F _<_f_l_a_g_1_> _<_f_l_a_g_2_> True if flag1 and flag2 contain different values. _L_T_F _<_f_l_a_g_1_> _<_f_l_a_g_2_> True if flag1 contains a smaller value than flag2. _G_T_F _<_f_l_a_g_1_> _<_f_l_a_g_2_> True if flag1 contains a larger value than flag2. _I_S_I_N _<_i_t_e_m_1_> _<_i_t_e_m_2_> 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. _I_S_N_O_T_I_N _<_i_t_e_m_1_> _<_i_t_e_m_2_> The reverse of the isin action. _A_D_J_1 _<_a_d_j_e_c_t_i_v_e_> True if the first user entered adjective is the given word or a synonym _A_D_J_2 _<_a_d_j_e_c_t_i_v_e_> True if the second user entered adjective is the given word or a synonym _N_O_U_N_1 _<_n_o_u_n_> True if the first user entered noun is the given word or a synonym _N_O_U_N_2 _<_n_o_u_n_> 16 May 1993 28 AberMUD5(6) AberMUD5(6) True if the second user entered noun is the given word or a synonym _P_R_E_P _<_p_r_e_p_o_s_i_t_i_o_n_> True if the user entered preposition is the given word or a synonym _C_H_A_N_C_E _<_n_u_m_b_e_r_> This action has a number in 100 (ie a percentage) chance of being true. _I_S_P_L_A_Y_E_R _<_i_t_e_m_> True if the item has player properties. _I_S_U_S_E_R _<_i_t_e_m_> True if the item is a user of the game rather than just a game driven object. _I_S_R_O_O_M _<_i_t_e_m_> True if the item has room properties _I_S_O_B_E_C_T _<_i_t_e_m_> True if the item has object properties _S_T_A_T_E _<_i_t_e_m_> _<_n_u_m_b_e_r_> 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. _P_F_L_A_G _<_i_t_e_m_> _<_p_f_l_a_g_> True if the item has this player flag set. Non players are assumed to always have this clear. _O_F_L_A_G _<_i_t_e_m_> _<_o_f_l_a_g_> True if the item has this object flag set. Non objects are assumed to always have this clear. _C_A_N_P_U_T_I_N _<_i_t_e_m_1_> _<_i_t_e_m_2_> 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 16 May 1993 29 AberMUD5(6) AberMUD5(6) over 100% full when another soft container is within it and an item is placed into the soft container from outside of either container. _R_F_L_A_G _<_i_t_e_m_> _<_r_f_l_a_g_> True if item has the room flag specified set. Non rooms have all these flags assumed to be zero. _L_E_V_E_L _<_n_u_m_b_e_r_> True if the level property of the current player is at least number. Non players have a level of zero. _I_F_D_E_A_F True if the player is deaf. This is directly equivalent to testing the deaf flag with PFLAG. _I_F_B_L_I_N_D True if the player is blind. _A_R_C_H True if the name of the player matches one of the compiled in archwizard names. Remember that the editing commands are tied to the name, and thus allowing people to set the name is a bad idea. _G_E_T _<_i_t_e_m_> 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. _D_R_O_P _<_i_t_e_m_> 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. _R_E_M_O_V_E _<_i_t_e_m_> 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 16 May 1993 30 AberMUD5(6) AberMUD5(6) sent to people present informing them of the event. _W_E_A_R _<_i_t_e_m_> 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. _C_R_E_A_T_E _<_i_t_e_m_> 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. _D_E_S_T_R_O_Y _<_i_t_e_m_> 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. _P_U_T_O _<_i_t_e_m_> Obsolete call. _S_W_A_P _<_i_t_e_m_1_> _<_i_t_e_m_2_> Swaps over the location of item1 and item2. No checks on whether the item will fit are made. _P_L_A_C_E _<_i_t_e_m_1_> _<_i_t_e_m_2_> Item1 is placed directly into item2. No checks are made. _P_U_T_I_N _<_i_t_e_m_1_> _<_i_t_e_m_2_> 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. _T_A_K_E_O_U_T _<_i_t_e_m_1_> _<_i_t_e_m_2_> 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. _C_O_P_Y_O_F _<_i_t_e_m_> _<_n_u_m_b_e_r_> _<_f_l_a_g_> 16 May 1993 31 AberMUD5(6) AberMUD5(6) 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. _C_O_P_Y_F_O _<_f_l_a_g_> _<_i_t_e_m_> _<_n_u_m_b_e_r_> 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. _C_O_P_Y_F_F _<_f_l_a_g_1_> _<_f_l_a_g_2_> The value in flag1 is placed into flag2. _W_H_A_T_O _<_n_u_m_b_e_r_> 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. _G_E_T_O _<_n_u_m_b_e_r_> _<_i_t_e_m_> 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. _W_E_I_G_H _<_i_t_e_m_> _<_f_l_a_g_> Calculate the total weight of item and its contents and store its result in flag. _S_E_T _<_f_l_a_g_> Set the value of flag to 255. _C_L_E_A_R _<_f_l_a_g_> Set the value of flag to 0. _P_S_E_T _<_i_t_e_m_> _<_p_f_l_a_g_> Set player flag pflag of item. This function has no effect on non player class objects. _P_C_L_E_A_R _<_i_t_e_m_> _<_p_f_l_a_g_> Clears player flag pflag of item. This function has no effect on non player class objects. _L_E_T _<_f_l_a_g_> _<_n_u_m_b_e_r_> 16 May 1993 32 AberMUD5(6) AberMUD5(6) Set the value of flag to be number. _A_D_D _<_f_l_a_g_> _<_n_u_m_b_e_r_> 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. _S_U_B _<_f_l_a_g_> _<_n_u_m_b_e_r_> Subtract number from the value in flag and store the result back in flag. _A_D_D_F _<_f_l_a_g_1_> _<_f_l_a_g_2_> Add the value in flag1 to the value in flag2 and store the result back in flag1. _S_U_B_F _<_f_l_a_g_1_> _<_f_l_a_g_2_> Subtract the value in flag2 from the value in flag1 and store the result back in flag1. _M_U_L _<_f_l_a_g_> _<_n_u_m_b_e_r_> Multiplies the value of flag by number and stores the result back in flag. _D_I_V _<_f_l_a_g_> _<_n_u_m_b_e_r_> Divides the value of flag by number. If you attempt a division by zero the message _M_U_L_F _<_f_l_a_g_1_> _<_f_l_a_g_2_> The contents of flag1 are multiplied by the contents of flag2 and the result is stored in flag1. _D_I_V_F _<_f_l_a_g_> _<_n_u_m_b_e_r_> Divides the value of flag1 by the value of flag2. If you attempt a division by zero the message _M_O_D _<_f_l_a_g_> _<_n_u_m_b_e_r_> 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. _M_O_D_F _<_f_l_a_g_1_> _<_f_l_a_g_2_> 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. 16 May 1993 33 AberMUD5(6) AberMUD5(6) _R_A_N_D_O_M _<_f_l_a_g_> _<_n_u_m_b_e_r_> 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. _M_O_V_E _<_f_l_a_g_> 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. _G_O_T_O _<_i_t_e_m_> 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. _W_E_I_G_H_T _<_i_t_e_m_> _<_n_u_m_b_e_r_> 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. 16 May 1993 34 AberMUD5(6) AberMUD5(6) _S_I_Z_E _<_i_t_e_m_> _<_n_u_m_b_e_r_> 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. _O_S_E_T _<_i_t_e_m_> _<_o_f_l_a_g_> Set an object flag on an item. If the item is not an object nothing happens. _O_C_L_E_A_R _<_i_t_e_m_> _<_o_f_l_a_g_> Clear an object flag on an item. If the item is not an object nothing happens. _R_S_E_T _<_i_t_e_m_> _<_o_f_l_a_g_> Set an room flag on an item. If the item is not an room nothing happens. _R_C_L_E_A_R _<_i_t_e_m_> _<_o_f_l_a_g_> Clear an room flag on an item. If the item is not an room nothing happens. _P_U_T_B_Y _<_i_t_e_m_1_> _<_i_t_e_m_2_> Item1 is placed in the same location as item2. No messages are displayed and no size or weight checking is done. _I_N_C _<_i_t_e_m_1_> 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. _D_E_C _<_i_t_e_m_1_> Decrement (subtract 1 from) the state of an item. If the state is already 0 nothing happens. _S_E_T_S_T_A_T_E _<_i_t_e_m_> _<_n_u_m_b_e_r_> 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. _P_R_O_M_P_T _<_t_e_x_t_> Set the input prompt of the current player to be the given text string. If the current player is not a user then 16 May 1993 35 AberMUD5(6) AberMUD5(6) nothing happens. _P_R_I_N_T _<_f_l_a_g_> 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. _S_C_O_R_E Display the players score in a simple format. This is for compatibility and now obsolete. _M_E_S_S_A_G_E _<_t_e_x_t_> Output a text message on the current players screen (if any). A trailing newline is added. _M_S_G _<_t_e_x_t_> Output a text message on the current players screen (if any). A trailing newline is not added. _L_I_S_T_O_B_J _<_i_t_e_m_> Generate an output list of long descriptions of the con- tents of item in a short 'name,name and name.' type for- mat. _L_I_S_T_A_T _<_i_t_e_m_> 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. _I_N_V_E_N Display the users inventory. _D_E_S_C Describe the location of the current player including objects, and trapping out to the user control tables called during a room description. _E_N_D _<_t_e_x_t_> 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. _D_O_N_E 16 May 1993 36 AberMUD5(6) AberMUD5(6) 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. _N_O_T_D_O_N_E 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. _A_B_O_R_T Abort the game server instantly. All users are kicked off and the program exits without saving any game world changes. _S_A_V_E Store the current players persona to the user data file. If the save fails this action fails too. _P_A_R_S_E _<_t_e_x_t_> 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. _N_E_W_T_E_X_T Flsuh all the pronouns. _P_R_O_C_E_S_S _<_t_a_b_l_e_> Suspend current processing and processes table. Once table is processed continue processing. _D_O_C_L_A_S_S _<_i_t_e_m_> _<_c_l_a_s_s_f_l_a_g_> _<_i_t_e_m_v_a_l_> 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 _a_f_t_e_r 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 16 May 1993 37 AberMUD5(6) AberMUD5(6) 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. _G_I_V_E _<_i_t_e_m_1_> _<_i_t_e_m_2_> 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. _S_E_T_U_T _<_i_t_e_m_> _<_n_u_m_b_e_r_> _<_t_e_x_t_> 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. _D_O_E_S_A_C_T_I_O_N _<_i_t_e_m_> _<_m_e_s_s_a_g_e_> _<_n_u_m_b_e_r_> 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. _D_O_E_S_T_O _<_i_t_e_m_> _<_m_e_s_s_a_g_e_> _<_i_t_e_m_2_> _<_n_u_m_b_e_r_> 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 _D_O_E_S_T_O_P_L_A_Y_E_R _<_i_t_e_m_> _<_m_e_s_s_a_g_e_> _<_i_t_e_m_2_> _<_n_u_m_b_e_r_> 16 May 1993 38 AberMUD5(6) AberMUD5(6) Identical to DOESTO except that the output is formatted as when it is reported to item2. _P_O_B_J _<_i_t_e_m_> _<_n_u_m_b_e_r_> 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. _P_L_O_C _<_i_t_e_m_> _<_n_u_m_b_e_r_> 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. _P_N_A_M_E _<_i_t_e_m_> 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. _P_C_N_A_M_E _<_i_t_e_m_> 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. _D_A_E_M_O_N _<_i_t_e_m_> _<_v_e_r_b_> _<_n_o_u_n_1_> _<_n_o_u_n_2_> 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. _A_L_L_D_A_E_M_O_N _<_v_e_r_b_> _<_n_o_u_n_> _<_n_o_u_n_> As a daemon except that it is applied to all _u_s_e_r_s on the game system. For speed reasons only user objects are pro- cessed. _H_D_A_E_M_O_N _<_i_t_e_m_> _<_v_e_r_b_> _<_n_o_u_n_> _<_n_o_u_n_> As a daemon except that it is applied to all _u_s_e_r_s that are in the same location as item. _W_H_E_N _<_n_u_m_b_e_r_> _<_t_a_b_l_e_> 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 16 May 1993 39 AberMUD5(6) AberMUD5(6) 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. _S_E_T_N_A_M_E _<_i_t_e_m_> _<_t_e_x_t_> 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. _D_U_P _<_i_t_e_m_> _<_n_u_m_b_e_r_> _<_i_t_e_m_v_a_l_> 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. _F_R_O_B Obsolete. _P_O_I_N_T_S _<_n_u_m_b_e_r_> The players score is increased (or if number is negative decreased) by the number of points indicated. _H_U_R_T _<_n_u_m_b_e_r_> 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. _C_U_R_E_D _<_n_u_m_b_e_r_> The players strength is increased by number. _K_I_L_L_O_F_F _<_t_e_x_t_> 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. 16 May 1993 40 AberMUD5(6) AberMUD5(6) _A_U_T_O_V_E_R_B _<_v_e_r_b_> 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. _I_F_1 True if $1 references an item. _I_F_2 True if $2 references an item. _B_U_G _<_t_e_x_t_> Add a bug report to the system log. _T_Y_P_O _<_t_e_x_t_> Add a typo record to the system log. _N_A_R_G _<_f_l_a_g_> _<_n_u_m_b_e_r_> Obsolete _I_S_M_E _<_i_t_e_m_> True if item is the current player (ie $ME). _B_R_O_A_D_C_A_S_T _<_t_e_x_t_> _<_n_u_m_b_e_r_> 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. _I_S_C_A_L_L_E_D _<_i_t_e_m_> _<_t_e_x_t_> 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. _I_S _<_i_t_e_m_1_> _<_i_t_e_m_2_> True if item1 is item2. This isn't as pointless as it sounds since items can of course be things like $AC, $ME , $1. _S_E_T_M_E _<_i_t_e_m_> Change the 'current' player - ie $ME - to be item. 16 May 1993 41 AberMUD5(6) AberMUD5(6) _P_R_O_N_O_U_N_S Display the current pronouns. _C_H_A_N_C_E_L_E_V _<_n_u_m_b_e_r_> This condition has a number in 100 chance of being true for each level the player has. Non player items are always level 0. _E_X_I_T_S _<_i_t_e_m_> 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. _P_W_C_H_A_N_G_E 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. _S_N_O_O_P _<_i_t_e_m_> Begin snooping on an item, and seeing exactly what it does. This only works properly if you are snooping on another user. _U_N_S_N_O_O_P _<_n_u_m_b_e_r_> _<_i_t_e_m_> If number is non-zero unsnoop everything this user is cur- rently snooping on. Otherwise cease snooping on item. _G_E_T_U_T _<_i_t_e_m_> _<_n_u_m_b_e_r_> Items have up to eight user text strings. This function extracts string number from item and places it into {$}. _C_A_T _<_t_e_x_t_1_> _<_t_e_x_t_2_> _<_t_e_x_t_3_> The three strings text1, text2, and text3 are concatenated and placed in {$}. The total length must be 512 bytes or less. _B_E_C_O_M_E _<_t_e_x_t_> The current player is logged out and the user is placed back at the game login prompt. _A_L_I_A_S _<_i_t_e_m_> The player gains control over another item, and observes 16 May 1993 42 AberMUD5(6) AberMUD5(6) 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. _U_N_A_L_I_A_S Cease being aliased and return to being the original user. _F_I_E_L_D _<_n_u_m_b_e_r_> Move on to the next X position that is divisible by num- ber. This enables you to lay out tabulated data. _N_E_E_D_F_I_E_L_D _<_n_u_m_b_e_r_> Not supported. _U_N_V_E_I_L _<_n_u_m_b_e_r_> 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. _D_E_B_U_G _<_n_u_m_b_e_r_> 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. _G_E_T_S_C_O_R_E _<_i_t_e_m_> _<_f_l_a_g_> Copy the score of a player item into flag. _G_E_T_S_T_R _<_i_t_e_m_> _<_f_l_a_g_> Copy the strength of a player item into flag. _G_E_T_L_E_V _<_i_t_e_m_> _<_f_l_a_g_> Copy the level of a player item into flag. 16 May 1993 43 AberMUD5(6) AberMUD5(6) ,I SETSCORE Set the score of a player item to the value of flag. _S_E_T_L_E_V _<_i_t_e_m_> _<_f_l_a_g_> Set the level of a player item to the value of flag. _S_E_T_S_T_R _<_i_t_e_m_> _<_f_l_a_g_> Set the strength of a player item to the value of flag. _S_H_E_L_L _<_t_e_x_t_> 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. _C_S_E_T _<_i_t_e_m_> _<_c_f_l_a_g_> Set a container flag on a container item. This has no effect on items that do not have the container class. _C_C_L_E_A_R _<_i_t_e_m_> _<_c_f_l_a_g_> Clear a container flag on a container item. This has no effect on items that do not have the container class. _C_F_L_A_G _<_i_t_e_m_> _<_c_f_l_a_g_> True if a container item has this container flag set. Non container items never have any container flags set. _C_A_N_S_E_E _<_i_t_e_m_> True if the current player can perceive item after due consideration of darkness blindness and invisibility rules. _R_E_S_C_A_N 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. _M_E_A_N_S _<_v_e_r_b_> _<_n_o_u_n_> _<_n_o_u_n_> _<_n_u_m_b_e_r_> 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. 16 May 1993 44 AberMUD5(6) AberMUD5(6) _T_R_E_E_D_A_E_M_O_N _<_i_t_e_m_> _<_v_e_r_b_> _<_n_o_u_n_> _<_n_o_u_n_> 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. _S_E_T_I_N _<_t_e_x_t_> Set the message displayed when the current item enters a location. _S_E_T_O_U_T _<_t_e_x_t_> Set the message displayed when the current item leaves a location. _S_E_T_H_E_R_E _<_t_e_x_t_> Set the message displayed when the current item is seen within a location description. _C_A_N_G_O_T_O _<_i_t_e_m_> _<_f_l_a_g_> 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. _M_O_B_I_L_E_S Obsolete. _D_I_R Obsolete. _R_O_O_M_S Obsolete. _C_H_A_I_N_D_A_E_M_O_N _<_i_t_e_m_> _<_v_e_r_b_> _<_n_o_u_n_1_> _<_n_o_u_n_2_> Perform a DAEMON action (see above) on each item which is chained (with the chain class and command) to this item. _C_A_N_G_O_B_Y _<_i_t_e_m_> _<_f_l_a_g_> As CANGOTO except that this action searches for a move which places you in the same location as item. _S_E_T_I_F_L_A_G _<_i_t_e_m_1_> _<_n_u_m_b_e_r_> _<_i_t_e_m_2_> Each item can have up to eight item flags each remembering another item. The SETIFLAG action sets flag number of 16 May 1993 45 AberMUD5(6) AberMUD5(6) item1 to contain item2. If number is out of range nothing happens. _G_E_T_I_F_L_A_G _<_i_t_e_m_> _<_n_u_m_b_e_r_> _<_i_t_e_m_v_a_l_> 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. _C_L_E_A_R_I_F_L_A_G _<_i_t_e_m_> _<_n_u_m_b_e_r_> Set item flag number of item to indicate no item at all. _W_H_E_R_E_T_O _<_i_t_e_m_> _<_n_u_m_b_e_r_> _<_i_t_e_m_v_a_l_> 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. _D_O_O_R_E_X_I_T _<_i_t_e_m_1_> _<_i_t_e_m_2_> _<_f_l_a_g_> 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'. _C_L_A_S_S_A_T _<_i_t_e_m_> _<_c_l_a_s_s_> This condition is true if at least one of items direct contents is a member of class. _D_U_P_O_F _<_i_t_e_m_1_> _<_i_t_e_m_2_> True if item1 is a duplicate of item2 that was created by the DUP action. Only temporary duplicates remember this information. _M_A_S_T_E_R_O_F _<_i_t_e_m_> _<_i_t_e_m_v_a_l_> 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. _C_O_M_M_E_N_T _<_t_e_x_t_> A comment in the database. The comment is ignored at run time. _C_O_M_V_O_C_A_B _<_v_e_r_b_> _<_a_d_j_e_c_t_i_v_e_> _<_n_o_u_n_> _<_p_r_o_n_o_u_n_> _<_a_d_j_e_c_t_i_v_e_> _<_n_o_u_n_> 16 May 1993 46 AberMUD5(6) AberMUD5(6) Change the input that is being processed to match the sup- plied set of words. _C_O_M_M_A_N_D _<_v_e_r_b_> _<_i_t_e_m_1_> _<_p_r_o_n_o_u_n_> _<_i_t_e_m_2_> Change the input that is being processed to match the given words and items. The adjective noun pairs are taken from the items. _B_S_X_S_C_E_N_E _<_t_e_x_t_> Display the requested BSX scene. The scene must be present in the table of BSX images known to the game system. _B_S_X_O_B_J_E_C_T _<_n_u_m_b_e_r_1_> _<_n_u_m_b_e_r_2_> _<_t_e_x_t_> 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. _N_O_T Invert the logic of the following condition. Using not before an action makes it always fail (since an action always succeeds). _I_F_D_A_R_K True if the current location is dark after all light source rules have been computed. _V_I_S_I_B_I_L_I_T_Y _<_i_t_e_m_> _<_n_u_m_b_e_r_> Change the visibility of item to be number. The number is the minimum level to be able to perceive the item. _G_E_T_P_A_R_E_N_T _<_i_t_e_m_> _<_i_t_e_m_v_a_l_> 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. _G_E_T_N_E_X_T _<_i_t_e_m_> _<_i_t_e_m_v_a_l_> 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. _G_E_T_C_H_I_L_D_R_E_N _<_i_t_e_m_> _<_i_t_e_m_v_a_l_> Get the first thing contained within item. To walk along this list use GETNEXT after using GETCHILDREN. 16 May 1993 47 AberMUD5(6) AberMUD5(6) _P_E_X_I_T _<_n_u_m_b_e_r_> Print the name of an exit. The number matches the numbers for MOVE. _S_E_T_D_E_S_C _<_i_t_e_m_> _<_n_u_m_b_e_r_> _<_t_e_x_t_1_> _<_t_e_x_t_2_> _<_t_e_x_t_3_> 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. _S_E_T_L_O_N_G _<_i_t_e_m_> _<_t_e_x_t_1_> _<_t_e_x_t_2_> _<_t_e_x_t_3_> Set the long description of a room to the catenation of the three text strings. If item is not a room nothing hap- pens. _S_E_T_S_H_O_R_T _<_i_t_e_m_> _<_t_e_x_t_1_> _<_t_e_x_t_2_> _<_t_e_x_t_3_> Set the short description of a room to the catenation of the three text strings. If item is not a room nothing hap- pens. _G_E_T_L_O_N_G _<_i_t_e_m_> Set {$} to be the long description of room item. If it is not a room then nothing happens. _G_E_T_S_H_O_R_T _<_i_t_e_m_> Set {$} to be the short description of room item. If it is not a room then nothing happens. _G_E_T_D_E_S_C _<_i_t_e_m_> _<_n_u_m_b_e_r_> 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. _G_E_T_N_A_M_E _<_i_t_e_m_> Sets {$} to the name of item. _S_W_A_T Swaps {$} and {$2}. _F_L_A_T _<_f_l_a_g_> Sets {$} to the text for a flag in decimal. _F_I_N_D_M_A_S_T_E_R _<_n_u_m_b_e_r_> _<_i_t_e_m_v_a_l_> Loads either $1 or $2 with the first item anywhere in the 16 May 1993 48 AberMUD5(6) AberMUD5(6) database matching the vocabulary words for the either the first or second user adjective/noun pair. _N_E_X_T_M_A_S_T_E_R _<_i_t_e_m_> _<_n_u_m_b_e_r_> _<_i_t_e_m_v_a_l_> 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. _F_I_N_D_I_N _<_i_t_e_m_> _<_n_u_m_b_e_r_> _<_i_t_e_m_v_a_l_> 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. _N_E_X_T_I_N _<_i_t_e_m_1_> _<_i_t_e_m_2_> _<_n_u_m_b_e_r_> _<_i_t_e_m_v_a_l_> 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. _L_E_N_T_E_X_T _<_t_e_x_t_> _<_f_l_a_g_> Set flag equal to the length in characters of the text string. _P_R_O_C_S_U_B_J_E_C_T _<_i_t_e_m_> Using the current vocabulary and item values scan the sub- ject table of item, possibly including subclasses. _P_R_O_C_O_B_J_E_C_T _<_i_t_e_m_> Using the current vocabulary and item values scan the object table of item, possibly including subclasses. _P_R_O_C_D_A_E_M_O_N _<_i_t_e_m_> 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. _G_E_T_S_U_P_E_R _<_i_t_e_m_> _<_i_t_e_m_v_a_l_> Set either $1 or $2 to be the direct superclass of item. _S_E_T_S_U_P_E_R _<_i_t_e_m_1_> _<_i_t_e_m_2_> Set the direct superclass of item1 to be item2. All of the 16 May 1993 49 AberMUD5(6) AberMUD5(6) superclasses above that will change to be the superclasses of item2. _M_E_M_B_E_R _<_i_t_e_m_1_> _<_i_t_e_m_2_> True if item2 is one of the superclasses of item1. _C_L_S Clear the display. This may or may not do something. _I_S_C_L_A_S_S _<_i_t_e_m_> _<_c_l_a_s_s_f_l_a_g_> True if item has classflag set. _S_U_B_S_T_R _<_t_e_x_t_1_> _<_t_e_x_t_2_> True if text2 is a substring of text1. _G_E_T_I_N _<_i_t_e_m_> Set {$} to be the room entry message of item. _G_E_T_O_U_T _<_i_t_e_m_> Set {$} to be the room exit message of item. _G_E_T_H_E_R_E _<_i_t_e_m_> Set {$} to be the room description message of a player. _L_O_G _<_t_e_x_t_1_> _<_t_e_x_t_2_> _<_t_e_x_t_3_> 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. _S_E_T_C_L_A_S_S _<_i_t_e_m_> _<_c_l_a_s_s_f_l_a_g_> Set classflag of item. _U_N_S_E_T_C_L_A_S_S _<_i_t_e_m_> _<_c_l_a_s_s_f_l_a_g_> Clear classflag of item. _B_I_T_C_L_E_A_R _<_f_l_a_g_> _<_n_u_m_b_e_r_> Clear bit number of the flag. _B_I_T_S_E_T _<_f_l_a_g_> _<_n_u_m_b_e_r_> Set bit number of the flag _B_I_T_T_E_S_T _<_f_l_a_g_> _<_n_u_m_b_e_r_> 16 May 1993 50 AberMUD5(6) AberMUD5(6) True if bit number of flag is set. _S_P_R_I_N_T _<_f_l_a_g_> Set {$} equal to the decimal string representing flag. Equivalent to FLAT for historical reasons it is now iden- tical. _U_S_E_R _<_n_u_m_b_e_r_> _<_n_u_m_b_e_r_> _<_n_u_m_b_e_r_> _<_i_t_e_m_> _<_i_t_e_m_> _<_t_e_x_t_> Invoke a user compiled function. See the source code for details. _S_E_T_I _<_i_t_e_m_v_a_l_> _<_i_t_e_m_> Set either $1 or $2 to item. _C_D_A_E_M_O_N _<_i_t_e_m_> _<_v_e_r_b_> _<_n_o_u_n_> _<_n_o_u_n_> Send a DAEMON to every user contained within item. _D_E_L_E_T_E _<_t_e_x_t_> Delete the specified file. If the security define is set this action is forbidden. If the delete files the action returns false. _U_L_O_A_D _<_t_e_x_t_> _<_i_t_e_m_> 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. _U_S_A_V_E _<_t_e_x_t_> _<_i_t_e_m_> 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. _F_L_O_A_D _<_t_e_x_t_> _<_f_l_a_g_1_> _<_f_l_a_g_2_> 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. _F_S_A_V_E _<_t_e_x_t_> _<_f_l_a_g_1_> _<_f_l_a_g_2_> 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. 16 May 1993 51 AberMUD5(6) AberMUD5(6) _G_E_T_V_I_S _<_i_t_e_m_> _<_f_l_a_g_> Get the visibility (perception) of item and store it in flag. _M_E_S_S_A_G_E_T_O _<_i_t_e_m_> _<_t_e_x_t_> Output the text followed by newline to item. If item isn't a user then nothing happens. _M_S_G_T_O _<_i_t_e_m_> _<_t_e_x_t_> Output the text to item. If item isn't a user nothing hap- pens. _R_W_H_O_I_N_I_T _<_t_e_x_t_1_> _<_t_e_x_t_2_> _<_t_e_x_t_3_> _<_t_e_x_t_4_> 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. _R_W_H_O_D_O_W_N Tell the RWHO server the game is shutting down. _R_W_H_O_L_O_G_I_N _<_t_e_x_t_1_> _<_t_e_x_t_2_> 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. _R_W_H_O_L_O_G_O_U_T _<_t_e_x_t_> 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. _R_W_H_O_P_I_N_G Send an rwho keepalive packet. _S_E_T_E_X_I_T _<_i_t_e_m_1_> _<_n_u_m_b_e_r_> _<_i_t_e_m_2_> 16 May 1993 52 AberMUD5(6) AberMUD5(6) Set the exit in direction number from item1 to item2. Num- ber is an exit in the same form as MOVE. _D_E_L_E_X_I_T _<_i_t_e_m_> _<_n_u_m_b_e_r_> Delete the exit in direction number from item. Number is an exit in the same form as MOVE. _G_E_T_E_X_I_T _<_i_t_e_m_> _<_n_u_m_b_e_r_> _<_i_t_e_m_v_a_l_> Copy exit number of item into $1 or $2. If there is no exit it is set to no item. _F_O_R_K_D_U_M_P _<_t_e_x_t_> 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. 16 May 1993 53