pennmush-1.8.2p8/0000755000175000017500000000000010736360342013213 5ustar noltarnoltarpennmush-1.8.2p8/hints/0000755000175000017500000000000010736360341014337 5ustar noltarnoltarpennmush-1.8.2p8/hints/aix.sh0000644000175000017500000000003210417116361015444 0ustar noltarnoltarccflags="-D_BSD_INCLUDES" pennmush-1.8.2p8/hints/darwin.sh0000644000175000017500000000003710470552036016156 0ustar noltarnoltarusenm="n" cdecl='' so='dylib' pennmush-1.8.2p8/hints/win32.sh0000644000175000017500000000046410417116361015636 0ustar noltarnoltarcc=`pwd`'/utils/clwrapper.sh' ccflags='/DWIN32 /DNDEBUG /D_CONSOLE' ldflags='/MT' libs='libcmt.lib winmm.lib wsock32.lib advapi32.lib /link /NODEFAULTLIB:libc.lib /subsystem:console /incremental:no /pdb:PennMUSH.pdb /machine:I386' optimize='/O1' d_index='undef' d_strchr='define' usenm='n' has_fcntl='false' pennmush-1.8.2p8/hints/cygwin.sh0000644000175000017500000000031010467332225016166 0ustar noltarnoltar# Hints for cygwin, tested with 1.3.12-2 # Note that you need the exim-4.10-1 package so you can include # its minires files cc='gcc' ccflags='-I/usr/src/exim-4.10-1/minires' usenm='y' d_ipv6='undef' pennmush-1.8.2p8/hints/freebsd.sh0000644000175000017500000000025410470567123016310 0ustar noltarnoltarusenm=false i_malloc='undef' i_values='undef' ccflags='-D_POSIX_C_SOURCE=2 -D__XSI_VISIBLE=1000 -D__BSD_VISIBLE -I/usr/local/include' d_attribut=true d_force_ipv4='define' pennmush-1.8.2p8/hints/dec_osf.sh0000644000175000017500000000007710417116361016276 0ustar noltarnoltarccflags="-taso" echo "You will want to use the native malloc." pennmush-1.8.2p8/hints/os2.sh0000644000175000017500000000025210417116361015372 0ustar noltarnoltar# Hints for OS/2, based on Sylvia's reports of the few config.h # tweaks she's had to do d_random='define' d_lrand48='define' d_gettblsz='define' tablesize='ulimit(4,0)' pennmush-1.8.2p8/hints/irix_6.sh0000644000175000017500000000020510556616672016103 0ustar noltarnoltarloclibpth="/usr/local/lib /usr/gnu/lib /usr/lib32 /usr/lib /lib" libs="-lc -lm" has_sigchld='define' has_sigcld='define' nm_opt="-B" pennmush-1.8.2p8/hints/openbsd.sh0000644000175000017500000000012310467317431016324 0ustar noltarnoltarusenm=false inclwanted='/usr/local/include' i_malloc='undef' d_force_ipv4='define' pennmush-1.8.2p8/hints/hpux.sh0000644000175000017500000000021710417116361015654 0ustar noltarnoltarccflags="-w +Obb800 -Aa -D_INCLUDE_POSIX_SOURCE -D_INCLUDE_HPUX_SOURCE -D_INCLUDE_XOPEN_SOURCE -D_INCLUDE_AES_SOURCE -D_XOPEN_SOURCE_EXTENDED" pennmush-1.8.2p8/hints/solaris_2.sh0000644000175000017500000000015010467317431016567 0ustar noltarnoltarccflags="-DNO_SIGCONTEXT" libs="-lnsl -lsocket -lm -lc -lresolv" i_fcntl="define" has_sigchld="define" pennmush-1.8.2p8/hints/a-u-x.sh0000644000175000017500000000003310417116361015613 0ustar noltarnoltarccflags="-ZB" libs="-lbsd" pennmush-1.8.2p8/hints/mingw32.sh0000644000175000017500000000006510470545736016172 0ustar noltarnoltarcc='gcc' usenm='n' libs='-lwsock32' osname='mingw32' pennmush-1.8.2p8/hints/win32-gcc.sh0000644000175000017500000000016310467330367016375 0ustar noltarnoltar# Hints for win32 with gcc cc='gcc' ccflags='-DWIN32' usenm='n' h_fcntl='false' d_ipv6='undef' d_setlocale='undef' pennmush-1.8.2p8/hints/ultrix.sh0000644000175000017500000000002510417116361016214 0ustar noltarnoltarccflags="-DOLD_ANSI" pennmush-1.8.2p8/hints/linux_2.sh0000644000175000017500000000020510470555520016250 0ustar noltarnoltarnm_opt='-B' ccflags='-D__USE_POSIX' libswanted='nsl m c crypt intl resolv' echo "I suggest using sysmalloc when you edit options.h." pennmush-1.8.2p8/hints/irix.sh0000644000175000017500000000004010417116361015635 0ustar noltarnoltarccflags="-woff 651" nm_opt="-B" pennmush-1.8.2p8/hints/hpux-gcc.sh0000644000175000017500000000021110467317431016406 0ustar noltarnoltarcc="gcc" ccflags="-D_INCLUDE_POSIX_SOURCE -D_INCLUDE_HPUX_SOURCE -D_INCLUDE_XOPEN_SOURCE -D_INCLUDE_AES_SOURCE -D_XOPEN_SOURCE_EXTENDED" pennmush-1.8.2p8/hints/next.sh0000644000175000017500000000026410417116361015650 0ustar noltarnoltarccflags="-W -Wreturn-type -Wunused -Wswitch -Wshadow -Wwrite-strings" echo echo "NeXT note: You may have to use the native malloc rather than" echo "smalloc.c or gmalloc.c" echo pennmush-1.8.2p8/hints/sunos_4.sh0000644000175000017500000000003610417116361016261 0ustar noltarnoltarccflags="-DSUN_OS -DOLD_ANSI" pennmush-1.8.2p8/hints/darwin-fink.sh0000644000175000017500000000013310470567123017103 0ustar noltarnoltarusenm="n" cdecl='' so='dylib' osname='darwin' loclibpth='/sw/lib' ccflags='-I/sw/include' pennmush-1.8.2p8/Patchlevel0000644000175000017500000000014310736221745015226 0ustar noltarnoltarDo not edit this file. It is maintained by the official PennMUSH patches. This is PennMUSH 1.8.2p8 pennmush-1.8.2p8/BUGS0000644000175000017500000000151010527055516013675 0ustar noltarnoltarBugs that aren't our fault, but might bite people: Modern: * You might experience crashes because the default executable stack size is too small. An 8 megabyte stack is more than ample. On unix, it can be raised with 'ulimit -s 8192'. On Windows, you must use the editbin progam that comes with MS development environments to raise the stack on a per-executable basis, via 'editbin /STACK:8388608 netmush.exe' Ancient: * Ralph Melton reports that compiling with gcc 2.5.8 under SunOS 4.1.1 using -O optimization and forking dumps causes the dump process to crash. Removing -O fixes the problem; so might using a more recent gcc. * Javelin has confirmed that compiling with gcc 2.7.2.3 under Linux 2.2.16 using -O optimization causes ansi(rh,a) to crash. Removing -O fixes the problem; so might using a more recent gcc pennmush-1.8.2p8/UPGRADING0000644000175000017500000002537710736221745014477 0ustar noltarnoltar============================================================================ Upgrading to PennMUSH 1.8.x ============================================================================ This file explains how to upgrade to a new version of PennMUSH. There are three basic upgrade situations: A. You're running a stock ("vanilla") PennMUSH server of some version and you want to upgrade to a later version B. You've hacked your server source code a little bit here and there (adding a flag, for example). Hacks to the *local.c files don't count as hacks, as they're easy to handle. C. You've hacked your server source code a lot. There is also a list of upgrade "GOTCHAS" at the end of this file. Please read them. The PennMUSH developers actually only support situation A, but we'll give some useful tips for B and C here, too. DISCLAIMER: It is very wise to always back up your current working MUSH directories before you try an upgrade. You were warned. ============================================================================ A. Vanilla upgrade You have basically two choices here: upgrade with patch files, or build a whole new distribution. A.1. Upgrading with patch files This is the easiest way to upgrade your source code if you're keeping up with patches as they come out, or if you're upgrading patchlevels within a release (e.g., within 1.8.0). To upgrade with patch files, get all the patch files for higher patchlevels than your current version. For example, if you're running 1.8.0p0 and the latest version is 1.8.0p4, you need patches 1-4. These files are stored at http://ftp.pennmush.org/Source and usually named things like 1.8.0-patch02 (the patch from 1.8.0p1 to 1.8.0p2) or, in some cases, 1.7.6p16-1.8.0p0.patch (the patch from 1.7.6p16 to 1.8.0p0). Each patch file contains instructions at the top explaining how to apply it. FOLLOW THESE! Don't assume they're all the same. After you've applied all the patches and followed all the instructions, you should be good to go. In most cases, you can simply @shutdown/reboot after the final successful compile. If @shutdown/reboot crashes, you'll have to restart again. A.2. Building a new distribution When you're upgrading across release and no patchlevel is provided to make the upgrade (e.g. from 1.7.4p3 to 1.8.0p0), it's often easier to simply build a new distribution following the INSTALL instructions, but with your old configuration stuff. Move your older version of PennMUSH in a directory called oldpenn/, unpack the new one (it will unpack into pennmush/). All of the steps below should be taken before running Configure for the new version: A.2.a. options.h and game/*.cnf You can copy the options.h file and game/mush.cnf file from your old version to the new version. The 'make update' command (run after Configure) will compare your files with the newly distributed ones and tell you about options that have been added or removed. If you have any options defined that the new version doesn't recognize, you'll be asked if you want to retain them (which is safe). If your mush.cnf file is called something else, copy it to mush.cnf in pennmush/game anyway, since that's the file that gets updated. Then make a link to that file called whatever.cnf if you want to use that. If you've modified the restart script, you'll have to decide if your modified script is still appropriate, or modify a copy of the distributed game/restart script as you like it. it is highly recommended that you copy restart to a second file, called something like restart.local, and modify and use it instead of the stock restart script to reduce conflicts when patching. You can also copy your old game/access.cnf, game/sitelock.cnf, and game/txt/*.txt files into the appropriate locations. You may wish to do the same thing for game/restrict.cnf, but you should compare it to the new version, as restrictions that may formerly have been compiled into the server may now be specified in restrict.cnf instead. A.2.b. src/*local.c You should copy local.c, cmdlocal.c, and funlocal.c from oldpenn/src to pennmush/src if you want to retain this local code. Of course, it may not still work, but it's quite likely that it will. If you don't have any such code, you can skip this step. A.2.c. Databases This MUSH version should read databases along the main branch of MUSH evolution -- TinyMUD, vanilla TinyMUSH up to 2.0, MicroMUSH, and all Pern/PennMUSH versions. If you need to convert a TinyMUSH 2.0 database, please contact Amberyl, and she'll mail you an extension to 2.0 that will dump a 1.50-readable flatfile. You're probably out of luck with databases for TinyMUSH 2.2 and later. Be sure that your options.h settings correctly reflect the type of password encryption that was used on your database. The default has changed to SHS, so if your db used crypt(3) encryption, be sure you set the appropriate definition in options.h. *** If you are upgrading from 1.7.4 (or earlier) to 1.7.7 (or later), *** you must first load your old database under PennMUSH 1.7.6 and *** then dump it, and load this converted database under your *** target version of PennMUSH. PennMUSH 1.7.7+ can no longer read *** 1.7.4 databases. *** If you are upgrading from 1.7.6 or certain 1.7.7 versions, *** you may also first need to load your database under PennMUSH *** 1.8.0p13 and then dump it, and load this converted database *** under your target version of PennMUSH. ============================================================================ B. PennMUSH with a few hacks When you have only a few local hacks outside of the src/*local.c files, you can often patch up using the patch file method discussed above. Alternatively, you can build a new version and reapply your changes. One small exception is upgrading from a version that used the old flag system to one that uses the new flag system (post-1.7.7p5), if you've added flags or toggles. You probably had an #define in hdrs/flags.h for your flag's bit value. This now should be moved to hdrs/oldflags.h; you should leave in the table entry in src/flags.c. If you set up a macro for testing your flag in hdrs/mushdb.h, you'll need to change it to use the has_flag_by_name() function - see the many examples in that file. If this isn't suitable (you're crossing releases or your hacks are too many for this to work cleanly), see below. ============================================================================ C. PennMUSH with a lot of hacks If you've seriously hacked your server source code, you're on your own in terms of keeping up with new patchlevels. Some people apply patchfiles and fix the rejected hunks. A better approach is probably that described in the Guide for Gods, and involves creating a set of patches from the distributed old version of pennmush (e.g. 1.7.4p16) to your hacked version of pennmush (e.g. 1.7.4p16 with hacks), and then applying those patches to the new version of PennMUSH (e.g. 1.8.0p0) to create a hacked version thereof. If some patch hunks fail, you'll have to apply them manually. Probably the best approach is to keep all multiple versions of the code (old distributed, old hacked, new distributed, new hacked) under a source code control system like prcs that can merge changes between versions. See the Guide for Gods. ============================================================================ IMPORTANT NOTES FOR THOSE UPGRADING TO 1.8.0 FROM 1.7.6: * Softcode gotchas: * Wizards (other than God) and royalty are no longer treated as No_Pay unless the No_Pay power is explicitly set on them, although they can still give (themselves or others) as many pennies as they wish. This helps stop runaway wizards in the queue (they'll run out of cash like anyone else). To get the old behavior back, @power your admin No_Pay. You probably want to @power any globals that use search(), children(), mail*stats(), etc, No_Pay as well. * @desc can no longer be gotten remotely without privileges. @desc on privileged objects can now be evaluated by mortals. * @adisconnect is triggered on every disconnection, partial or full. This mirrors the behavior of @aconnect. Use %1 (the number of remaining connections) to distinguish between partial and full disconnects in @adisconnect code. * Players can no longer be set CHOWN_OK. If you have existing CHOWN_OK players, you probably want to unset this from them, or the results will be confusing (they'll continue to appear to have the flag, even though it won't be testable or settable or clearable; this is desired behavior). * New HEAVY admin flag, prevents an object from being teleported by a mortal between two containers they own. Admin without this flag CAN be teleported. * Hardcode/db/startup gotchas: * After each @startup is enqueued (during startup or @restart/all), we immediately run up to 5 queue cycles. This allows, e.g., God's @startup to up to five levels of @dol/@tr/@switch/etc and still have the queued code run ahead of other startups. This requires that you keep God's dbref as #1. * netmush is now started with only a single argument - the path to the configuration file. The error log file (typically game/netmush.log is now configured in mush.cnf. * CHAT_SYSTEM option removed. If you don't want to use the chat system, use restrict.cnf to disable @channel, @chat, etc. * USE_MAILER and MAIL_ALIAS options removed. If you don't want to use the @mail or @malias systems, use restrict.cnf to disable the associated commands. * QUOTA, EMPTY_ATTRS, and FUNCTION_SIDE_EFFECTS options are now runtime options, instead of compile-time. * SINGLE_LOGFILE option removed, and log filenames are now runtime options. You may now give the same name to multiple log files and get a more fine-grained version of the same effect. * src/Makefile is now autobuilt from src/Makefile.SH. IF you use local hacks that require src/Makefile, this is likely to be a problem for you. You'll want to start patching Makefile.SH instead. * The new code can no longer read databases created by versions of Penn before 1.7.5p0. If you need to do this, load it in 1.7.6, shutdown, and use that database. * PROFILING #define for use when profiling the code (surprise). This just disables the CPU timer. * help-like commands without arguments now use the command name as the argument. E.g. 'news' now looks for topic 'news', instead of 'help'. If not found, we fall back on help. * Mail messages now track not only the dbref of the sender but the sender's creation time, so messages from dbrefs that have been nuked and recreated can be distinguished from messages from the original sender. This modifies the maildb and make it not usable with older versions. All existing @mail is grandfathered in, and can't be tracked this way. pennmush-1.8.2p8/options.h.dist0000644000175000017500000001241210663656044016027 0ustar noltarnoltar/* options.h */ #ifndef __OPTIONS_H #define __OPTIONS_H /* *********** READ THIS BEFORE YOU MODIFY ANYTHING IN THIS FILE *********** */ /* WARNING: All options in this file have the ability to significantly change * the look and feel and sometimes even internal behavior of the program. * The ones shipped as the default have been extensively tested. Others have * been tested to a (usually) lesser degree, and therefore might still have * latent bugs. If you change any of them from the default, PLEASE check * to make sure that you know the full effects of what you are changing. And * if you encounter any errors or compile time problems with any options * other than the default settings, PLEASE inform * pennmush-bugs@pennmush.org * immediately, so that they can be fixed. The same goes for any other bug * you might find in using this software. All efforts will be made to fix * errors encountered, but unless given a FULL description of the error, * (IE telling me that logging in doesn't work is insufficient. telling * me that logging in with WCREAT undefined still gives you the registration * message is a lot better. MOST effective would be a full dbx trace, or a * patch for the bug.) Enjoy using the program. */ /***************************************************************************/ /*---------------- Internals with many options ------------------------*/ /* Malloc package options */ /* malloc() is the routine that allocates memory while the MUSH is * running. Because mallocs vary a lot from operating system to operating * system, you can choose to use one of the mallocs we provide instead of * your operating system's malloc. * Set the value of MALLOC_PACKAGE to one of these values: * 0 -- Use my system's malloc. Required for Win32 systems. * Recommended for FreeBSD, Linux, Mac OS X/Darwin, and other OS's * where you think the malloc routines are efficient and debugged. * In other words, pretty much any fairly current OS releases. * 1 -- Use the CSRI malloc package in normal mode. * Recomended for ancient OS releases. On anything modern, you'll want * the system malloc (Option 0). * 2 -- Use the CSRI malloc package in debug mode. * Only use this if you're tracking down memory leaks. Don't use * for a production MUSH - it's slow. * 3, 4, 5, 6 -- Same as 0, kept for compatibility. */ #define MALLOC_PACKAGE 0 /* What type of attribute compression should the MUSH use? * Your options are: * 1 - the default Huffman compression which has been in use for a * long time. In theory, this should be the best compression, * possibly at the cost of some speed. It is also 8-bit clean, * and thus suitable for locales that use extended character sets. * Sometimes has trouble on some linux systems for some reason. * 2 - Same as 1, for backwards compability. * 3 - Nick Gammon's word-based compression algorithm. * In theory, this should be considerably faster than Huffman * when decompressing, and considerably slower when compressing. * (But you decompress a lot more often). Compression ratio * is worse than Huffman for small dbs (<1.5Mb of text), but * better for larger dbs. * 4 - Raevnos's almost 8-bit clean version of the word-based algorithm. * Prefer 3 unless you need extended characters. This algorithm * can encode all characters except 0x06. * 0 - No compression at all. Very fast, but your db in memory * will be big - at least as large as your on-disk db. * Possibly suitable for the building stages of a small MUSH. * This should be 8-bit clean, too. * You can change this at any time, with no worries. It only affects * the in-memory compression of attribute/mail text, not the disk * db compression. Recommend to keep it at 1. When in doubt, try them * all, and check @uptime's memory usage stats for the most efficient * choice among those that are stable for you. When using word-based * compression, you can also #define COMP_STATS to get some detailed * information in @stats/tables. */ #define COMPRESSION_TYPE 1 /*------------------------- Other internals ----------------------*/ /* If defined, use the info_slave to get information from identd, * instead of having the MUSH do it directly. This may help reduce lag * from new logins. This does _not_ work under Win32. */ #define INFO_SLAVE /* */ /*------------------------- MUSH Features ----------------------*/ /* Many MUSHes want to change the +channels to =channels. That's * annoying. So we've got this CHAT_TOKEN_ALIAS, which allows + as well * as = (or whatever) channels. If you want this, define it to be * the character you want to use in addition to +, enclosed in * single quotes, as in '=' or '.' or whatever. Don't define it to '+'! */ /* #define CHAT_TOKEN_ALIAS '=' /* */ /*------------------------- Cosmetic Features --------------------*/ /* If you're using the email registration feature, but want to * use a mailer other than sendmail, put the full path to the mailer * program here. The mailer must accept the -t command-line * argument ("get the recipient address from the message header To:"). * If it doesn't, you could probably write a wrapper for it. * Example: #define MAILER "/full/path/to/other/mailer" */ /* #define MAILER "" /* */ #endif pennmush-1.8.2p8/game/0000755000175000017500000000000010736360342014124 5ustar noltarnoltarpennmush-1.8.2p8/game/log/0000755000175000017500000000000010736360342014705 5ustar noltarnoltarpennmush-1.8.2p8/game/log/README0000644000175000017500000000005010417116361015554 0ustar noltarnoltarServer log files are usually kept here. pennmush-1.8.2p8/game/mushcnf.dst0000644000175000017500000006625010644322121016303 0ustar noltarnoltar# configuration file for PennMUSH # # The directives in this file control the behavior of your MUSH # If you change any of them while your MUSH is running, you can # cause the MUSH to re-read this file by sending it a SIGHUP # signal. Typically, one does this by using 'ps' to determine the # MUSH's process id#, and then issuing a: kill -1 pid# # command. #### #### ESSENTIALS #### # Name of your MUSH. Please change this. mud_name TinyMUSH # The port it's running on. See also ssl_port, later. port 4201 # Should we listen only on a specific IP address? If your host has # multiple IP addresses, put the ip address to listen on here # Example: ip_addr 128.32.243.78 # Otherwise, just leave it blank. ip_addr # Should the MUSH attempt to resolve IP numbers to hostnames? # If yes, you'll see hostnames on the wizard WHO. If no, IP numbers. # No makes sense if you're running PennMUSH at home and don't have # a DNS server you can access. MacOS 7/8/9 should use 'no' # Changing this while using info_slave requires a @shutdown/reboot # to make it take effect. use_dns yes # Databases # These are, respectively, where to read a database, where to # write a database, where to put a panic dump (performed if # the MUSH determines it's going to crash, where to put MUSH mail, # and where to keep information about the chat system. # Filenames are relative to the game/ directory. # # Do NOT put compression suffixes at the end of the files. # That's handled below # input_database data/indb output_database data/outdb crash_database data/PANIC.db mail_database data/maildb chat_database data/chatdb # Database compression # When your databases are dumped, they can be dumped in a compressed # format to save disk space, or uncompressed for speed. # To use a compression program, you must know the name of the # program that compresses, the name of the program that uncompresses, # and the suffix that the compression program adds. # # Most people can just use one of the following: # # Use these 3 lines for no compression. Required on win32 and MacOS 7/8/9. #compress_program #uncompress_program #compress_suffix # # Use these 3 lines for gzip compression #compress_program gzip #uncompress_program gunzip #compress_suffix .gz # # Use these 3 lines for Unix compress compression #compress_program compress #uncompress_program uncompress #compress_suffix .Z # # Use these 3 lines for bzip2 compression #compress_program bzip2 #uncompress_program bunzip2 #compress_suffix .bz2 # compress_program gzip uncompress_program gunzip compress_suffix .gz # Room where new players are created. player_start 0 # The master room. Exits here are global, as are commands on # objects here. master_room 2 # The base room. Any room that can be reached from this room # through exits is considered a 'connected room'. # See also: exits_connect_rooms base_room 0 # The ancestor room. This dbref serves as an 'ultimate parent' to # all rooms that aren't set ORPHAN. Set to -1 to disable. ancestor_room -1 # The ancestor exit. This dbref serves as an 'ultimate parent' to # all exits that aren't set ORPHAN. Set to -1 to disable. ancestor_exit -1 # The ancestor thing. This dbref serves as an 'ultimate parent' to # all things that aren't set ORPHAN. Set to -1 to disable. ancestor_thing -1 # The ancestor player. This dbref serves as an 'ultimate parent' to # all players that aren't set ORPHAN. Set to -1 to disable. ancestor_player -1 # The default home. This is the room used when an object becomes # homeless (usually due to its home getting destroyed). It's also # the place where things get moved to if their location gets # unsalvageably corrupted. default_home 0 # What's the filename of the @sitelock file, that controls # who can connect and who can't access_file access.cnf # Where are the names you want to ban players from # creation/rename? A good idea to start with are swear words, # and features names like 'Luke', 'Merlin', 'Gandalf', 'Picard', # 'Lessa', 'Dracula', 'Hercules', 'Scooby', 'Nancy Drew', etc, # depending on what type of MUSH you are running names_file names.cnf ### ### Attribute (chunk) cache ### ### PennMUSH can swap rarely-referenced attribute text out to a disk ### file, and cache often-used attribute text in memory. This ### can result in substantial (typically 30-50%) savings ### in process memory use, at the cost of a very small performance hit. ### You can control the size of memory cache (or set it so large ### that nothing is ever swapped to disk), as well as several less ### important parameters here. ### # The file to store the attribute data in, when not in memory. # This is relative to the game/ directory. chunk_swap_file data/chunkswap # The amount of memory allowed for the attribute cache, in bytes. # The actual amount used will be a multiple of 64K slightly less # the specified amount. You must give it at least 132000 bytes. # If you want to use an 'infinite' cache, try setting this # to 2000000000; you'll lose the memory benefits, but you'll still # gain some locality benefits and overhead savings. chunk_cache_memory 1000000 # The number of attributes that may be moved at one time, once per # second. The higher the value, the faster memory gets defragmented, # but at a greater CPU cost. chunk_migrate 50 ### ### SSL support ### # The port to listen on for SSL connections. This must be an unused # port other than the standard connection port. To disable SSL # connections, leave this set to 0. ssl_port 0 # The ip address to bind to for the SSL port, if one is specified. # If your host has multiple IP addresses, put the ip address to # listen on here. Otherwise, leave it blank to listen on all # addresses if SSL is in use. ssl_ip_addr # The file containing the MUSH server's certificate and private key, # concatenated together, and with no password on the private key. # Obviously, this file should only be readable by the MUSH account # owner. If this is commented out, the server will not present a # certificate, so clients that attempt to authenticate the server # will fail. ssl_private_key_file server-key.crt # The file containing one or more certificates of certifying authorities # that the server should trust to certify clients who connect and # present certificates. A standard bundle of these is distributed # with openssl as 'ca-bundle.crt'. If commented out, the server will # not attempt client authentication. ssl_ca_file /usr/share/ssl/certs/ca-bundle.crt # Are clients *required* to present a valid certificate in order to # make an SSL connection? ssl_require_client_cert no ### ### Limits, costs, and other constants ### # name of the monetary units money_singular Penny money_plural Pennies # Should there be a limit on how long players can be idle? # If you want one, set idle_timeout to the # number of MINUTES # a player may idle before getting disconnected. # If you don't want a timeout, set it to 0. idle_timeout 0m # Should there be a limit on how long connections at the connect screen # (without an associated player) can be idle? # If you want one, set unconnected_idle_timeout to the # number of MINUTES # a connection may idle before getting disconnected. # If you don't want a timeout, set it to 0. unconnected_idle_timeout 5m # Many common home network routers will drop a connection if there's # been no activity for a few minutes; they tend to assume the web is # the internet, and don't deal well with persistant connections like # mushes use. This option will make the server automatically send a # TCP-level 'Are you still there?' query every few minutes to keep the # connection active. # NOTE: This doesn't work on all OSes, but does some of the most popular # ones for mush hosting such as linux. Other options include the KEEPALIVE # flag and the IDLE command. keepalive_timeout 5m # Should there be a limit on the number of logins the MUSH # can accept? If your operating system has a limited number of # file descriptors per process, you should set this to # that number - 8. If not, or if you like to live dangerously, # set this to 0. max_logins 120 # Should there be a limit on the number of concurrent guest logins the MUSH # will allow? This option can take 3 values: # 0 = no limit, any number of guests. Logins beyond the number of established # guest characters will result in multiple players being logged into the # same guest character. # -1 = limited to the number of guests in the database. To allow more guests # to log in, create more guest characters. # Any other number = the number of guest connections allowed at once. max_guests 0 # How much MUSH money do players get when they're created? starting_money 150 # How much MUSH money do non-guest players get each day they log in? paycheck 50 # How much MUSH money do guests get each day they log in? guest_paycheck 0 # What's the most money anyone but guests can have? max_pennies 100000 # What's the most money guests can have? max_guest_pennies 1000 # If quotas are enforced, how much players get by default starting_quota 20 # number of commands a player can have queued. Prevents runaway machines # from getting out of hand. player_queue_limit 100 # the number of commands run from the queue when there is no net activity queue_chunk 3 # the number of commands run from the queue when there is net activity active_queue_chunk 1 # the maximum level of recursion allowed in functions function_recursion_limit 50 # the maximum number of functions that can be invoked function_invocation_limit 2500 # the maximum depth we're allowed to recursively call the parser # for a single expression. This limits how much the stack size can increase, # which could be useful if your host limits your stack (it will prevent # a crash). The higher your allowed stack size limit, the larger the # mush process can grow, and the higher this can be set. Generally # speaking, you won't ever see more than 8192 recursions, so that's # probably an upper limit, but most sane code shouldn't need more # than a couple hundred. Setting it to '0' means unlimited. call_limit 100 # The maximum number of milliseconds of CPU time that a single queue entry # is allowed to use before aborting. Setting this to a low number will # help prevent many malicious attacks, as well as accidently bad code, # from lagging the game. Setting it to 0 means unlimited, and is a bad # idea. Remember there are 1000 milliseconds in a second. queue_entry_cpu_time 1500 # How many channels total can be created? # This doesn't allocate memory, it just sets a maximum. max_channels 200 # How many channels can each non-admin create? Set this to some number # higher than zero to allow mortals to create channels. max_player_chans 0 # What's the maximum number of levels of parenting allowed max_parents 10 # What's the max chain length of indirect locks allowed? max_depth 10 # How many @functions can we have? If you change this without # doing a # shutdown (or shutdown/reboot) immediately thereafter, you'll very likely # crash your MUSH, so don't do that. max_global_fns 50 # How much does it cost a mortal to create a channel? chan_cost 1000 # How likely should it be that noisy whispers are noticed by other # players in the room? (Others see: John whispers to Mary.) # Use a number from 0 to 100 whisper_loudness 100 # the highest allowable dbref -- you can't build more than this # many objects. if you don't want such a limit, leave this set # to 0. max_dbref 0 # The maximum number of attributes per object. This prevents # denial-of-service attacks involving creating an infinite number # of attributes on an object. This value is probably enough. max_attrs_per_obj 2048 # The maximum number of mail messages in each player's inbox. # Encourages people to clean up their inbox, discourages # mailspammers. mail_limit 300 # If you kill someone, you can spend up to 100 coins; the chance # of killing them is the number of coins you spend. What's the # minimum number of coins that must be spent, and the default # number if no number is given? kill_min_cost 10 kill_default_cost 10 # If you kill someone, they get paid off. The payoff is this # percentage of the amount you spent to kill them. The usual is 50%. kill_bonus 50 # How much to various commands cost: find_cost 100 page_cost 0 # How many objects are equal to 1 quota, if quotas are used quota_cost 1 # How much deposit is required to queue a command? queue_cost 10 # One out of how many commands that are queued will cost the # player a coin? Setting this to 1 causes a coin to be lost with # every command. Setting it to 0 disables coin loss for queued # commands (and is a very bad idea). queue_loss 63 # What does it cost to build various things? room_cost 10 object_cost 10 link_cost 1 exit_cost 1 # How often should we run a purge to remove destroyed objects? (seconds) purge_interval 10m1s # How often should we run a dbck to check db consistency? (seconds) dbck_interval 9m59s # How often should we perform topology warning checks? # Default is 1 hour. If you set this to 0, timed MUSH-wide checks # will be disabled, but players can still use @wcheck. warn_interval 1h # If compiled with FLOATING_POINTS support, this controls the # decimal precision of numbers. Default is 6 digits after the # decimal point. float_precision 6 # The password that must be given to do an @logwipe. You must also # be God, of course. CHANGE THIS. log_wipe_passwd zap! # The maximum length of player names. Lowering this won't change # current player names. This number should be one greater than the # actual maximum length you want. player_name_len 16 # The maximum number of aliases a player may have simultaneously. # Setting this to 0 disables aliases. To allow an unlimited number # of aliases, set this to 4000 or so. max_aliases 3 # Limit the number of objects players can own. use_quota yes ### ### Dump stuff ### # How often should the database be dumped, in seconds? # 3600 is once an hour, and probably the most frequent you'd ever want. # On a large MUSH, consider at most once every 3-6 hours. # This cannot be a multiple of any of the timer.c parameters # (so keep it an even number of hours). dump_interval 1h # should I fork a concurrent process to do database dumps? # If I do, your memory requirements will double during the dump. # If I don't, the MUSH will pause while it dumps. # If you're low on memory, don't do this. # If you're on Win32, don't do this; fork() is not defined. forking_dump yes # If you're not forking, you get a bunch of messages that you # can set to warn players when the dump is 5 minutes away, # 1 minute away, in progress, and finished. You can # leave messages you don't want blank, but don't comment # them out or remove them from the file or you'll get the # default messages. dump_warning_5min GAME: Database save in 5 minutes. dump_warning_1min GAME: Database save in 1 minute. dump_message GAME: Saving database. Game may freeze for a few moments. dump_complete GAME: Save complete. ### ### Filenames ### # Text files shown on connection, as message of the day, # as wizard message of the day, on quit, to newly created players, # when logins are disabled, when player creation is disabled, # and when a guest logs in. connect_file txt/connect.txt motd_file txt/motd.txt wizmotd_file txt/wizmotd.txt quit_file txt/quit.txt newuser_file txt/newuser.txt down_file txt/down.txt register_create_file txt/register.txt guest_file txt/guest.txt full_file txt/full.txt # The equivalent files in html, shown to Pueblo clients. connect_html_file txt/connect.html motd_html_file txt/motd.html wizmotd_html_file txt/wizmotd.html quit_html_file txt/quit.html newuser_html_file txt/newuser.html down_html_file txt/down.html register_create_html_file txt/register.html guest_html_file txt/guest.html full_html_file txt/full.html # The big text files. New ones can be added by setting up # a new subdirectory of game/txt as described in game/txt/README, # and adding a new help_command line below, or uncommenting one of # the normal file entries. #help_command events txt/events.txt #help_command index txt/index.txt #help_command rules txt/rules.txt #help_command +help txt/plushelp.txt help_command help txt/help.txt help_command news txt/news.txt ahelp_command ahelp txt/help.txt restrict_command ahelp admin ahelp_command anews txt/news.txt restrict_command anews admin ### Config directive for IDENT. ### If you want to do ident (RFC1143) lookups, set use_ident to "yes" ### and select an ident_timeout to determine how long the MUSH ### should wait for a response, in seconds. If you're using ### INFO_SLAVE (in options.h), this is how long the info_slave waits. # Changing this while using info_slave requires a @shutdown/reboot # to make it take effect. use_ident yes ident_timeout 5s ### ### Logging ### ### When selecting log files, you may assign multiple logs to the ### same filename. If you don't assign a filename to a log, ### messages are written on stderr instead (usually redirected to ### log/netmush.log). Probably unwise to change these in a running ### MUSH. ### # Filename to log important messages (startups, errors, shutdowns) error_log log/netmush.log # Filename to log connections to connect_log log/connect.log # Filename to log wizard commands to wizard_log log/wizard.log # Filename to log dump checkpoint messages to checkpt_log log/checkpt.log # Filename to log debugging trace messages to trace_log log/trace.log # Filename to log commands by SUSPECT players to command_log log/command.log # log all commands. Makes big, big command.log files. Use only for # debugging, generally. log_commands no # log forces done by wizards log_forces yes # perform memory allocation tracking (logged on @dump) to help find # memory leaks. This really shouldn't be changed while the server # is running - it's only useful if you do a full shutdown, turn # this on, and then start up. Generally, you want this off. mem_check no ### ### Logins ### # Support the pueblo MUSH client and allow html to be sent to it pueblo no # allow non-wizard/royalty logins logins yes # allow guest logins guests yes # allow players to create/register characters at the login screen # If you turn this off, neither "create" nor "register" will work. # Use access.cnf if you want to disable creation for specific sites # or disable creation but enable registration for everyone. player_creation yes # If you use the shs password system, and your database was created # on a little-endian hardware architecture (such as an intel PC), # set this to 'yes'. If your database was created on a big-endian # hardware architecture (most non-intel systems), set this to 'no'. # If you port a db with shs passwords between systems, and the # passwords don't work, try changing this setting. reverse_shs yes # trigger @aconnect/@adisconnect in a connecting player's location # if the location is a room or thing? room_connects no ### ### SQL connectivity ### # What SQL server platform should we use? Options include: # mysql, disabled (the default) sql_platform disabled # What's the SQL hostname? Use '127.0.0.1' for a TCP connection # to the local host, and 'localhost' for a domain socket connection. sql_host 127.0.0.1 # What's the SQL database? You have to set this to a database that # you create. sql_database mush # What username to access the database? sql_username mush # What password for that user? Change this! sql_password mush ### ### Options affecting commands and functions ### (See also restrict_command to restrict command use) ### # The old daytime directive is better suited to restrict_command # or @command/disable. # prevent objects from evaluating ufuns on more privileged objects. [++] safer_ufun yes # allow functions that have side effects? (e.g. dig(), etc.) function_side_effects yes # default whisper to whisper/noisy instead of whisper/silent noisy_whisper no # is possessive get (get players's object) allowed? possessive_get yes # what if the player is disconnected? possessive_get_d no # SAFE absolutely prevents destruction, even with @nuke really_safe yes # With this turned on, ZMRs and ZMOs are not included in control # checking. Only Zone Master Players are. The other zone types are # still used for command-matching, just not for control purposes. # Highly recomended. zone_control_zmp_only yes # When a player is nuked, his SAFE objects are @chowned to God. # If this is set to "yes", his non-safe objects are destroyed # If this is set to "no", they are chowned to God destroy_possessions yes # Can we @link to an object? link_to_object yes # Keep queue limits on a per-owner rather than per-object basis? # That is, is an object runaway when its owner's total queue is too # high, rather than when the object's queue is too high? owner_queues no # If this is yes, DARK wizards do not trigger AENTER/ALEAVE when they move. # If it's no, they are just like anybody else. wiz_noaenter no # should say/pose by a DARK wizard be anonymous ('Someone says...')? full_invis no # Are empty attributes preserved? If this is yes, you can do # &ATTR obj= and obj will have an attribute ATTR set, with an empty value. # If this is no, that same command would clear the attribute instead. empty_attrs yes ### ### TinyMUSH compatibility ### # Should we treat a missing number as 0 in things like add(3,)? # For TinyMUSH compatibility, the answer is 'no'. null_eq_zero no # In PennMUSH, strings and db#s larger than #0 have traditionally # been considered true (1) in boolean functions like and(), or(), etc. # In TinyMUSH, strings and db#s evaluate as false (0) # Should we emulate TinyMUSH? tiny_booleans no # TinyMUSH's trim function is: # trim( [, [,]]) # PennMUSH's trim function has been: # trim([,[,]]) # Should we emulate TinyMUSH? [+ for new MUSHes] tiny_trim_fun yes # In Tiny, strings used in math expressions evaluate to 0, # so eq(asdfa,0) = 1, gt(asdf,0) = 0, etc. # In Penn, using strings where numbers should be is traditionally an # error (returning #-1 ARGUMENT MUST BE NUMBER or similar) # Do you want the TinyMUSH behavior? tiny_math no # should @pemit default to @pemit/silent, like TinyMUSH? silent_pemit no ### ### Attributes ### # enable the adestroy attribute, triggered when an object is nuked? adestroy no # enable the amail attribute for admin, triggered when they receive # @mail? This does no mail loop checking. [-] amail no # does @listen work on players? player_listen yes # does @ahear work on players? If player_listen is yes, and # player_ahear is no, sound outside the player can be heard by her # inventory, but her @ahear isn't executed. player_ahear yes # Should we trigger the @startup attribute on startup? # You always want to, unless you need to disable some # malicious code on an @startup. This does not affect the # @restart command, which will work even if this is "no". startups yes # Can @desc attributes be accessed remotely by everyone? # Historically, this was allowed, but it makes it difficult to # have hidden objects with secrets in their @desc if players # can remotely get the @desc. If set to "no", you must be # able to look at something to retrieve its @desc. read_remote_desc no ### ### Cosmetic stuff ### # show room/object/player names in bold for ansi players? ansi_names yes # show exit lists with commas (a, b, and c)? comma_exit_list no # count hidden players when WHO reports total connected? count_all no # are rooms with any exits considered connected, and thus not required # to have the FLOATING flag set on them? exits_connect_rooms no # Prefixes for various broadcast messages wizwall_prefix Broadcast: rwall_prefix Admin: wall_prefix Announcement: # Should we announce connections/disconnections to rooms and on channels? # If this is disabled, only MONITOR players will see connect/disconnect. # @aconnect/@adisconnect, however, are still triggered, so you can # softcode whatever connection monitor you like. Players will probably # object if you don't at least show them when someone connects in # the room with them. announce_connects yes # can players have names with spaces in them? player_name_spaces no # show expanded flag name list when you examine an object? flags_on_examine yes # show visual attributes when you examine an object you don't own? # (like examine/full in TinyMUSH) ex_public_attribs yes # What should page a b c = message do? # If blind_page is yes, page defaults to page/blind (a,b,c each get separate # pages with no evidence that it was a multipage). If blind_page is no, # page defaults to page/list (a single page goes to a,b,c and they can # see that they all received it. blind_page yes # Should we show the pager's alias, in parentheses, after their name? # That is, should recipients see: # Javelin (Jav) paged: ... page_aliases no # Should +whatever "hi! strip the initial quote and produce X says, # "hi!", or not (producing X says, ""hi!"). This also affects # the @*wall and say commands. chat_strip_quote yes # Should strlen(%r) be 1 or 2? Turning this option on will allow %r to be # used as a list delimiter, but might break formatting softcode that depends # on its length being 2. newline_one_char yes # Should object names be restricted to just ascii characters, or can # non-ascii (Accented letters, for example) be used as well if the # mush'es locale permits? Not reccomended except for # non-english-language games, as people with tend to have problems # typing in those extra characters. @nameaccent is the preferred way to # get fancy names. only_ascii_in_names yes ### ### Default flags for newly created stuff ### To get multiple flags, you may repeat these directives: ### player_flags flag1 ### player_flags flag2 ### As of 1.7.7p6, you may also stack them on one directive: ### player_flags flag1 flag2 ### # -- Default flags for exits # Uncommenting this will cause the exit default to be DARK (like in TinyMUD): # no exits show up on the "Obvious exits" list. # exit_flags dark # Uncommenting this will cause all exits to be TRANSPARENT by default # (if you look through them, you will see the description of the next room) # exit_flags transparent # -- Default flags for rooms # Uncommenting this will cause all rooms to be TRANSPARENT by default. # Each obvious exit in a transparent room is displayed on a line by # itself, in the format: # leads to # instead of having all exits strung out in one row. # room_flags transparent # Objects which are NO_COMMAND will not be checked for $commands. # Making this a default may speed up your server somewhat. This is # definitely a good idea for rooms and players, and, depending on # the compostion of your database, probably a good idea for things. room_flags no_command # -- Default flags for players # Players who are ENTER_OK can be given stuff. player_flags enter_ok # Players who are INHERIT allow all their objects to control them. # player_flags inherit # Players who are ANSI see attribute names hilighted. player_flags ansi # See the explanation for rooms and no_command. player_flags no_command # -- Default flags for things # For example, you can't see through OPAQUE things. # thing_flags opaque # See the explanation for rooms and no_command. thing_flags no_command # -- Default flags for newly created channels # # For example, you might want: # channel_flags player quiet open hide_ok channel_flags player ### ### Reserved command names, and command and function aliases are in ### alias.cnf ### include alias.cnf ### ### Restrictions on command usage are in restrict.cnf ### include restrict.cnf pennmush-1.8.2p8/game/getdate.README0000644000175000017500000000107310421616663016422 0ustar noltarnoltarThe getdate.template file is used by the extended CONVTIME() (See @config compile for it's status) to match many date and time templates. The format is one template per line, using the same codes as TIMEFMT(), except with %-signs instead of $-signs. Plain text is matched exactly. The MUSH does not need to be rebooted after editing getdaily.template. DO NOT use '%c', '%x' or '%X', as they might crash the mush on a linux box, and possibly others. For more details on the format of the file, see your system documentation on the getdate() and strptime() C functions. pennmush-1.8.2p8/game/aliascnf.dst0000644000175000017500000000437710470567536016444 0ustar noltarnoltar# Command aliases that you'd like reserved. # Normally, commands are autoaliased to their unique prefixes, # so n -> news # However, you might prefer to have n not treated as a command alias # because you think of it as short for 'north' and want to use a # master room exit to catch it. In that case, you'd uncomment # lines like this: #reserve_alias e #reserve_alias w #reserve_alias s #reserve_alias n #reserve_alias nw #reserve_alias ne #reserve_alias sw #reserve_alias se #reserve_alias u #reserve_alias d # We add a dummy here to make updating easier reserve_alias dummy_exit_alias # You can also alias commands to other names. # command_alias EXISTING_COMMAND ALIAS # For example, a french-language game do the following: # command_alias think pensent # Some standard aliases: command_alias @edit @gedit # Alias read to look? #command_alias look read command_alias look l command_alias inventory i command_alias @switch @sw command_alias page p command_alias whisper w command_alias goto move command_alias @atrlock @attrlock command_alias @atrchown @attrchown # As well as commands, functions can be aliased. Same syntax, # just function_alias instead of command_alias. Note that many # functions use the same internal function, doing slightly different # things depending on the name it was called by. The hasattr*() functions # are an example of these. Aliases of this type of function may not work # right. # Some standard aliases: function_alias lsearch search function_alias soundslike soundlike function_alias lstats stats function_alias trunc val function_alias nattr attrcnt function_alias nattrp attrpcnt function_alias iter parse function_alias modulo mod function_alias modulo modulus function_alias randword pickrand function_alias lthings lobjects function_alias lvthings lvobjects function_alias nthings nobjects function_alias nvthings nvobjects function_alias xthings xobjects function_alias xvthings xvobjects function_alias atrlock attrlock # For rhost compatibility function_alias textfile dynhelp # And so can attributes! attribute_alias describe desc attribute_alias idescribe idesc attribute_alias success succ attribute_alias osuccess osucc attribute_alias asuccess asucc attribute_alias failure fail attribute_alias ofailure ofail attribute_alias afailure afail pennmush-1.8.2p8/game/restart0000755000175000017500000001006210556616672015547 0ustar noltarnoltar#!/bin/sh # # usage: restart # # REQUIRED: You must set this to the path to your game directory. # E.g.: /home/mush/game GAMEDIR= # OPTIONAL things that you may want to tweak. # Uncomment the line below to attempt to allow crashes to produce # core dumps. If you're getting crashes, this is the best way # to debug them. #ulimit -c unlimited # Internationalization stuff # Set LANG here to get international character sets and, if someone's # done it, translation of messages. # Vaild locales are usually _ # Example (uncomment to use): #LANG=fr_FR # Time zone stuff # If you want your MUSH to run in a different timezone than the one # you're in, you need to identify the target time zone file in # /usr/share/zoneinfo or /usr/lib/zoneinfo. Then uncomment the next # two lines and set TZ to the desired timezone file, as shown, with # an initial colon: #TZ=:EST5EDT #export TZ # The config file. Best to keep this as is. If you must change # the name, make it a link to mush.cnf. CONF_FILE=mush.cnf ####################################################################### if [ -z "$GAMEDIR" ]; then echo "You must set GAMEDIR in the restart script." exit 1 fi if [ ! -d "$GAMEDIR" ]; then echo "GAMEDIR doesn't appear to be a directory. It's: $GAMEDIR" exit 1 fi cd $GAMEDIR echo Running from `pwd` if [ ! -f "$CONF_FILE" ]; then echo "CONF_FILE doesn't exist. It's: $CONF_FILE" echo "Create $CONF_FILE from $GAMEDIR/mushcnf.dst and run 'make update'" exit 1 fi # If netmush isn't here, they probably didn't make install # In any case, we'd better not proceed. if [ ! -e netmush ]; then echo "I don't see $GAMEDIR/netmush. Did you remember to make install?" exit 1 fi # # Read the cnf file and set some variables. # INDB=`egrep "^input_database" $CONF_FILE | sed "s/.*[ ][ ]*.*\/\(.*\)/\1/" | sed 's/\r$//'` OUTDB=`egrep "^output_database" $CONF_FILE | sed "s/.*[ ][ ]*.*\/\(.*\)/\1/" | sed 's/\r$//'` PANICDB=`egrep "^crash_database" $CONF_FILE | sed "s/.*[ ][ ]*.*\/\(.*\)/\1/" | sed 's/\r$//'` PANICDIR=`egrep "^crash_database" $CONF_FILE | sed "s/.*[ ][ ]*\(.*\)\/.*/\1/" | sed 's/\r$//'` COMPRESSOR="cat" SUFFIX="" # Find out what the compression program is, if any egrep -s "^compress_program[ ]*[A-Za-z0-9]" $CONF_FILE nocompress=$? if [ "$nocompress" -eq 0 ]; then COMPRESSOR=`egrep "^compress_program" $CONF_FILE | sed "s/[^ ]*[ ]*\(.*\)/\1/" | sed 's/\r$//'` SUFFIX=`egrep "^compress_suffix" $CONF_FILE | sed "s/[^ ]*[ ]*\(.*\)/\1/" | sed 's/\r$//'` fi #-- start up everything # Prevent double-starting things. You may need to provide a pathname for # some of the commands. System V flavors need "ps -f" instead of "ps uwx". mush=`ps uwwx | grep " $GAMEDIR/$CONF_FILE" | grep -v grep | wc -l` if [ "$mush" -gt 0 ]; then echo Mush already active or some other process is using $GAMEDIR/$CONF_FILE. exit 0 fi echo Building text file indexes. (cd txt; make) echo Restarting Mush. if [ -r "$PANICDIR/$PANICDB" ]; then end="`tail -1 $PANICDIR/$PANICDB`" if [ "$end" = "***END OF DUMP***" ]; then echo "Recovering PANIC dump." cat $PANICDIR/$PANICDB | $COMPRESSOR > data/$OUTDB$SUFFIX rm $PANICDIR/$PANICDB echo "PANIC dump successfully recovered." else mv $PANICDIR/$PANICDB save/$PANICDB.corrupt echo "Warning: PANIC dump corrupt. Using older db." fi fi # Copy the last set of log files to save/ mv -f log/*.log save/ if [ -r "data/$OUTDB$SUFFIX" ]; then rm -f save/$INDB$SUFFIX.old mv -f data/$INDB$SUFFIX save/$INDB$SUFFIX.old mv data/$OUTDB$SUFFIX data/$INDB$SUFFIX else echo "No $OUTDB$SUFFIX found." if [ -r "data/$INDB$SUFFIX" ]; then echo "Using $INDB$SUFFIX." else echo "No $INDB$SUFFIX found." if [ -r "save/$INDB$SUFFIX.old" ]; then echo "Using save/$INDB$SUFFIX.old." cp save/$INDB$SUFFIX.old data/$INDB$SUFFIX else echo "No database found. Mush will start with a minimal world." fi fi fi if [ -r reboot.db ]; then rm -f reboot.db fi DATEMSK="${GAMEDIR}/getdate.template" LC_ALL=$LANG LANG=$LANG ./netmush $GAMEDIR/$CONF_FILE & pennmush-1.8.2p8/game/access.README0000644000175000017500000001453510470547525016261 0ustar noltarnoltar Everything you ever wanted to know about access.cnf and more The file "access.cnf" in the game/ subdirectory controls access to the MUSH. It's used to restrict which sites can conect to players or guests, create players, or register players by email. It can also flag a site as suspect; all players who connect from suspect sites have their SUSPECT flag set. This file replaces the older lockout.cnf and sites.cnf file; typing 'make access' will create a new access.cnf file from your lockout.cnf and sites.cnf files. FILE SYNTAX The syntax of the file is simple. Each line gives information about a host or host-pattern: [user@]host [dbref] [options] [# comment] host - the only required file, this is a hostname or a wildcard pattern to match. Examples: berkeley.edu - matches hostname berkeley.edu *.berkeley.edu - matches hostname .berkeley.edu *berkeley.edu - matches either of the above * - matches all hosts user@ - if the host supports ident, and you trust the ident response, and you're sure that the link is fast enough that you'll always get an ident response in time, you can match for specific users. Example: johnq@netcom.com dbref - The dbref of a character to restrict the rule too. (Only makes sense for connect rules). Leave it out or use '-2' to match all characters. Leave out the '#' in the dbref. options - A space-separated list of options which apply to connections from the host. Described in detail below. comment - an optional comment Everything in the file is separate by a single space - don't use tabs. The file is read line-by-line, and the first match is used. This means that the order in which hosts are listed is very important. Also, since both hostnames and IPs are checked, some rules must take both into account. There is one special line in the file, which looks like this: @sitelock This line indicates where @sitelock'd sites will be inserted in the file. Hosts listed after this line can have their access options superseded by using @sitelock on-line. Hosts listed before this line can not have their access options overriden by @sitelock. If the line doesn't appear in the file, it will be added to the end of the file at startup. READING AND WRITING THE FILE The access.cnf file is read and cached at startup, and whenever the MUSH receives a HUP signal. The access.cnf file is written back to disk whenever @sitelock is used. OPTIONS The following options are available for each host in the file: create - People connecting from this host may 'create' players. !create - People connecting from this host may NOT 'create' players. connect - People may connect to their existing non-guest players. !connect - People may NOT connect to their existing non-guest players. guest - People may connect to guest players from this host. !guest - People may NOT connect to guest players from this host. none - shorthand for: !create !connect !guest default - shorthand for: create connect guest !god - God cannot connect from this host. !wizard - Wizards cannot connect from this host. !admin - Wizards and Royalty cannot connect from this host. register - People may use the 'register' command from this host. suspect - All players connected to from this host will be set SUSPECT deny_silent - Don't log failed create/connect/guest/register attempts regexp - Use regexp match rather than glob matching for the pattern If no options are given, the host is treated as if option "none" were used. If at least one option is listed, it's assumed that hosts can do anything (create, connect, guest) that they are not prohibited from. EXAMPLE SCENARIOS Here are some typical ways you might want to set up your file: 1. Totally ban specific sites, allow all others *badsite.com -2 none *.twink.edu -2 none This will totally lock out those sites (like lockout.cnf) 2. Allow specific sites and no others. Note that you must list both hostname-matching patterns and ip address-matching patterns, because if either fails to match a rule that allows connection, the connection will be refused. This is true in general when writing positive rules. *.berkeley.edu -2 default 128.32.* -2 default * -2 none People may connect from .berkeley.edu (128.32.) sites only. 3. Allow connection but not creation from some sites *.twink.edu -2 !create This is equivalent to the former function of sites.cnf 4. Allow connection but not creation or guest-connection from some sites *.twink.edu -2 !guest !create 5. Require that a given site use the 'register' command to register players by email. *.twink.edu -2 !create register Using !create prevents people from using the usual create command. Adding register allows them to uset the register command. 6. Disable creation from twink.edu sites, and don't let Wizards override this rule with @sitelock *.twink.edu -2 !create @sitelock Because the rule appears above "@sitelock", and @sitelock rules appear below "@sitelock", the rule will always be checked before any @sitelock rules. 7. Disable creation from twink.edu sites, but allow Wizards to later override this rule with @sitelock @sitelock *.twink.edu -2 !create Because the rule appears below "@sitelock", new @sitelock rules (which will be added immediately following "@sitelock") will precede it, and will be checked first. 8. God can only be connected to from one specific account on the server, and nowhere else. Wizards cannot override it. This requires you to connect to 'localhost ' from a given account on the same server the mush runs on. If the server doesn't support ident, remove 'username@' so that anyone on the server can connect. username@localhost 1 connect username@127.0.0.1 1 connect * -2 !god @sitelock 9. A complex example: a) Allow anybody from localhost.berkeley.edu complete access b) Force people from *.twink.edu to use registration, and set their players SUSPECT c) Completely ban *badsite.com, and don't log attempts to connect d) Don't allow jerk@netcom.com to connect to Guests e) Allow people from somesite.org to connect to Guests only. f) Allow @sitelock to override c-e above localhost.berkeley.edu -2 default 127.0.0.1 -2 default *.twink.edu -2 !create register suspect @sitelock *badsite.com -2 none deny_silent jerk@netcom.com -2 !guest somesite.org -2 !connect !create guest pennmush-1.8.2p8/game/save/0000755000175000017500000000000010736360342015062 5ustar noltarnoltarpennmush-1.8.2p8/game/save/README0000644000175000017500000000010010417116361015725 0ustar noltarnoltarThe save/ directory is usually where backup databases are kept. pennmush-1.8.2p8/game/restrictcnf.dst0000644000175000017500000001051110470567342017170 0ustar noltarnoltar# # Commands to restrict # Syntax: restrict_command [" ] # restrict_function # is a space separated list that may include: # nobody Totally disable the command # nogagged Gagged players can't use it # nofixed Fixed players can't use it # noguest Guests can't use it # noplayer Player objects can't use it (things, rooms, exits may. Command only) # admin Must be roy or wiz to use it # wizard Must be wiz to use it # god Must be god to use it # logname When func/cmd is used, log its name and user # logargs When func/cmd is used, log its name, args, and user # Any flag that must be present to use it (Command only) # Any power that must be present to use it (Command only) # ! The opposite of a restriction (Command only). # nosidefx The side-effect version of a function won't work (Function only). # # If is given to a restrict_command, it is sent to the player # instead of a more generic, typically useless error message. # # Command restrictions typically also apply to side-effect functions that # emulate the command. # Don't let guests mess with the database # (This replaces the HARSH_GUEST compile-time define) # The "ATTRIB_SET" command controls the setting of attributes with # @attr obj=value or &attr obj=value restrict_command @set noguest restrict_command ATTRIB_SET noguest restrict_command @chown noguest restrict_command @chzone noguest restrict_command @cpattr noguest restrict_command @mvattr noguest restrict_command @edit noguest restrict_command @gedit noguest restrict_command @parent noguest restrict_command @wipe noguest restrict_command @unlink noguest restrict_command @link noguest restrict_command @lock noguest restrict_command @unlock noguest restrict_command @create noguest restrict_command @dig noguest restrict_command @open noguest # @power is traditionally logged restrict_command @power logargs # Prevent players going home while set FIXED restrict_command home nofixed " You can't do that IC! # Some additional protection against spam attacks by guests #restrict_command @dolist noguest #restrict_function repeat noguest #restrict_function iter noguest #restrict_function map noguest #restrict_function fold noguest # Don't allow kill (slay still works) #restrict_command kill nobody # Uncomment to allow only admin or @powered builders to build #restrict_command @open admin builder " You need the builder power to do that. #restrict_command @dig admin builder " You need the builder power to do that. # Uncomment to disallow them to create objects #restrict_command @create admin builder " You need the builder power to do that. # Used to be player_locate #restrict_command @whereis nobody # Used to be hate_dest restrict_command @destroy noplayer " Use @recycle instead # Used to be cemit_power #restrict_command @cemit admin cemit " You can't @cemit without cemit @power # Turn off ansi(). #restrict_function ansi nobody # And some of the more dangerous side-effect functions. #restrict_function set nobody #restrict_function wipe nobody #restrict_function create nobody #restrict_function clone nobody #restrict_function tel nobody # If you turn this on, players who try to use functions in place # of commands (e.g. $foo: [pemit(%#,blah)] will get error messages. # Disabled by default for backward compatibility. restrict_command warn_on_missing nobody # We add a dummy here to make updating easier restrict_function lstats noguest # Remove the hardcode chat system by uncommenting these #restrict_command @cemit nobody #restrict_command @nscemit nobody #restrict_command @channel nobody #restrict_command @chat nobody #restrict_command @clock nobody #restrict_function cowner nobody #restrict_function ctitle nobody #restrict_function cwho nobody #restrict_function channels nobody #restrict_function cflags nobody # Remove the hardcode mail system by uncommenting these #restrict_command @mail nobody #restrict_command @malias nobody #restrict_function mail nobody #restrict_function maildstats nobody #restrict_function mailfrom nobody #restrict_function mailfstats nobody #restrict_function mailstats nobody #restrict_function mailstatus nobody #restrict_function mailsubject nobody #restrict_function mailtime nobody #restrict_function malias nobody #restrict_function folderstats nobody pennmush-1.8.2p8/game/README0000644000175000017500000001471510470565610015014 0ustar noltarnoltar Run-time Installation and Configuration of PennMUSH This document assumes that you've successfully compiled and installed PennMUSH as described in the main PennMUSH README file. The next step is to create your configuration file. In the game directory is a file called "mush.cnf". If you don't have mush.cnf, but you have mushcnf.dst, you can copy mushcnf.dst to mush.cnf. This file is a list of all runtime configuration options with their default settting. Change them as you see fit. IMPORTANT: do not _delete_ any parameters. They all need to be there. WIN32 WITH MSVC++: Under win32 using the Microsoft compiler, ignore the restart script. In the configuration file, turn off disk database compression; it is not supported. Then go to the game directory and run PennMUSH.exe. Poof, you're done. UNIX or WIN32 VIA CYGWIN/MINGW: Edit the restart script. Change GAMEDIR to the path to the directory containing mush.cnf. Read about the optional settings in that file. The restart script is written for sh, and assumes a fairly standard Berkeley UNIX setup. If you're on a HP-UX or SysV machine, for example, you may need to change the restart script a bit (the ps options, for example). Then run it. You should now be ready to start the game. This distribution can general a minimal database - a God character, starting room, and master room. The server will generate this database if it doesn't find another database to load. If you're starting with the minimal database, the god character "One" has no password, so you can log in without one. Of course, you should immediately set one (via @newpasswd). options.h has the Master Room as #2 by default; in the minimal database, this room is created for you. Now you should be set -- all you have to do now is customize the .txt files in the game directory. The logfiles in the "log" directory generally contain useful information. You will probably want to read your error logfile (defined in mush.cnf) every time, since errors and other important messages get printed to that logfile. After your first startup, it's a good idea to make some small change to the database (e.g., @create an object) and then do an @shutdown. Restart the game again and ensure that your object is still present - this verifies that the server is successfully dumping. ============================================================================ Game Trouble-shooting If you ever run into trouble, the your first reaction should ALWAYS be to back up your database. indb.Z.old is the file that the MUSH saves indb.Z to when the game, restarted, indb.Z is the file that the MUSH loaded at startup, and outdb.Z is the file to which the MUSH is currently dumping the database. You can tell if a dump is (theoretically) complete by doing a "zcat | tail -10". The last line should read "***END OF DUMP***". If it doesn't, your database has been truncated for some reason. Check the logfile. Possible causes include a full process table, a full disk partition, or running out of disk quota. Occasionally the dump process may dump core. This is caused by some sort of corruption in an attribute, normally. You can tell if the dump process has died by looking in your data directory; you will see something like "outdb.Z.#5#". Wait a few moments and check on the file again. If it has grown, then the game is in the process of a normal dump. If it hasn't, and there's a core file, then something has gone wrong. You should definitely shout a warning that building is not being saved. To attempt to fix the problem, do a @dbck to take care of any possible minor weirdness in the database, then try doing a "@dump/paranoid", and reading the checkpoint logfile (default is log/checkpt.log). This is slow, but it will write out an uncorrupted database, and tell you what it fixed. Back up that database and indb.Z, then figure out what you're going to do next: you can take the game down with a kill -9, or attempt to manually fix the problem by either @destroying the offending object, or attempting to reset the attributes on the object that are causing a problem. If "@dump/paranoid" dies, you are more or less out of luck. The game may crash from time to time. It will generate a core file, usually; if you don't limit the coredumpsize or strip the executable, you should be able to get some useful information out of it, using a debugger. Javelin is interested in stack traces. You can do a stack trace in the following manner: Go into the directory where you keep your source code, and type netmud ../game/core If you don't call your executable "netmud", substitute in whatever you do call it. You are looking for variables set to bizarre values - attempts to access objects that aren't there, attempts to use pointers which point to nothing, and the like. If you are using the "adb" debugger (don't do this unless you really have absolutely nothing else available), you will see nothing. It's loaded and ready, though. Type "$c". This will print out a list of the functions it called. Type "$q" to quit. You can't really get much more useful information out of adb. If you are using the "dbx" debugger, type "where" to see the stack trace. You can move through it using "up" and "down", and see exactly what the sequence of calls was. You can also use "print " to see the value of a variable at the time the game crashed. The "gdb" debugger is similar to "dbx"; with that, you can abbreviate "print" as "p". Javelin appreciates news of any bugs found, and any patches that have been written to deal with them. He is also interested in any extensions that people make to the code, and requests that ones that are of more than just local interest be sent to him for inclusion in the next release of this code. One important thing to remember is, if the MUSH refuses to start, there is probably a good reason. Check the MUSH log, and the core file, if there is one. Make sure to back up your database before attempting to restart -- remember that every time it restarts, it overwrites indb.Z.old. If you restart three times and somehow manage to trash your database each time (for example, a full process table zero'ing out your files), you won't have a backup to restart from, unless you've backed up your database before trying! You can also find helpful tips in Javelin's Guide for Gods, which is available on the WWW as http://pennmush.org/~alansz/guide.html and by ftp from pennmush.org as /pub/DuneMUSH/Guide/guide-single.txt pennmush-1.8.2p8/game/getdate.template0000644000175000017500000000020710421616663017276 0ustar noltarnoltar%a %b %d %H:%M:%S %Y %a %b %d %H:%M:%S %b %d %H:%M:%S %Y %b %d %H:%M:%S %B %d %H:%M:%S %B %d %H:%M:%S %Y %b %d %Y %b %d %B %d %Y %B %d pennmush-1.8.2p8/game/txt/0000755000175000017500000000000010736360342014743 5ustar noltarnoltarpennmush-1.8.2p8/game/txt/Makefile0000644000175000017500000000226610467332225016411 0ustar noltarnoltar# # This makefile only rebuilds the text files we need it # # By default we build help, news, and events. # To build rules.txt: # add rules.txt to the TXT line # Do the same to build index.txt (but add index.txt) TXT=help.txt news.txt events.txt # INDEX_FLAGS can be set to one or more of: # --first Insert the first entry alias in the index # --longest Insert the longest entry alias in the index # If left blank, all aliases are indexed. This is the default behavior. # (By default, this variable is not used in making the help index, # but if you want it to be, you can figure out how from the examples # below.) INDEX_FLAGS= all: $(TXT) help.txt: hlp/*.hlp hlp compose.sh ./compose.sh hlp mv hlp.txt help.txt news.txt: nws/*.nws nws compose.sh ./compose.sh nws $(INDEX_FLAGS) mv nws.txt news.txt events.txt: evt/*.evt evt compose.sh ./compose.sh evt $(INDEX_FLAGS) mv evt.txt events.txt rules.txt: rules/*.rules rules compose.sh ./compose.sh rules $(INDEX_FLAGS) index.txt: index/*.index index compose.sh ./compose.sh index $(INDEX_FLAGS) clean: -rm -f $(IDX) $(TXT) -rm -f compose.sh -rm -f hlp/*.orig hlp/*.rej hlp/\#* hlp/*~ compose.sh: compose.sh.SH sh compose.sh.SH pennmush-1.8.2p8/game/txt/compose.sh.SH0000755000175000017500000000401510467550132017257 0ustar noltarnoltar#!/bin/sh case $CONFIG in '') if test -f config.sh; then TOP=.; elif test -f ../config.sh; then TOP=..; elif test -f ../../config.sh; then TOP=../..; elif test -f ../../../config.sh; then TOP=../../..; elif test -f ../../../../config.sh; then TOP=../../../..; else echo "Can't find config.sh."; exit 1 fi . $TOP/config.sh ;; esac : This forces SH files to create target in same directory as SH file. : This is so that make depend always knows where to find SH derivatives. case "$0" in */*) cd `expr X$0 : 'X\(.*\)/'` ;; esac echo "Extracting compose.sh (with variable substitutions)" : This section of the file will have variable substitutions done on it. : Move anything that needs config subs from !NO!SUBS! section to !GROK!THIS!. : Protect any dollar signs and backticks that you do not want interpreted : by putting a backslash in front. You may delete these comments. $spitshell >compose.sh < # Example: compose.sh help # # This script calls index-files.pl # # By Alan Schwartz (Javelin/Paul) # # These come from Configure perl=${perl-none} test=$test cat=$cat rm=$rm echo=$echo !GROK!THIS! : In the following dollars and backticks do not need the extra backslash. $spitshell >>compose.sh <<'!NO!SUBS!' # This process can eat CPU, so uncomment if you want to be nice #/etc/renice +4 $$ # What subdirectories should we be processing? dir=$1 if $test ! -d $dir; then $echo "Usage: compose.sh " exit 0 fi index_args=$2 # Ok, let's do 'em: cd $dir # Remove the old index $rm -f index.$dir # Build a new index, and tack it on. $echo Building index for $dir... if test -f $perl; then $cat *.$dir | tee ../$dir.txt | $perl ../index-files.pl $index_args > index.$dir $cat index.$dir >> ../$dir.txt else $cat *.$dir > ../$dir.txt fi cd .. $echo Done. $echo Remember to use @readcache if the mush is currently running. !NO!SUBS! chmod 755 compose.sh $eunicefix compose.sh pennmush-1.8.2p8/game/txt/newuser.txt0000644000175000017500000000124510417116361017172 0ustar noltarnoltar------------------------------------------------------------------------- Congratulations on your newly created character. PennMUSH welcomes you. For more information about this game, type 'news' or 'help' to get help. Please read news for updates on program changes and other things that affect your life here at PennMUSH. If you ask for help on a topic that is in the help, you will be told to read help and news first to see if you can figure out what you might be doing. If you then still need help, the wizards will be more than happy to assist you. Yell at your god to personalize this file! ------------------------------------------------------------------------- pennmush-1.8.2p8/game/txt/motd.txt0000644000175000017500000000021310417116361016437 0ustar noltarnoltarWelcome to PennMUSH! -------------------------------------------------------------------------- Yell at your god to personalize this file pennmush-1.8.2p8/game/txt/guest.txt0000644000175000017500000000017510417116361016632 0ustar noltarnoltar Yell at your local God to personalize this file, if GUEST_TEXTFILE is defined and it's being shown to Guests who connect! pennmush-1.8.2p8/game/txt/connect.txt0000644000175000017500000000126610417116361017136 0ustar noltarnoltar ----------------------------------------------------------------------------- Use create to create a character. Use connect to connect to your existing character. Use 'ch ' to connect hidden, and cd to connect DARK (admin) Use QUIT to logout. Use the WHO command to find out who is online currently. ----------------------------------------------------------------------------- Yell at your local god to personalize this file! pennmush-1.8.2p8/game/txt/README0000644000175000017500000000300310421620113015601 0ustar noltarnoltarYour local help/news/events/etc files can now be kept separate from those distributed with PennMUSH, and can now be managed as a set of files rather than a single large file. Here's the details: 1. The source files for help.txt, news.txt, and events.txt are kept in directories called hlp, nws, and evt respectively. 2. Files in those directories which end in . are considered to be part of the text. That is, files in hlp/ which end in .hlp, and files in nws/ which end in .nws will be merged into the final help.txt, news.txt, or whatever. 3. When the MUSH is restarted, a 'make' is run in this directory. For if a file in hlp/ is newer than help.txt, it calls compose.sh to rebuild help.txt. If you've got perl on your system, compose.sh will also call index-files.pl to make a 'help index' entry which lists all your help entries. So, if you want to add your own news entries, make a file called nws/local.nws and put 'em there. Or maybe organize it into parts: nws/theme.nws, nws/code.nws, etc. Files distributed with PennMUSH always begin with "penn", so don't start your files with that. You can also add files for "rules" and "index" commands if you compiled them in. The easiest way to do add rules files is to: a) create a directory here called "rules" b) put your rules files there, each ending in .rules c) edit game/txt/Makefile and add rules.txt to the TXT line For index files, do exactly the same process, but replace all references to 'rules' above with 'index'. pennmush-1.8.2p8/game/txt/wizmotd.txt0000644000175000017500000000011010417116361017165 0ustar noltarnoltarWizards, tell your friendly neighborhood god to personalize this file! pennmush-1.8.2p8/game/txt/quit.txt0000644000175000017500000000013710417116361016463 0ustar noltarnoltarThank you for visiting. Please return soon. *********** D I S C O N N E C T E D *********** pennmush-1.8.2p8/game/txt/evt/0000755000175000017500000000000010736360342015541 5ustar noltarnoltarpennmush-1.8.2p8/game/txt/evt/index.evt0000644000175000017500000000037310467331011017363 0ustar noltarnoltar & Entries -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- & &Entries -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- pennmush-1.8.2p8/game/txt/evt/pennmush.evt0000644000175000017500000000051110417116361020107 0ustar noltarnoltar& help =========================================================================== TinyMUSH Events =========================================================================== No topics written yet. =========================================================================== pennmush-1.8.2p8/game/txt/register.txt0000644000175000017500000000045510467317431017336 0ustar noltarnoltarThis message is shown when a user tries to create a player or register a player from a site that doesn't allow creation or registration, respectively, or if creation/registration is disabled entirely. Alas. You'll probably have to send email to the person who runs this MUSH if you want a character. pennmush-1.8.2p8/game/txt/full.txt0000644000175000017500000000015710417116361016445 0ustar noltarnoltarThe maximum number of players this game can support are currently logged in. Please try back in a few minutes. pennmush-1.8.2p8/game/txt/nws/0000755000175000017500000000000010736360342015552 5ustar noltarnoltarpennmush-1.8.2p8/game/txt/nws/index.nws0000644000175000017500000000051210467331011017400 0ustar noltarnoltar & Entries -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- changes code & &Entries -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- pennmush-1.8.2p8/game/txt/nws/pennmush.nws0000644000175000017500000000006510421620367020136 0ustar noltarnoltar& code See 'help code' & changes See 'help changes' pennmush-1.8.2p8/game/txt/index-files.pl0000755000175000017500000000771510467550132017523 0ustar noltarnoltar#!/usr/bin/perl # # index-files.pl - make an & index topic for events/news/help # # Called by compose-tricky # # Take a MUSH help.txt format file on the stdin, and write a # "& entries" entry or entries. # Lines with entries to be indexed start with &'s. # Write the resulting entries to the stdout, also in help.txt format, # in columns and paged. # Idea by Schmidt@Dune, perl version by Alan Schwartz (Javelin/Paul) # with mods by Jeff Heinen. Modified further by Raevnos. # # Usage: index-files.pl [options] < news.txt > nws/index.nws # require 5; # Sorry, Talek. use strict; use Getopt::Long; use locale; my (@entries, @aentries); # Have we got any options? my($first,$longest) = ("",""); exit 1 unless GetOptions ('first' => \$first, 'longest' => \$longest); # Collect all the topic names my @set = (); my @aset = (); while () { chomp; next if /^& &?Entries/o; # Skip index entries. if ((@set or @aset) and $_ !~ /&\s+\S/) { # We've got a set of entries now. Choose which to add. if ($first) { # Add the first one push(@entries,$set[0]) if $set[0]; push(@aentries,$aset[0]) if $aset[0]; } if ($longest) { # Add the longest one @set = sort { length($b) <=> length($a) } @set; @aset = sort { length($b) <=> length($a) } @aset; push(@entries,$set[0]) if $set[0]; push(@aentries,$aset[0]) if $aset[0]; } if (!$first and !$longest) { # Add all push(@entries,@set) if @set; push(@aentries,@aset) if @aset; } @set = (); @aset = (); } push @aset,$1 if /^&\s+(&.*)/o; # Catch admin-help entries push @set, $1 if /^&\s+([^&].*)/o; # Catch normal entries. } # If anything's left in @set/@aset now, someone's screwed up # Make 'em all lower-case and sort 'em. @entries = map { lc $_ } @entries; @aentries = map { lc $_ } @aentries; sub withnumchecking; my @sorted = ($#entries > 0) ? (sort withnumchecking @entries) : @entries; my @asorted = ($#entries > 0) ? (sort withnumchecking @aentries) : @aentries; my $maxlines = 14; my $maxlen = 25; my $separator ="-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\n"; my $three_items = " %-25.25s %-25.25s %-25.25s\n"; # Format for three entries my $bigone = " %-51.51s %-25.25s\n"; # Format for two entries, long first. my $bigtwo = " %-25.25s %-51.51s\n"; # Format for two entries, long second. my $admin = 0; my $index; foreach $index (\@sorted, \@asorted) { my $i = 0; my $title = $admin ? "&Entries" : "Entries"; $admin++; my $titlecount = 1; my $header = 0; my ($entry1, $entry2, $entry3); print "\n& $title\n", $separator; while (@$index) { if (${$index}[0] eq "help") { shift @$index; next; } if ($header) { print "& $title-$titlecount\n", $separator; $header = 0; } $entry1 = shift @$index; $entry2 = shift @$index; $entry2 = "" if !defined $entry2; if (length($entry1) > $maxlen) { if (length($entry2) > $maxlen) { printf " %-76.76s\n", $entry1; unshift @$index, $entry2; } else { printf $bigone, $entry1, $entry2; } } else { if (length($entry2) > $maxlen) { printf $bigtwo, $entry1, $entry2; } else { $entry3 = shift @$index; $entry3 = "" if !defined $entry3; if (length($entry3) > $maxlen) { unshift @$index, $entry3; $entry3 =""; } printf $three_items, $entry1, $entry2, $entry3; } } if ($i++ > $maxlines) { $titlecount++; print "\nFor more, see $title-$titlecount\n", $separator; $header = 1; $i = 0; } } } print $separator; sub withnumchecking { my($firsta, $firstb) = ($a,$b); my($lasta, $lastb); ($firsta, $lasta) = ($1,$2) if $a =~ /(.+)p(\d+)/o; ($firstb, $lastb) = ($1,$2) if $b =~ /(.+)p(\d+)/o; my $res = $firsta cmp $firstb; return $res if $res; if (!defined($lasta)) { warn "Possible duplicate help topic: $a\n"; return $res; } return $lasta <=> $lastb; } pennmush-1.8.2p8/game/txt/down.txt0000644000175000017500000000053610417116361016453 0ustar noltarnoltar*************************************************************************** There has been an emergency which necessitated the disabling of non-wizard logins. Please be patient, and you will be re-allowed to login as soon as the emergency has been controlled. Thank you. *************************************************************************** pennmush-1.8.2p8/game/txt/hlp/0000755000175000017500000000000010736360342015526 5ustar noltarnoltarpennmush-1.8.2p8/game/txt/hlp/penntop.hlp0000644000175000017500000024440010644322121017711 0ustar noltarnoltar& help This is the index to the MUSH online help files. For an explanation of the help system, type: help newbie For the list of MUSH commands, type: help commands For the list of MUSH topics, type: help topics For an alphabetical list of all help entries: help entries For a list of entries that match a pattern: help For information about PennMUSH: help code For a list of flags: help flag list For a list of functions: help function list For a list of attributes: help attribute list To see the configuration of this MUSH: @config On many MUSHes, list local commands with: +help If there are any errors in the help text, please notify a wizard in the game, or send mail to pennmush-bugs@pennmush.org, which is the address of the team who develop PennMUSH (and its distributed help files) but probably have no relation to this MUSH in particular. & newbie If you are new to MUSHing, the help files may seem confusing. Most of them are written in a specific style, however, and once you understand it the files are extremely helpful. The first line of a help file on a command or function will normally be the syntax of the command. "Syntax" means the way the command needs to be typed in. In the help files, when the syntax of a command is described, square brackets [] mean that that part of the command is optional and doesn't have to be typed in. Also, pointy brackets <> mean that that part of the command needs to be replaced with a specific piece of information. You should not type the [] or <> brackets when entering a command. (continued in help newbie2 -- type 'help newbie2' without the single quotes) & newbie2 For example, the syntax of the help command is: help [] What this means is that to get help, you would type first the word "help" and then you could optionally type the name of a more specific topic in order to get help on that topic. Just typing "help" will work too (that's why the part is optional). Some common commands that you should look at help for are: look say go page pose take give home Just type help for help. Example: help page (continued in help newbie3) & newbie3 There is help available on every standard MUSH command. If you see a command or someone mentions one to you that you want to know more about, try just typing: help -- that will most likely bring up the help file on it. Please note that just because there is help available on a command does not necessarily mean that the command can be used on this MUSH. The siteadmin of the MUSH can choose to turn off some commands. If there's something that you would like available, and it isn't, please ask a wizard why not. It is also highly recommended that any new player read the MUSH manual, written by Amberyl. It is available by anonymous FTP from: ftp.pennmush.org in the directory: /pub/PennMUSH/Manuals & topics Help is available on the following topics: ACTION LISTS ANCESTORS ANONYMOUS ATTRIBUTES ATTRIB-OWNERSHIP ATTRIBUTES BEING KILLED BOOLEAN VALUES CHAT CLIENTS CONTROL COPYRIGHT COSTS CREDITS DBREFS DROP-TO ENACTOR EVALUATION EXECUTOR EXITS FAILURE FLAGS FUNCTIONS GENDER GLOBALS HERE HOMES INTERIORS LINKING LISTENING LISTS LOOPING MASTER ROOM MATCHING (continued in help topics2) & topics2 ME MONEY MUSHCODE NON-STANDARD ATTRIBUTES PARENTS POWERS PUPPETS QUEUE REGEXPS REGISTERS SEMAPHORES SETTING-ATTRIBUTES SPOOFING STACK STRINGS SUBSTITUTIONS SUCCESS SWITCHES TYPES OF OBJECTS USER-DEFINED COMMANDS VERBS WARNINGS WILDCARDS ZONE MASTER ROOMS ZONE MASTERS ZONES Type "help " for help. & ACTION LISTS Action lists are simply lists of actions that are all executed at once. You can have an action list in a user-defined command, in one of the a-attributes, or in many other commands. Action lists may not be executed directly from a client, except in the case of a command which forces a re-insertion into the queue such as @switch or @dolist. Actions in an action list are separated by semicolons. Each action is simply a separate MUSH command. If part of the action (such as the text in an @emit, for example) contains a semi-colon or comma, you may need to enclose that part in curly braces {}. You can also nest action lists inside each other by enclosing each action list in braces {}. Substitution will be performed on the contents of action lists before they are executed. (continued in help action2) & ACTION2 Example 1: > @asuccess Gift = @pemit %#={The box pops open; surprise!} ; @name me=New Toy ; @desc me={A shiny new toy, just for %N!} > take gift The box pops open; surprise! > look new toy New Toy A shiny new toy, just for Cyclonus! Example 2: > &TEST me=$test:@emit {Testing; testing; one, two.} ; @dolist 1 2 3={think {Test ##, success.} } > test Testing; testing; one, two. Test 1, success. Test 2, success. Test 3, success. See also: ATTRIBUTES, SUBSTITUTION, @asuccess, @dolist & ANCESTORS ANCESTORS Objects can inherit attributes from other objects through the use of parents. An object's parent, its parent's parent, its parent's parent's parent, etc. constitute the object's "parent chain" and lookups work the way up the chain until an inheritance occurs. Ancestors are "virtual parents" that are assumed to be last on every parent chain. There is one ancestor for each object type (room, exit, thing, player), and @config lists the dbref of each ancestor object (@config ancestor_room, etc.) Under normal circumstances, if an attribute can't be retrieved from an object or any of its explicit parents, the attribute will be looked for on the appropriate ancestor. The ORPHAN flag may be set on an object to cause lookups on that object to ignore ancestors (like the pre-ancestor behavior). Ancestors may themselves have parent chains, but these are (obviously) not virtually terminated by ancestors. Note that the choice of which ancestor to look up is based on the type of the *child* object, as is the check of the ORPHAN flag. Also note that ancestors are *not* checked for $-commands or ^-commands; you should use the master room for global commands, instead. See also: PARENTS, ORPHAN & ANONYMOUS ATTRIBUTES & LAMBDA & #LAMBDA In many cases where a function expects a object/attribute pair that refers to an attribute to evaluate, you can use the form #lambda/ instead, and the code will be treated as an attribute's body. The code will normally be parsed twice, so special characters should be escaped where needed. These anonymous attributes should be used for short and simple pieces of code. Anything long or complicated should go in an actual attribute, for readability and maintainability. See 'HELP ANONYMOUS2' for examples. & ANONYMOUS2 A typical usage of anonymous attributes would be to convert a list of dbrefs to names, as so: >say map(#lambda/name(\%0), #3 #12 #23) You say, "Joe Robert Sally" Because the code is parsed twice, you can actually build parts of it in place, which is very convenient. Consider this implementation of a lattrval function, which is like lattr() but it only returns non-empty attributes: &lattrval me= filter(#lambda/hasattrval([secure(before(%0, /))], \%0), lattr(%0)) The first time '#lambda/hasattrval([secure(before(%0, /))], \%0)' is parsed in a call like 'u(lattrval, #1234)', it is turned into '#lambda/hasattrval(#1234, %0)', thus avoiding the need for a setq() or the like to store the top-level %0 for use in a real attribute called by filter(). However, this can lead to problems with evaluating un-trusted code. Use secure() or escape() where neccessary. See 'HELP ANONYMOUS3' for another example. & ANONYMOUS3 You can also use lit() to avoid having the code evaluated twice, if needed. For example, this code, which returns all unlinked exits in a room: &lunlinked me=filter(lit(#lambda/strmatch(loc(%0), #-1)), lexits(%0)) This approach is useful both for security in making it harder to evaluate a string that shouldn't be, and for making the code look nicer by not having to escape percent signs, brackets, and other special characters. However, it also makes it harder to build the code string on the fly. Use what's most appropriate. See 'HELP ANONYMOUS4' for a list of functions that support anonymous attributes. & ANONYMOUS4 The following functions support anonymous attributes: filter() filterbool() fold() foreach() map() mapsql() mix() munge() sortby() sortkey() step() & ATTRIB-OWNERSHIP ATTRIBUTE OWNERSHIP The latest person to set an attribute on an object is the owner of that attribute. If you lock an attribute, using the @atrlock command, only the person who owns the attribute will be able to alter the attribute. This allows you to create standard commands on objects and then @chown them to others without letting them alter them. Attribute ownership is NOT changed when the object itself is @chown'ed. To change attribute ownership, you must use the @atrchown command. You must control an object in order to set attributes on it. See also: @atrlock, @atrchown, ATTRIBUTES & ATTRIBUTES & ATTRIBUTES LIST & ATTRIBUTE LIST Attributes with (*) after them are special, cannot be set by players, and may only be visible to wizards or admin. For those attributes, there is no @-command, so you can just type 'help ' for help. For all other attributes, type 'help @' for help. Standard Attributes: (see @list/attribs for the complete list) AAHEAR ACLONE ACONNECT ADEATH ADESCRIBE ADISCONNECT ADROP AEFAIL AENTER AFAILURE AHEAR ALEAVE ALFAIL AMHEAR AMOVE APAYMENT ASUCCESS AWAY CHARGES COST DEATH DESCRIBE DROP EALIAS EFAIL ENTER FAILURE FORWARDLIST HAVEN IDESCRIBE IDLE LALIAS LAST (*) LASTIP (*) LASTLOGOUT(*) LASTSITE (*) LEAVE LFAIL LISTEN MOVE ODEATH ODESCRIBE ODROP OEFAIL OENTER OFAILURE OLEAVE OLFAIL OMOVE OPAYMENT OSUCCESS OXENTER OXLEAVE OXMOVE PAYMENT QUEUE (*) RQUOTA (*) RUNOUT SEX STARTUP SUCCESS TFPREFIX (continued in help attributes2) & ATTRIBUTES2 An attribute is part of the code on an object that makes it unique. An attribute can contain any sort of text -- from a single word, to a long paragraph, to a piece of MUSHcode. Some attributes are standard in PennMUSH. That means that their effects are pre-set. Standard attributes can be set using one of the following commands: @ = @set =: & = It is also possible to have non-standard attributes, which can be named anything you like. Please see 'help NON-STANDARD ATTRIBUTES' for more information on those. (continued in help attributes3) & ATTRIBUTES3 Any attribute name can be shortened, but a shorter forms run the risk of conflicting with other attribute names. This could result in you setting an unwanted attribute. For example: @adesc me=think %N looks at you. will set your ADESCRIBE attribute just as @adescribe me=think %N looks at you. would. To see the attributes that are set on you or on any of the objects you own, you should use the "examine" command. See 'help examine'. (continued in help attributes4) & ATTRIBUTES4 Attributes can be owned by someone other than the object they are set on. This allows the person to change the content of just that attribute while not the rest of the object. Attributes can also be locked, which prevents them from being changed by anyone. In addition to the standard attributes with pre-set effects, there are some special attributes that date from the days before you could set non-standard attributes with any name you wanted. These are the attributes VA-VZ, WA-WZ, XA-XZ. These attributes have no pre-set effects, and were just to allow players to store any text or MUSHcode that they wished in those attributes. Now that non-standard attributes are available, it is highly recommended that you instead use them, since you can use longer and descriptive names for attributes, which makes it much easier to examine and work on objects. See also: ATTRIB-OWNERSHIP, @set, examine, @atrchown, @atrlock, hasattr(), get(), v(), NON-STANDARD ATTRIBUTES, SETTING-ATTRIBUTES, ATTRIBUTE TREES & BEING KILLED Getting killed is no big deal. If you are killed, you return to your home, and all things you carry return to their homes. You also collect 50 pennies in insurance money (unless you have >= 10000 pennies or you were killed via the Wizard slay command). See 'MONEY'. Generally, killing is not encouraged unless absolutely necessary. It can be extremely rude and annoying. Many MUSHes choose to disable the kill command. See also: kill, slay, @death & BOOLEAN VALUES A boolean variable, for those of you not familiar with programming, is a variable that is either true or false. Normally, a value of 1 is considered "true" and a value of 0 is considered "false". Many MUSH functions return either 1 if they are true or 0 if false. For example, the hasflag() function tests to see if an object has a certain flag set on it. If hasflag(,) is true (the object has the flag), it will return 1. If it is false, it will return 0. Other functions expect to operate on boolean values. What they consider "true" or "false", however, depends on the setting of the "tiny_booleans" config option (@config tiny will show this). (continued in help boolean2) & BOOLEAN2 If tiny_booleans is... no FALSE: null string, 0, any negative db TRUE: everything else yes TRUE: numbers other than 0 strings beginning with numbers other than 0 FALSE: everything else Or, put another way: Value tiny_booleans=no tiny_booleans=yes Gotcha 0 FALSE FALSE non-zero number TRUE TRUE # TRUE FALSE * # FALSE FALSE null string FALSE FALSE 0 TRUE FALSE * TRUE FALSE * (continued in help boolean3) & BOOLEAN3 Examples (assuming tiny_booleans is "no"): not(foo) = 0 not() = 1 not(-66) = 0 not(0) = 1 not(#-1) = 1 not(#12) = 0 And so on... (note: These rules only apply when a function expects a Boolean value, not for strings that expect other values.) See also: BOOLEAN FUNCTIONS, not(), t() & CLIENTS & CLIENTS Clients are special software programs that you can use to connect to MUSHes. They are usually much nicer to use than raw telnet and give you many additional features, such as larger text buffers (so you can type more), backscroll, history of previous commands, macros, and so on. Here is a list of common clients and the web sites where they can be found. Please note that the below sites are subject to change. The below are listed solely for your information and possible benefit. The developers of PennMUSH have nothing to do with the clients. OPERATING SYSTEM CLIENT WEB SITE ----------------------------------------------------------------------- UNIX Tinyfugue http://tinyfuge.sourceforge.net WINDOWS MUSHClient http://www.mushclient.com SimpleMU http://simplemu.onlineroleplay.com MuckClient http://www.xcalibur.co.uk/MuckClient/ MAC OS X Savitar http://www.heynow.com/Savitar/ Atlantis http://www.riverdark.net/atlantis/ Unix clients will also run on OS X. & CONTROL Controlling an object basically means that you have the power to change the object's characteristics such as flags and attributes. It may also mean that you have the ability to destroy it. Here are the conditions under which object O controls victim V: 1. If V is God, O must be God 2. If V is Wizard, O must be Wizard or God 3. If O is a Wizard, O controls V 4. If V is Royalty, O must be Royalty, Wizard or God 5. If O is MISTRUST, O must be V to control V 6. If V and O are owned by the same player: 6a. If V is not TRUST, O controls V 6b. If V is TRUST, O must be TRUST or the player must be TRUST 7. If V is on a zone, and isn't a player and isn't TRUST, O controls V if O passes the zone-lock of the zone. 8. If V is owned by a SHARED player, and V isn't a player and isn't set TRUST, O controls V if O passes the zone-lock of the SHARED player. Step 7 is skipped if config(zone_control_zmp_only) is on. There's also one special case: anyone can @link an unlinked exit (at which point the exit is @chowned to the linker). See also: controls(), TRUST, MISTRUST, ZONES, SHARED PLAYERS & COSTS These are usually: kill: 10 pennies (or more, up to 100 pennies) page: 0 pennies @dig: 10 pennies @create: 10 pennies (or more) @find: 100 pennies @search: 100 pennies @entrances: 100 pennies @link: 1 penny (if you didn't already own it, +1 to the previous owner). @open: 1 penny (2 pennies if linked at the same time) Type '@config/list costs' to get the costs for the MUSH you are on. See also: MONEY, money(), score & CREDITS Maintainer: Raevnos [SW] Developers: Javelin, Ervin Hearn III [EEH], Greg Millam [GM] Past Porters: Nick Gammon [NJG] (win32), Dan Williams [DW] (MacOS), Sylvia (OS/2) Former developers: Rhyanna [RLM], Trivian [TN], Halatir [LdW], Talek [TAP] The original TinyMUSH 1.0 code was written by Lawrence Foard, and was based upon James Aspnes' TinyMUD server. Since then, the code has been modified by the programmers of MicroMUSE (then MicroMUSH), and Joseph Traub (Moonchilde of PernMUSH). From January 1992 to January 1995, Lydia Leong (Amberyl of PernMUSH / Polgara of Belgariad) maintained the code currently known as PennMUSH 1.50. From January 1995 until July 2006, Alan Schwartz (Paul of DuneMUSH / Javelin elsewhere) maintained this code, along with a development team. From July 2006 on, Raevnos has been the maintainer. Big thanks to the developers of TinyMUSH 2.0, 2.2 [2.2], 3.0 [3], MUX2, and Rhost [Rhost] servers, as well as to the players of Belgariad MUSH, DuneMUSH, and M*U*S*H, and everyone else using this server! See also: help code, help license & DATABASE & DBREFS & DBREF NUMBER & DBREF # You will find the term "dbref" or "dbref number" used frequently in these help files and in MUSHcode. It is an abbreviation of "database reference number". The database is the part of MUSH that stores all the information about this particular MUSH. Players, things, rooms, and exits are all objects in the database. Each object in the database has a unique dbref number that is set when the object is created. You can use the dbref number to refer to an object that is not in your current location, and it is especially important for global code. Using DBREFs is also faster than using names, even if the object is in your location. This is because whenever you try to do something with an object (such as look at it, take it, etc.), the MUSH first has to locate the object. Since the dbref is unique, it can immediately find the object rather than checking through all the contents of your area to see if one matches the name. (continued in help dbref2) & DBREF2 If you own or control an object, you will see its dbref number listed right after its name when you look at it (unless you are set MYOPIC). Example: > look me Cyclonus(#3PWenAMc) A very short desc. The dbref number is indicated by the number/pound sign (#). Cyclonus's dbref is #3. The letters following the dbref are the abbreviations of the flags set on the object. NOTE: the abbreviation of the OPAQUE flag is 'O' (o), which looks like '0' (zero) on some clients. Make sure you have the right number before using it in your code! See also: MYOPIC, OPAQUE, MUSHCODE & DROP-TOS When you use the @link command on a room, it sets another room or object as the DROP-TO location. By default, any non-STICKY object that someone drops in the room will automatically be transported to the drop-to location, rather than staying in the room. Any STICKY object droped in the room will go to its home. If the room is set STICKY, objects dropped in the room will stay there until the last player leaves/disconnects, at which point they will be transported as described above. If the room has a @lock/dropto set on it, only objects that pass the lock will be transported (either immediately or when the last player leaves if the room is STICKY). This can be used to prevent the dropto from acting on, say, objects containing connected players. Drop-tos are useful for keeping rooms uncluttered. See also: @link, STICKY, LINK_OK, @lock & %# & %N & %~ & %: & ENACTOR The enactor is the object that does something (enacts something :). This is an important concept in MUSH, because the way many commands work will depend on who enters the command (ie, who the enactor is). Any type of object can be an enactor. There are five %-substitutions that involve the enactor: %# = the enactor's dbref %N = the enactor's name, first letter capitalized %n = the enactor's name, first letter as-is %~ = the enactor's accented name %: = the enactor's unique identifier, like objid(%#) If, for example, you have an @osucc on an object that includes the %n symbol, whenever someone picks up the object, that %n will be replaced with the name of the enactor (the person who typed 'get ' in this case). See also: EXECUTOR, SUBSTITUTION, DBREF & EVALUATION ORDER Whenever some text is entered by an object or thing, the MUSH program attempts to match it against a valid game command in the following order of possible commands: Special game commands: WHO, QUIT, etc. Single-token commands: ", :, ;, +, \, # Exits in the room @-commands and &attribute setting Regular game commands: get, inventory, etc. Enter aliases Leave aliases User-defined commands on nearby objects. All such $commands are matched and executed. If there are no user-defined commands nearby: If the zone of the player's location is a zone master room, Zone master room exits Zone master room user-defined commands Else User-defined commands on the zone of the player's location (continued in help evaluation2) & EVALUATION2 If still nothing is matched: User-defined commands on the player's personal zone If nothing, including zone commands, has been matched: Global exits Global user-defined commands: all $commands in the Master Room are matched. Local commands are always checked first and ALWAYS negate global commands. Because local commands overrule global commands, you can easily prevent a global command from working in a specific room by setting a copy of the global command in that room. Alternatively, if a global command is oddly not working in a room, you should check for copies of the command word in the room (using @scan). & %! & EXECUTOR The executor of a command is the object actually carrying out the command. This differs from the enactor, because the enactor is the object that sets off the command. In some cases, the enactor and the executor will be the same. There is a %-substitution, %!, that is replaced by the dbref # of the executor of the command. For example: @emit %N is the enactor and %! is the executor! > Cyclonus is the enactor and #6 is the executor! @create Box > Created: Object #10 &DO_EMIT box=$emit:@emit %N is the enactor and %! is the executor! emit > Cyclonus is the enactor and #10 is the executor! In the first case, Cyclonus directly entered the command and was therefore both the enactor and the executor. In the second, Cyclonus set off the command on the box, so Cyclonus was still the enactor, but the box was the object that was actually doing the @emit, and was thus the executor. See also: ENACTOR, SUBSTITUTION & EXITS An exit is a one-way link that takes you from its source room to its destination room. To open an exit from a room, you must control that room. To open an exit to a room, you must either control the room or it must be set LINK_OK. If an exit is set DARK is will not show up in the list of obvious exits in a room. If an exit is set TRANSPARENT, someone who looks at the exit will also see the description and contents of the destination room. If an exit is set CLOUDY, someone who looks at the exit will also see the contents of the room beyond, but not its description. If an exits is set -both- CLOUDY and TRANSPARENT, the description but not the contents will be seen. If you have code on an exit (In an @asuccess or the like), note that [loc(exit)] is the exit's destination, and [home(exit)] is the exit's starting point. If an exit @emit's something, it will be heard in the source room. (continued in exits2) & EXITS2 You can create an exit that sends those who go through it to their homes by typing '@link =home'. Starting with PennMUSH version 1.50p10, exits can have more than one destination. To make an exit with a variable destination, open the exit (using @open), then type '@link =variable'. Finally, add an attribute named 'DESTINATION' to the exit (&destination ), which will be evaluated for the dbref # of the destination room when the exit is used. For example: @open South ;s;south @link s=variable &destination s=[switch(rand(3),0,#100,1,#101,2,#102)] This exit would take you to either room #100, #101, or #102 depending on the random number. Anyone can create variable exits, but the destinations must be to places that the exit can normally @link to. See also: @link, @open, link_ok, CLOUDY, TRANSPARENT, @firstexit & FAILURE FAILURE A "failure" usually occurs when you try to do something that is governed by an @lock and you don't pass the lock. If you try to take a player or thing, and you don't pass their @lock, you will set off their @fail/@ofail/@afail attributes. If you try to go through an exit, and you don't pass its @lock, you will similarly set off its @fail/@ofail/@afail. Other failure sets include: Failing to enter an object (@efail, @oefail, @aefail) Failing to leave an object (@lfail, @olfail, @alfail) Failing to use an object (@ufail, @oufail, @aufail) Other failures (&`FAILURE, &`OFAILURE, &`AFAILURE) where the can be: FOLLOW_LOCK, PAGE_LOCK Many other things can also be locked -- see @lock and locktypes for more information. However, there are failure messages at this time only for the above. See also: @lock, @fail, @efail, @lfail & GENDER & SEX Gender on a MUSH is entirely up to you. You can set yourself (or any of your objects) to be male, female, neuter, or plural. If whatever is in the SEX attribute is not recognizable, the MUSH will assume the object is neuter. Setting a gender attribute will enable pronoun substitution by the MUSH. The SEX attribute is visual to anyone who wants to see it. See also: @sex, SUBSTITUTION & GLOBALS & GLOBAL COMMANDS A command is "global" if it can be used anywhere in the world of the MUSH. The standard MUSH commands are all global, so this term is usually used to refer to user-defined commands on objects in the Master Room of the MUSH. Global commands very greatly from MUSH to MUSH, but you can usually find MUSH-specific help on them by typing "+help". See also: MASTER ROOM, USER-DEFINED COMMANDS, EVALUATION & HERE The word 'here' refers to the room you are in. For example, to rename the room you're in (if you control it), you could enter "@name here= ". & HOMES & HOME Every thing or player has a home, which is usually the room where it was created. You can reset your home or the home of any object you own with the @link command: @link =. You must also control , unless that location (room or thing) is set ABODE or LINK_OK. When a player types 'home', s/he is sent back to the home room. When a thing with the STICKY flag set on it is dropped, it also goes to its home location. Note that if the FIXED flag is set on a player, he/she cannot use the 'home' command. You can create an exit that sends players home by doing: @link =home You can set the drop-to in a room to home by doing: @link =home See also: DROP-TOS, @link, STICKY, LINK_OK, FIXED, EXITS & INTERIORS Here's a quick description of how to make things that can be entered: @create Car @desc Car=A shiny red car. @idesc car=You are sitting inside a luxurious sportscar. @set Car=enter_ok @oxleave car=climbs out of the car. { The 'ox' messages are shown to @oxenter car=climbs into the car. { those OUTSIDE the object. @oenter car=joins you inside the car. { The 'o' messages are shown to @oleave car=gets out of the car. { those INSIDE the object @enter car=You get into the car. { The plain messages are shown to @leave car=You get out of the car. { the one entering or leaving (continued in help interiors2) & INTERIORS2 Now, if you want people inside to be able to hear and communicate with the outside, you also need to do the following. @set car=audible (lets people outside hear what's being said in the car. @listen car=* (lets people inside hear what's being said outside. @prefix car=From inside the car, @inprefix car=From outside, @filter car=* has arrived.,* has left.,joins you inside the car., gets out of the car. @infilter car=* has arrived.,* has left.,* climbs out of the car., * climbs into the car. (The filters will keep people on the outside from seeing the 'o' messages and people on the inside from seeing the 'ox' messages which is a good thing.) See also: enter, leave, @prefix, @filter, AUDIBLE, @listen & LAST & LASTLOGOUT LAST and LASTLOGOUT These attributes show the last times you connected and disconnected from the MUSH. & LASTSITE & LASTIP LASTSITE and LASTIP The LASTSITE attribute gives the name of the site you last connected from. The LASTIP attribute gives the IP address you last connected from. Mortals cannot set them. & LINKING You can link to a room if you control it, or if it is set LINK_OK or ABODE. Being able to link means you can set the homes of objects or yourself to that room if it is set ABODE, and can set the destination of exits to that room if it is LINK_OK. See also: LINK_OK, ABODE, @link & LISTENING There are two basic ways to trigger action on the MUSH. The basic way is to type in commands such as 'look' or '@emit'. These commands are not seen or heard by other players, although the results of the commands may be. The other way is to "listen" for something said/emitted in your hearing. There are two ways to listen for something in a room. The easiest way is to use a combination of @listen and @ahear/@aahear/@amhear. For example: > @listen Welcome Mat=* has arrived. > @ahear Welcome Mat="Welcome, %N! Breaker has arrived. Welcome Mat says, "Welcome, Breaker!" (continued in help listening2) & ^ & LISTENING2 If you need an object to "listen" for more than one pattern, you can also use ^-patterns. These work similar to user-defined commands, using ^ instead of $. An object must be set MONITOR to have ^-patterns activated. Syntax: & = ^: For example: > @set Welcome Mat = MONITOR > &greet Welcome Mat = ^* has arrived.:"Welcome, %N! > &goodbye Welcome Mat = ^* has left.:POSE says as %N leaves, "Bye!" Grimlock has arrived. Welcome Mat says, "Welcome, Grimlock!" Grimlock has left. Welcome Mat says as Grimlock leaves, "Bye!" Such attributes can also be @triggered as if the ^: did not exist. (continued in help listening3) & LISTENING3 By default, ^-patterns work like @ahear. To have them work like @amhear, set the AMHEAR attribute flag on the attribute; to have them work like @aahear, set the AAHEAR attribute flag on the attribute (Note that the triggering object is whatever happens to be %#, so, for example, when you @set an object MONITOR, you are %# with regard to the "Object is now listening" message, and this message can be picked up with an ^pattern.) Additionally, unlike $-commands, @listen and ^-patterns are NOT inherited via @parent, unless the LISTEN_PARENT flag is set on the listener. Listen patterns are checked after the object's normal @listen attribute. See also: @listen, @ahear, @amhear, @aahear, MONITOR, LISTEN_PARENT, USER-DEFINED COMMANDS & LISTS The word "list" is used in the help files to refer to a string that is a series of smaller strings separated by one or more spaces. A list can also have its elements separated by some other kind of character -- the separating character is called the "delimiter". For example, the following are all lists: #6 #10 #14 #12 Rumble|Krystal|Bobatron|Rodimus Prime ('|' is the delimiter here) foo bar whee blarg -eek- .boing. yawp #5 7 Lots of MUSHCode depends on lists and manipulating them. Normally, a list is made up of similar items (so the fourth list in the example is NOT a typical one). See also: STRINGS, List Functions & LOOPING Looping in an object can have its good parts and its bad parts. The good part is when you activate part of a program multiple times to exhaustively perform an operation. This can be done like this: &PART1 object= ; @trigger me/PART2 &PART2 object= @select =,@trigger me/PART1 Looping can be a problem when it goes on without stopping. The @ps command can be used to see if you are looping. Beware! A looping machine that isn't @halt'd will drain your pennies while you are away from the mush! See also: @ps, HALT, COSTS, @trigger & MASTER ROOM The Master Room enables global commands and exits. Exits in the Master Room may be used from any location on the MUSH. All objects left in the Master Room are checked for user-defined $commands. Those $commands are considered global, meaning that they can be used anywhere on the MUSH. Normally, only wizards will have access to the Master Room; if you have a global command that you would like to see enabled for the MUSH, speak to a wizard. See also: EVALUATION, GLOBAL COMMANDS & ME The word 'me' refers to yourself. Some things to do when starting out: 1) give yourself a description: @desc me= 2) check your desc.: look me 3) lock yourself: @lock me==me 4) set your gender: @sex me= See also: help newbie, help @lock, help @describe, help @sex & MONEY The MUSH has a built-in money system, which gives a starting amount of money to new players and hands out a daily allowance thereafter. MUSH money (the default name is "pennies", but this may be different depending on the particular MUSH) is spent on some MUSH commands that are computationally expensive or alter the database. In addition, every time you "queue" a command, it costs you a certain amount of money -- this prevents looping from getting out of control, since when all your money is spent, you can't queue any more commands. The money system can also be used on player-created objects by giving them @cost/@payment/@opayment/@apayment attributes. When someone then pays the object by giving it the right number of pennies, the attributes are triggered. See also: COSTS, give, @cost, @pay, @opay, @apay & MUSHCODE & SOFTCODE MUSHcode is the programming language available within the MUSH itself with which you can create user-defined commands and macros. It is sometimes called "softcode" to distinguish it from "hardcode", which is the language that the source code for the MUSH server is written in. (Incidentally, hardcode is written in the C programming language.) At its most basic, writing MUSHcode is just stringing together a series of commands that you would otherwise just type in one at a time. You can store MUSHcode in attributes on any type of object you own or control (including yourself!). The series of commands can be triggered by using a user-defined command or by using @trigger. (continued in help mushcode2) & MUSHCODE2 If you would like to learn more about mushcoding and how to create macros for yourself, the following help files may be useful. However, the best way to learn is by obtaining a copy of Amberyl's MUSH manual and following the examples described there. The manual is available by anonymous FTP from: ftp.pennmush.org in the directory /pub/PennMUSH/Manuals Related Help Topics (in no particular order) ------------------- ATTRIBUTES SUBSTITUTION NON-STANDARD ATTRIBUTES ENACTOR EXECUTOR USER-DEFINED COMMANDS DBREFS EVALUATION TYPES OF OBJECTS WILDCARDS STRINGS LISTS ACTION LISTS & NON-STANDARD ATTRIBUTES While there are many standard attributes in MUSH, objects can also have an unlimited number of attributes, with any name you wish to use. In the past, you were limited to attributes named VA-VZ, WA-WZ, XA-XZ; these are still available as standard attributes. However, it is strongly recommended that you use non-standard attributes and meaningful names in order to make maintaining your MUSHCode easier. To set a non-standard attribute, you can use these formats: & = OR @_ = OR @set = : You can get the value of attributes using the functions v(), get(), and xget(). You can evaluate attributes using u(), eval(), and get_eval(). All attributes can be used in attribute locks and can be 'owned' independent of object ownership. See also: ATTRIBUTES, ATTRIB-OWNERSHIP, Attribute Functions, ATTRIBUTE TREES & PARENT & PARENTS & OBJECT PARENTS Objects may have "parent" objects, from which they can inherit attributes. Once an object is given a parent, it may use the attributes on the parent just as if the attributes were on the object itself, including checking for $commands. Use the @parent command to change the parent of an object. Objects may have multiple levels of parents - thus, if #100 is the parent of #101, which is the parent of #102, object #102 checks itself, #101, and #100 for attributes. Attributes are checked on the object itself first, followed by its parent, followed by that parent's parent, and so forth. There is a (configurable) maximum length of the parent chain for an object; the default is 10. After the parent chain is exhausted, the type-specific ancestor is also checked in similar fashion. See 'help ANCESTORS' for more about ancestors. (continued in help parents2) & PARENTS2 Note that the only properties inherited are attributes. In particular, flags and exits are NOT inherited from the parent object. Also, commands which walk the attribute list (such as "examine", the LATTR() function, the HASATTR() function, @set, and @edit) only affect attributes that are on the object itself. There are some limitations to the use of @parent. The most important is that ^-pattern checking is not done on the parent of an object, unless the object is set LISTEN_PARENT. For the purposes of automated game checks, the following attributes are not inherited: CHARGES, EALIAS, LALIAS, LAST, LASTSITE, LISTEN, QUEUE, RQUOTA, SEMAPHORE, and STARTUP. The attributes inherited from the parent are treated just like its own attributes by the child. Thus, when a $-command or @trigger is executed, "me", for example, refers to the child, not the parent, and the $-command's associated actions are performed by the child. (continued in help parents3) & PARENTS3 Attributes with $-commands _are_ inherited from the parent and previous generations. Conflicts are resolved not by the $-command name, but by the attribute name. If two attributes are in "conflict", the child's attribute is used. For example: > &TEST #10=$test:@emit I'm the parent > &TEST #11=$check:@emit I'm the child > @parent #11=#10 > test (nothing happens) > check I'm the child (continued in help parents4) & PARENTS4 If a parent has the same $-command name in a different attribute, however, BOTH the parent and child commands will execute: (continued from previous example) > &CHECK #10=$check:@emit No, I'm the parent! > check I'm the child No, I'm the parent! @parent is most useful when several objects use common attributes. It is slightly faster to have $commands on the child object which in turn @trigger or otherwise retrieve attributes inherited from the parent object, rather than having the $commands checked on the parent object. (continued in help parents5) & PARENTS5 Parent-object $-command checking is at its most efficient when there are few or no attributes on the child. Also, each additional level of parents further reduces efficiency. Finally, note that ancestors are *not* checked for $-commands. If you are "mass-marketing" your objects, you can create blank copies, and @parent those copies to a template object. You can then customize necessary attributes on the copy. When a buyer @chowns his copy, the parent does not change, so unless you're putting data into the parent that you want to make impossible to read, it's safe to allow the purchasers of your object to @chown their copy. See also: @parent, $-COMMANDS, ATTRIBUTES, ANCESTORS & POWERS LIST Powers can be granted only by wizards, using the @power command. Powers cannot be granted to guest characters or players who are set UNREGISTERED. Powers normally give the player the ability to use a limited set of wizard/admin powers. announce Can use @wall command. boot Can use @boot command. builder Can use Builder commands. chat_privs Can use Admin channels. debit Can use give with a negative amount. functions Can use @function command. guest Guest. Restricted command set. halt Can @halt others' objects and do @allhalt. hide Can hide on the WHO list. idle No inactivity timeout. link_anywhere Can @link an exit to anyplace. login Not subject to login restrictions. long_fingers Can do things remotely, like "get". many_attribs Can exceed max_attrs_per_obj. (continued in help powers2) & POWERS2 & POWERS LIST2 no_pay Doesn't need money for anything no_quota Has an unlimited quota open_anywhere Can @open a link from any room. pemit_all Can @pemit to HAVEN/ulocked players. player_create Can use @pcreate command. poll Can use @poll command. pueblo_send Can use xch_cmd and send pueblo tags queue Has queue limit equal to the size of the database. quota Can use @quota commands on other players. search Can do @search, @stats, and @entrances on anything. see_all Sees everything as if it were Visual. see_queue Can do @ps on anyone, and @ps/all. sql_ok Can perform SQL queries tport_anything Can @teleport anything. tport_anywhere Can @teleport to anywhere. unkillable Can not be killed can_nspemit Can use @nspemit and nspemit() See also: help @power, and especially @power/list & PUPPETS A thing is turned into a puppet by setting the PUPPET flag on it. A puppet object is an extension of its owner and relays everything it sees and hears to its owner, except if it is in the same room as the owner (a puppet with the VERBOSE flag will relay even if it's in the same room). Things relayed by the puppet will be prefixed by the name of the puppet. Puppets are useful for keeping track of what is going on in two rooms at once, as extensions of a player (such as a pet, for example), or for testing code. You can control your puppets using the @force command. It is important to remember the DBREF numbers of your puppets so you can control them even if they are not in the same room with you. You can also have your puppets follow you by using the 'follow' command. (example in help puppets2) & PUPPETS2 An example of a puppet: > @create Punch Created: Object #18. > drop Punch Dropped. > @set punch=puppet Punch is now listening. Flag set. > @force punch=go north Punch has left. Punch> The Finishing Place Punch> Punch> Obvious exits: Punch> Door #18 :waves hello Punch> Punch waves hello See also: PUPPET, @force, DBREF & QUEUE QUEUE The queue is the waiting line for commands to be executed by the MUSH. Each time you enter a command, it goes into the queue and stays there until its turn comes up, at which time the MUSH processes the command and you see the results. The MUSH can execute several commands every second, so normally you see results right away. However, if there are too many commands in the queue, there may be a delay, called lag. The more common cause of lag, however, is network delays between you and the MUSH. The QUEUE attribute is only visible to objects that control you (wizards, you, and your objects) or unless you are VISUAL. It tracks how many active commands you have in the queue. See also: @ps, LOOPING & REGEXP & REGEXPS (This help text is largely from TinyMUSH 2.2.4, with permission) The majority of matching in MUSH is done with wildcard ("globbing") patterns. There is a second type of matching, using regular expressions, that is available in certain circumstances. For attributes that are $-commands or ^-listen-patterns, setting that attribute "regexp" (with '@set /=regexp') causes patterns to be matched using regular expressions rather than globbing. In addition, the function regmatch() performs regular expression matching. In a regular expression match, the substring of the string which matched the regexp pattern is %0; %1 through %9 are the substrings of the string which matched parenthesized expressions within the regexp pattern. Continued in 'help regexps2'. & REGEXPS2 Regular expressions are extremely useful when you want to enforce a data type. For example, if you have a command where you want a player to enter a string and a number ('+setnum =', for example), you might do it like this: &DO_NUM Command Object=$^\+setnum (.+)=([0-9]+)$: @va me=Data: %1 = %2 @set Command Object/DO_NUM = regexp Then, '+setnum cookies=30' would set VA to "Data: cookies = 30". This eliminates your having to check to see if the player entered a number, since the regular expression matches only numbers. Furthermore, the '+' guarantees that there needs to be at least one character there, so a player can't enter '+setnum cookies=' or '+setnum =10' or similarly malformed input. The '+' sign in the command has to be escaped out, or it is taken as a regexp token. Furthermore, the pattern-match has to be anchored with ^ and $, or something like 'try +setnum cookies=30 now' would also match. Regular expression syntax is explained in 'help regexp syntax'. & REGEXP SYNTAX PennMUSH uses PCRE for its regular expression engine. PCRE is an open source library of functions to support regular expressions whose syntax and semantics are as close as possible to those of the Perl 5 language. The text below is excerpted from its man page. PCRE was written by Philip Hazel , and is Copyright (c) 1997-1999 University of Cambridge, England. You can find it at ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ (Note that in PennMUSH, if the regular expression is in an eval'd context (like an argument to regmatch), you'll have to do a lot of escaping to make things work right. One way to escape an argument like %0 is: regeditall(%0,\\W,\\$0) or similar). Regular expression matching in PennMUSH can be used on user-defined command or listen patterns. In this usage, regular expressions are matched case-insensitively unless the attribute has the CASE flag set. Regular expressions can also be matched in MUSHcode using regmatch(), regrab(), regedit, etc. function families, which usually come in case-sensitive and case-insensitive versions. (Cont'd in help regexp syntax2) & regexp syntax2 A regular expression is a pattern that is matched against a subject string from left to right. Most characters stand for themselves in a pattern, and match the corresponding characters in the subject. There are two different sets of meta-characters: those that are recognized anywhere in the pattern except within square brackets, and those that are recognized in square brackets. Outside square brackets, the meta-characters are as follows: \ general escape character with several uses ^ assert start of subject $ assert end of subject . match any character except newline [ start character class definition | start of alternative branch ("or") ( start subpattern ) end subpattern ? 0 or 1 quantifier (after a unit to quantify) or, minimal match (after a quantifier) or, extends the meaning of ( after a ( * 0 or more quantifier + 1 or more quantifier (Cont'd in help regexp syntax3) & regexp syntax3 Part of a pattern that is in square brackets is called a "character class". It matches any character listed in the class. In a character class, the only metacharacters are: \ general escape character ^ negate the class, if the first character in the class - indicates character range (e.g. A-Z, 0-4) [:NAME:] A symbol for a group of characters that can vary according to the language the mush is using. See 'help regexp classes' for more information. ] terminates the character class A backslash will escape most metacharacters, and can turn some normal characters into generic character types: \d any decimal digit \D any character that is not a decimal digit \s any whitespace character \S any character that is not a whitespace character \w any "word" character (letter, digit, or underscore) \W any "non-word" character (Cont'd in help regexp syntax4) & regexp syntax4 A backlash can also be used for two useful assertions -- conditions that must be met at a particular point in a match: \b word boundary \B not a word boundary A word boundary is a position in the subject string where the current character and the previous character do not both match \w or \W (i.e. one matches \w and the other matches \W), or the start or end of the string if the first or last character matches \w, respectively. (Cont'd in help regexp syntax5) & regexp syntax5 Quantifiers specify repetition of characters. Three are available: * match 0 or more of whatever came before + match 1 or more of whatever came before ? match 0 or 1 of whatever came before (In theory, you can match m-n of whatever came before with {m,n}, but the MUSH parser makes it difficult to use {}'s in functions unless you store the regex pattern in an attribute and use v() to fetch it) Quantifiers are usually greedy -- they match as much as possible. Adding a ? after a quantifier causes it to match as little as possible instead. (Cont'd in help regexp syntax6) & regexp syntax6 Outside a character class, a backslash followed by a digit greater than 0 (and possibly further digits) is a back reference to a capturing subpattern earlier (i.e. to its left) in the pattern, provided there have been that many previous capturing left parentheses. A back reference matches whatever actually matched the capturing subpattern in the current subject string, rather than anything matching the subpattern itself. So the pattern (sens|respons)e and \1ibility matches "sense and sensibility" and "response and responsibility", but not "sense and responsibility". You can give names to subpatterns and refer to them that way instead of using numbers. (?Psubexpr) (Note: Literal <>'s) is a named capture, and (?P=NAME) refers back to it. The above pattern might be written: (?Psens|respons)e and (?P=word)ibility (Cont'd in help regexp syntax7) & regexp syntax7 An assertion is a test on the characters following or preceding the current matching point that does not actually consume any characters. There are two kinds: those that look ahead of the current position in the subject string, and those that look behind it. An assertion subpattern is matched in the normal way, except that it does not cause the current matching position to be changed. Lookahead assertions start with (?= for positive assertions and (?! for negative assertions. For example, Lookbehind assertions start with (?<= for positive assertions and (? say regmatch(foo_bar, lit(^[[:word:]]+$)) You say "1" > say regmatch(foo bar, lit(^[[:word:]]+$)) You say "0" Other, less useful, character class keywords include ascii, cntrl, graph, print, punct, and xdigit. & REGEXP EXAMPLES Topic: REGEXP EXAMPLES The regexp pattern '.' is equivalent to the wildcard '?'; it matches one and only one of an arbitrary character. The regexp pattern '.+' is equivalent to the wildcard '*'; it matches one or more arbitrary characters. To match zero or more arbitrary characters, the regexp pattern is '.*'. To match a string of numbers, use: [0-9]+ or \d+ To match a string of letters only, use: [A-Za-z]+ or \w+ See 'help regexp syntax' for a more detailed explanation. & REGISTERS A register is essentially a little reserved piece of computer memory that can hold some variable information that you want to pass on to another command. There are ten registers on the MUSH available via %-substitution (%0 - %9) and thirty-six setq registers available via %q- substitution (%q0 - %q9 and %qA - %qZ). The basic registers are filled with information that matches the wildcard pattern of the command trigger. (Before you say "Huh?", here's an example.) &COMMAND me=$command *+*:@emit %0 is in register 0 and %1 is in register 1. > command whee+blert foo whee is in register 0 and blert foo is in register 1. (continued in help registers2) & REGISTERS2 As you can see from the above example, the command trigger had two wildcards separated by a "+" sign. When the user types in the command with some words taking the place of the wildcards, the first register (register 0) is filled with whatever part of the command replaces the first wildcard (in this case, "whee") and the second register is filled with whatever replaces the second ("blert foo"). They can also be filled with information that is passed by an @trigger command: &SOMECODE me=@emit %0 is in register 0 and %1 is in register 1. @trigger me/somecode=whee,foo bar > whee is in register 0 and foo bar is in register 1. The registers can also be accessed using the V-function (v(0) through v(9)). Please see 'help setq()' for more information about the setq registers. See also: SUBSTITUTIONS, @trigger, USER-DEFINED COMMANDS, setq() & RQUOTA RQUOTA This attribute tracks remaining building quota if it is implemented. It is settable in-game only by a wizard, and is only visible to wizards. See also: @quota, @squota & SEMAPHORES The most complicated thing about semaphores is their name. Before you try to use semaphores, you should first be familiar with the "@wait" command. If you are, then you know that normally, you type: @wait = and the action takes place after that number of seconds has passed. With a semaphore, you instead type: @wait = @wait /= and the action takes place after the object has been "notified" that its time for it to happen. You can also set a timeout -- if the object hasn't been notified by the time that number of seconds has passed, the action will take place. Any object (player, thing, exit, room) that you control or that is set LINK_OK can be used to wait actions on. (continued in help semaphores2) & SEMAPHORES2 An object is notified using the "@notify" command. When you type "@wait =", you are adding one to the SEMAPHORE attribute on the object. When you type "@notify ", you are decreasing the SEMAPHORE attribute on the object by one. Whenever the attribute decreases, one of the actions waiting on the object takes place. The actions occur in the order they were added. You can make the semaphore attribute of an object negative by @notify-ing it more times than things have been @wait-ed on it. If you do so, anything @wait-ed on the object will add one to the SEMAPHORE attribute and the action will take place immediately. You can also make all the actions waiting on an object take place right away by using "@notify/all", or wipe all the commands out and clear the SEMAPHORE attribute by using "@drain". Please note that all SEMAPHORE attributes are cleared out whenever the MUSH is restarted. Semaphores can be used to make sure that events occur in the right order, or to make sure that two players can't use the same object at the same time. (continued in help semaphores3) & SEMAPHORES3 It's important to remember that the actions will be carried out NOT by the object that they are being @waited on, but by whichever object entered the @wait. Examples: > @wait semaphore=:tests. > @notify semaphore Wizard tests. > @wait timer/30=:waits 30 seconds. [ 30 seconds passes. ] Wizard waits 30 seconds. See also: @wait, @drain, @notify (continued in help semaphores4) & SEMAPHORES4 Semaphores can be used to enforce mutual exclusion - to prevent the same object from being used simultaneously by two players. The basic strategy is to ensure that the object always has a SEMAPHORE of -1, to enclose commands in an @wait, and to conclude the set of commands with an @notify me: > &doit obj = $doit: @wait me={&doer me = %N; @tr me/report} > &report obj = "[v(doer)] did it!; @notify me > @startup obj = @drain me; @notify me > @notify obj > ex obj/SEMAPHORE SEMAPHORE [#1ic+]: -1 > doit obj says "Talek did it! > ex obj/SEMAPHORE SEMAPHORE [#1ic+]: -1 If a second player types doit as well, the second player's command is put on the semaphore queue and not run until the @notify me at the end of the REPORT attribute. Note the STARTUP attribute - because semaphores are cleared when the MUSH starts up, you must insure that the object gets @notify'd once when it starts up. (Continued in help semaphores5) & SEMAPHORES5 Normally, semaphores use the SEMAPHORE attribute. However, other attributes can be used, as long as they follow a few simple rules: If the attribute is already set, it has to have the same owner (God) and flags as the SEMAPHORE attribute would (typically no_inherit, no_clone, and locked - see 'help @set' and '@atrlock'), and have a numeric or empty value. If it's not set, it can't be one of the built in attributes (See @list attribs) unless, naturally, it is SEMAPHORE. See the help on @wait, @notify and @drain for details, but, briefly, you can use named semaphores with / where you would normally just use in those commands. This means you can't have a un-timed semaphore on an attribute with a numeric name. (Continued in help semaphores6) & SEMAPHORES6 An example: > @wait me/semtest=think blah > ex me/semtest SEMTEST [#1ic+]: 1 > @ps ... Semaphore Queue: [#8/SEMTEST]Raevnos(#8P):think blah ... > @notify me/semtest Notified. blah This allows you to use one object to control many different things -- for example, fights in a turn-based combat sytem. & SETTING-ATTRIBUTES Standard attributes are set using @ = Nonstandard attributes are set using & = Attributes may also be set using @set =: or the attrib_set() or set() functions. Attributes are cleared using @ or & or with @wipe or wipe(). Note that if the empty_attrs configuration option is set (@config empty_attrs to check), there is a difference between clearing an attribute and setting an attribute to a null value: @va me <--- wipes out my VA attribute @va me= <--- sets my VA attribute to be empty Empty attributes retain their flags and atrlock status. Wiped attributes are gone forever. See also: ATTRIBUTES, NON-STANDARD ATTRIBUTES, @set, @wipe, attrib_set(), set(), wipe() & SPOOFING Spoofing is the act of making other characters think that a person said or did something that they did not. This is very easy to accomplish, and has some good effects, which is why it is allowed. However, abusing it is very twinkish and will most likely get you in hot water with your wizards. Note that if you are being spoofed and want to know who is doing it, you can set yourself NOSPOOF and you will be notified who is making the @emits. See also: @emit, @pemit, @remit, @oemit, NOSPOOF & STACK For those unfamiliar with the term stack, it refers to a programming data structure that follows a LIFO (Last-In-First-Out) principle. The stack in MUSH holds the ten REGISTERS, which can be accessed via the V-function (v(0) through v(9)) or via %-substitution (%0 through %9). See also: REGISTERS & STRINGS A string is simply a bunch of characters. A word is a string that begins and ends with the space character. A sentence is a string made up of smaller substrings that are words. Please note that a "word" or "sentence" in this technical sense does not have to make sense in English (or in any other language, for that matter). As far as mush functions and commands are concerned, this is a perfectly good sentence: Foozle 09blert bar baz foo. See also: string functions & % & SUBSTITUTIONS The % symbol is used in MUSH commands to indicate a substitution -- some other character(s) or words are substituted for whatever follows the % symbol. Some common substitutions are: %B = a single space (just like [space(1)]) %R = a blank line %T = A tab. Note that this may not look right on some screens. %# = dbref of the ENACTOR (object that set off the command) %N = the ENACTOR's name, first letter capitalized %n = the ENACTOR's name, first letter as-is %~ = the ENACTOR's accented name %: = the enactor's unique identifier, like objid(%#) (continued in help SUBSTITUTIONS2) & SUBSTITUTIONS2 & %2 If the ENACTOR's gender is set, you can use these substitutions to get the right pronoun for him/her: %s = subjective pronoun: he, she, it, they %o = objective pronoun: him, her, it, them %p = possessive pronoun: his, her, its, their %a = absolute possessive: his, hers, its, theirs. Case makes a difference: %S will return He, She, It, They. If you need an actual % symbol, use %% to get it. Some attributes can be retrieved via substitutions: %va-%vz = the contents of the object's VA-VZ attributes, respectively %wa-%wz, %xa-%xz = as above, for WA-WZ and XA-XZ (continued in help substitutions3) & SUBSTITUTIONS3 & %3 Other substitutions: %0-%9 = the contents of the REGISTERS 0-9, respectively %@ = the caller's dbref number. Initially same as %#, changes when something like a U-FUNCTION is called. %! = the dbref number of the object the command is on. %L = the dbref of the ENACTOR's location. %c = text of the last command, _before_ evaluation. %u = text of the last $command, after evaluation, available to locks. %? = The current function invocation and depth counts. %+ = The number of arguments passed to the current ufun. %qN = the equivalent of r(N), a register set by a setq() function. (continued in help substitutions4) & SUBSTITUTIONS4 & %4 Example: @sex me=male @drop box=%N just dropped %p box. drop box > Cyclonus just dropped his box. Let's say that Cyclonus's dbref number is #10 and the box's dbref number is #11. The dbref # of the room Cyclonus is standing in is #13. When Cyclonus dropped the box above, these were the values of the following %-variables: %N = Cyclonus %# = #10 %@ = #10 %! = #11 %L = #13 See also: EVALUATION, ENACTOR, EXECUTOR, DBREFS, v() & SUCCESS A "success" normally occurs when you attempt to do something that is restricted by an @lock and you pass the @lock. (Note that if no lock is set, you automatically pass it.) For example, the "basic" lock restricts who can pick up a player/thing or who can go through an exit. Whenever you successfully do either of these things, you will set off the basic success messages on the object whose lock you have just successfully passed. Many other actions can also be locked -- see @lock and locktypes for more information. Many of these actions have standard attributes that you can set messages in for when someone succeeds. See also: FAILURE, @lock, VERBS, ATTRIBUTES, @success, @asuccess, @osuccess & SWITCHES SWITCHES Commands can have "switches" which modify the behavior of the command. Switches are attached after the end of a command. For example, most people are familiar with the command @lock me=me The "enter" switch to @lock allows you to lock who can enter: @lock/enter me=me A command may have multiple switches: @pemit/noeval/silent me=Hi! Help on the switches available for a command is available in the help file for that command. (If you are looking for information on @switch, see 'help @switch'.) & TYPES OF OBJECTS Everything on a MUSH is an object in the MUSH database. There are four types of objects: players, rooms, exits, things. The first three are separated from each other by being set with a special FLAG: Player, Room, Exit. Any object that doesn't have one of these flags is a thing. Unique Characteristics PLAYERS Can own other objects and can be connected to. Can receive @mail. Can move around, speak/pose/emit, enter MUSH commands, enter global commands. You can have $-commands and ^-patterns on a player. Players can be carried, can carry other objects, and can follow. ROOMS Fixed container objects, linked together by exits. Cannot move. Rooms can @emit and enter MUSH commands, but they cannot execute global commands. You can have $-commands and ^-patterns on a room. (continued in help TYPES2) & TYPES2 EXITS Objects that link rooms and things together. Cannot move, but can be @teleport-ed to a new location. Exits can @emit and enter MUSH commands, but they cannot execute global commands. You can NOT have $-commands and ^-patterns on exits. Exits can lead TO things, but they can only lead FROM rooms. THINGS Can move around, speak/pose/emit, enter MUSH commands, enter global commands. Can send @mail as themselves. You can have $-commands and ^-patterns on things. Things can carry, be carried, and can follow. See also: EXITS, USER-DEFINED COMMANDS, LISTENING, GLOBALS & $-COMMANDS & MACROS & USER-DEFINED COMMANDS User-defined commands can be created by setting $-commands on players, things, and rooms. Exits cannot have $-commands. To set a $-command: & =$: Whenever someone in the same room as the object types the command name, the action list is carried out by the object, as long as: - the person typing the command passes the object's @lock/use and @lock/command - the object is not set NO_COMMAND or HALT Such attributes can also be @triggered as if the $: did not exist. It is recommended that not begin with "@", as the command parser treats @ specially and may cause your command to fail if the name might also match an attribute name. Conventionally, global commands are often named with the "+" prefix. (continued in help user-defined2) & $-COMMANDS2 & MACROS2 & USER-DEFINED2 Any number of *'s and ?'s may be in the command name. A * matches any number of characters, and a ? matches any single character. When the actions are executed, the values on the stack in %0-%9 are the portions of what the user types that match the first ten *'s or ?'s. You can also match a regular expression rather than wildcards. See 'help regexps' for details. For example, to make a 'wave' command, you could do the following: &DO_WAVE me=$wave *:pose {waves to %0.} You could then type: > wave Guest Rhyanna waves to Guest. If a command would match, but the enactor can't pass the lock, the object may define generic failure behavior by setting the COMMAND_LOCK`FAILURE, COMMAND_LOCK`OFAILURE, and/or COMMAND_LOCK`AFAILURE attributes. These are triggered on all objects with matching commands and failing locks, but only if no command successfully matched, and take the place of the usual "Huh?" message. *BE SURE TO @LOCK/USE ME==ME IF YOU SET MACROS ON YOURSELF!* See also: STACK, SUBSTITUTIONS, @lock & VERBS For most verbs there are three forms: Verb (what the Enactor sees), Overb (what others in the area see) and Averb (the action to be taken when the event happens). Example: @Drop, @Odrop and @Adrop & WARNINGS If the building warning system has been enabled in the source code, players may receive regular warnings about potential building problems on objects that they own, and will be able to check individual objects for warnings. For more information, see the following help topics: @warnings @wcheck NO_WARN warnings list & WARNINGS LIST The building warning system, if enabled, supports the following types of warnings: exit-unlinked Warn on unlinked exits exit-oneway Warn on exits with no return exit exit-multiple Warn on multiple exits from A to B exit-msgs Warn on missing succ/osucc/odrop/fail exit-desc Warn on missing description room-desc Warn on missing description thing-msgs Warn on missing succ/osucc/odrop/fail thing-desc Warn on missing description my-desc Warn on missing player description lock-checks Warn on @lock problems (continued in help warnings list2) & WARNINGS LIST2 These warnings combine the functionality of multiple warnings above: serious exit-unlinked, thing-desc, room-desc, my-desc, lock-checks normal serious, exit-oneway, exit-multiple, exit-msgs extra normal, thing-msgs all all of the above The warning "none" indicates no warnings. You can exclude warnings from a larger list by using ! after the larger list. For example: @warnings me=all !exit-oneway & WILDCARDS PennMUSH has two standard wildcards in user-defined commands: an asterisk (*) matches any string, and a question mark (?) matches a single character. For example, let's say that you want a command called "supercalifragalisticexpealidocious" (don't ask me why), but you don't want to force people to type the whole thing to trigger the command. You could use a wildcard in the command trigger to match substrings of it: &TOO_LONG_CMD object=$supercali*:@emit whee super > (nothing happens) supercali > whee supercalifra > whee supercalifragalisticexpealidocious > whee supercalifoobert > whee A backslash (\) can be used to escape * and ? if you want to match a literal asterisk or question mark. See also: USER-DEFINED COMMANDS, REGEXP & ZONE MASTER ROOMS & ZMR Zone master rooms are a subset of zones. If a room is used as a zone master, it is a zone master room (ZMR). ZMRs are like local "master" rooms. Exits in the ZMR are global to that zone, and $commands on objects in the ZMR are global to that zone ($commands on the ZMR itself, like $commands on the master room, are ignored). If a ZMR is a player's personal zone, objects in the ZMR are checked for commands that the player can use anywhere (but exits are not checked unless the player is in a zoned room). Zone master rooms are only defined if globals are used. Zone master rooms are best used for very large zones which have a lot of global exits, or for zones with restricted commands that can go on a separate use-locked object from general ones. See also: ZONES, MASTER ROOM, EVALUATION & ZONE MASTERS & ZMP & SHARED PLAYERS SHARED PLAYERS Shared players are player objects which are used to mediate shared control of objects. A shared player is an object of type PLAYER which has the SHARED flag set. They are created like ordinary players, and can connect, build, etc. The only difference is that objects owned by a shared player are controlled by anything that passes the @lock/zone of the shared player. Anyone who passes the @lock/zone of the shared player can @chown objects to it. This, however, does not refund the original creator's money or quota, as does normal. Shared players used to be known as Zone Masters. The term was changed to emphasize the fact that they are not related to zone master objects, which are used to affect search order for user-defined commands. Continued in HELP SHARED PLAYERS2 & SHARED PLAYERS2 Some suggested uses of shared players: 1. If you are working on a building project with several people, it may be useful to create a shared player and @lock/zone it to all of you. That way, all of the players working on the project will be able to modify the building, as long as the shared player owns all the objects being built. 2. If local wizards are desired, a shared player may be created and zone locked to the local wizards. Players building within that zone should be @chowning to the shared player, or logged in as it while creating objects. The local wizard will then be able to control anything within that domain as long as the object in question is owned by the shared player. & ZONES & ZONE OBJECTS & ZONE MASTER OBJECTS & ZMO Zones are areas of the MUSH that can have the same user-defined commands without having to @parent every object in the zone or make the commands mush-wide globals. The default zone is NOTHING. Any building done by a player defaults to belonging to the same zone that the player belongs to. Every zone is defined by a Zone Master Object (ZMO). The ZMO is an ordinary MUSH object owned by some player. A wizard may change the zone of an object or player to a ZMO. If the ZMO is a room, it is called a "zone master room." Most of the statements about ZMOs also apply to zone master rooms; for details, see the help topic ZONE MASTER ROOMS. See "help ZONES2" for more. & ZONES2 $commands on a ZMO are treated as global within that zone. The game attempts to match $commands for the ZMO of the player's location, as well as $commands for the player's own zone. If you want restricted global commands defined over only a small area, you can define that area to be part of a zone, and place the desired $commands upon the ZMO. If you want players to be able to use special commands for a culture they belong to, the $commands should go on the ZMO, and the players @chzoned to it so they can use the commands anywhere. See also: @chzone, SHARED PLAYERS & matching Matching is the process the MUSH uses to determine which object you mean when you try to do something with an object. Different commands do matching in different ways, but most will allow you to specify an object as: * its dbref (#7) * its full name (Box of chocolates) * part of any word in its name, if nothing else shares that part (Box) * me (yourself) * here (the room you're in) Usually, you can also qualify an object with an adjective to help the MUSH determine which object you mean. Adjectives include: * my - an object you're carrying * this - an object in your location (also: this here ) * toward - an exit in your location * 1st, 2nd, etc. - one of a set of objects with the same names. Objects are ordered in the order in which they're listed in your inventory, room contents, and exit list (in that order). If there aren't enough objects, this will fail. You may combine some adjectives (my 1st box, this here 2nd box). & &HELP This is the AHELP index. & RESTRICT Commands and functions can have their permission levels controlled in the mush config files, or by wizards from the game via @command and @function. In the config file, the syntax is: restrict_command command-name restriction [" ] restrict_function function-name restriction From the game: @command/restrict command-name=restriction [" ] @function/restrict function-name=restriction For commands, if is given, that message is sent to the player who runs it instead of a generic, unhelpful error message. (Continued in restrict2) & RESTRICT2 can be one of the following: god Command or function is usuable only by God. wizard Usable only by wizards. admin Usable only by Wiz/Roy. nogagged Usable only by non-GAGGED objects. nofixed Usable only by non-FIXED objects. noguest Usable only by non-guest @powered objects. nobody Nothing can use it. Same as the /disable switch to @command or @function. noparse Function arguments are not evaluated. Only applies to @functions. localize %q-registers are saved/restored when evaluating, as if the @function were wrapped in localize(). Commands can also use the 'noplayer' restriction, which stops player objects from using the command, as well as any generic or any . (Continued in restrict3) & RESTRICT3 In cases where there are a function and command that do the same thing (Like pemit() and @pemit), the command's restrictions are also checked when the function is called, so restricting @pemit also restricts pemit(). However, a function's restrictions are not checked when a command is called, to allow disabling side-effect functions. Some functions (Like name()) have non-side-effect and side-effect versions depending on how many arguments they're called with. The side-effect version can be disabled while keeping the safe non-side-effect form with the 'nosidefx' restriction. This can also be used to disable pure side-effect functions. pennmush-1.8.2p8/game/txt/hlp/pennconf.hlp0000644000175000017500000002665310556616672020067 0ustar noltarnoltar& @config parameters Many of the mush's run-time options can be set from the game by wizards, using @config/set