Index: circle/ChangeLog
diff -u circle/ChangeLog:1.181 circle/ChangeLog:1.203
--- circle/ChangeLog:1.181 Tue Aug 14 21:50:43 2001
+++ circle/ChangeLog Tue Jan 15 16:19:45 2002
@@ -1,6 +1,6 @@
-
Release history:
+Version 3.00 beta pl20 release: January 15, 2002
Version 3.00 beta pl19 release: August 14, 2001
Version 3.00 beta pl18 release: March 18, 2001
Version 3.00 beta pl17 release: January 23, 2000
@@ -31,10 +31,13 @@
Legend
------
-JE = Jeremy Elson (jelson@circlemud.org)
-GG = George Greer (greerga@circlemud.org)
-AE = Alex Fletcher (furry@circlemud.org)
-DK = Daniel A. Koepke (dkoepke@circlemud.org)
+JE = Jeremy Elson (jelson@circlemud.org) Since Jul 16, 1993
+AE = Alex Fletcher (furry@circlemud.org) Since Feb 23, 1995
+GG = George Greer (greerga@circlemud.org) Since Oct 14, 1997
+DK = Daniel A. Koepke (dkoepke@circlemud.org) Since Jul 11, 1999
+
+ New applicants must have a last name alphabetically after
+'Koepke' and will only be accepted on December 2, 2001.
--- CircleMUD 3.0 patchlevel 3
@@ -3529,3 +3532,276 @@
act.comm.c, structs.h: MAX_NOTE_LENGTH moved.
-- gg - Released patchlevel 19.
+
+******** Patchlevel 20 ***************************************************
+
+8/29/2001
+
+-- gg - src/Makefile.lcc, doc/README.CYGWIN, src/structs.h: bpl19 -> bpl20
+
+-- gg - src/structs.h: shop_rnum, shop_vnum
+
+-- gg - fight.c: compute_thaco(): New function split out of hit().
+ General: Gratuitous () removal.
+ hit(): Made hit/miss logic easier to follow.
+
+-- gg - act.informative.c, act.item.c, act.other.c, act.wizard.c, class.c,
+ db.c, limits.c, objsave.c, olc.c, shop.c, spec_procs.c, utils.c:
+ Remove redundant casts.
+
+-- gg - shop.c: Clean up buffer sizes, use NULL and '\0' where
+ appropriate, redundant cast removal, remove
+ gratuitous parentheses.
+
+-- gg - General: SPECIAL() and ACMD() generally assume their argument is
+ writable and MAX_INPUT_LENGTH large so give an empty
+ temporary buffer to scribble on.
+
+-- gg - act.wizard.c: Prototype snoop_check().
+ mail.c: Prototype mail_recip_ok(), merge two 'local functions'
+ sections, 'const char *name' for mail_recip_ok().
+ db.c, db.h: load_char(): 'const char *name'
+ interpreter.c, interpreter.h: find_name(): 'const char *name'
+
+9/13/2001
+
+-- ae - world/mob/186.mob: mob #18610 had a flag problem -- too many flags
+ that didn't exist. Reported by Vladimir Nano
+
+
+-- gg - shop.c: shopping_buy(): sprintf -> strcpy.
+
+-- gg - db.c: check_bitvector_names(): New, checks for invalid bits set.
+ check_objects(): Use check_bitvector_names().
+ parse_mobile(): Check bitvectors loaded.
+ Various: More GET_OBJ_* macros.
+ constants.c: Count number of array entries for later checking.
+
+10/1/2001 -- George's e-mail backlog clearing day.
+
+-- gg - act.wizard.c: do_restore(): Don't set the skills of a do_restore'd
+ mobile. Noted by Albert Brauneis .
+
+-- gg - db.c: file_to_string_alloc(): Be nicer when trying to load text
+ files that people are reading. Idea from Peter Ajamian.
+
+-- gg - handler.c: create_money(): Don't be so repetitive. At least until
+ a variable argument strdup() function exists. Suggested by
+ Axiem j'Terre .
+
+-- gg - act.movement.c: do_doorcmd(): Do SET/REMOVE instead of TOGGLE to
+ avoid exacerbating any unsynchronized door problem. Suggested by
+ Del .
+
+-- gg - Everywhere: xxx->in_room => IN_ROOM(xxx)
+
+-- gg - class.c: title_female(): Extra implementor level removed as noted
+ by Julian Buckley.
+
+-- gg - interpreter.c: nanny(): Remove extra echo_on(). Noted by
+ Del
+
+10/15/2001
+
+-- gg - shop.c: ok_damage_shopkeeper(): Charmed shopkeepers aren't attack
+ exempt. Set the shopkeeper MOB_NOCHARM if you don't want it in
+ that situation in the first place.
+
+-- gg - spells.c: spell_charm(): Charisma-based spell duration.
+
+-- gg - mobact.c: mobile_activity(): Check charmed follower limits and
+ "leash" any mobiles with memory based on master's charisma.
+
+10/20/2001
+
+-- gg - mobact.c: Fix check to make sure we have a 'snarl' social.
+
+-- gg - spec_procs.c: Reformatting. Change 0/1 to FALSE/TRUE.
+ snake(): Fix poison frequency bug.
+ cityguard(): Charisma modifications. Chris Epler's idea.
+
+10/21/2001
+
+-- gg - lib/world/{obj,zon}/: Various extraneous spaces, ~, and $ removed.
+
+11/12/2001
+
+-- ae - lib/world/shop/: Changed the shops from using hard-coded values for
+ the item types to using the existing support for keywords.
+ Also added a small (and dirty) conversion script written by
+ gg to convert homegrown shops. (shop-convert.pl)
+
+11/14/2001
+
+-- ae - lib/world/shop: 30.shp, 54.shp: Removed Uncle Juan's shop (3008).
+ He still exists in the mob file (3008) and the items he sold
+ still exist (3012, 3013, 3014), but his shop and room (3056)
+ don't. Fixed an erroneous room in shop 5433, it had the wrong
+ room listed therein.
+
+-- gg - db.c: file_to_string_alloc(): Check showstr_count, not showstr_vector.
+ modify.c: show_string(): NULL showstr_vector after free().
+
+-- gg - shop.c, shop.h: shop->in_room should be room_vnum, not room_rnum.
+ Stupid mixing of terminology!
+ shop.c: ok_shop_room(): 'room' is a room_vnum.
+
+11/15/2001
+
+-- ae - shop.c: SHOP_FUNC() in shopkeeper special should call the function
+ with argument (which is passed to it), not 'arg' (which is a
+ global, and as such, going away). Reported by Rich Paret
+ .
+
+-- ae - act.wizard.c: snoop_check() assumes a link exists. It shouldn't.
+ Reported by Kras Kresh .
+
+11/24/2001
+
+-- gg - sysdep.h: New configurable CIRCLE_GNU_LIBC_MEMORY_TRACK.
+ comm.c: main(): Call 'mtrace()' if C_G_L_M_T (see above) is on.
+ Call destroy_db() when finished.
+ db.c: free_extra_descriptions(), destroy_db(): New.
+ reset_zone(), free_obj(): Some NOTHING/NOWHERE/NOBODY fixes.
+ free_obj(): Use free_extra_descriptions().
+ db.h: Prototype free_extra_descriptions(), destroy_db().
+ shop.h: destroy_shops(): New.
+
+11/26/2001
+
+-- gg - comm.c, mail.h, spells.h, structs.h, utils.h: Minor quibble;
+ negative numbers are actually unary expressions.
+
+11/30/2001
+
+-- ae - act.wizard.c: do_advance() had a ch and victim reversed in a flag
+ check. Oops. Reported by Patrick O'Laughlin
+
+
+12/4/2001
+
+-- gg - act.item.c: name_from_drinkcon();
+ act.movement.c: ok_pick();
+ act.wizard.c: do_at(), do_goto(), do_teleport(), do_stat_object(),
+ do_load(), do_vstat(), do_zreset(), perform_set();
+ db.c: check_start_rooms(), read_mobile(), read_object();
+ graph.c: find_first_step();
+ handler.c: char_to_room(), obj_to_room(), extract_obj(),
+ extract_char_final();
+ objsave.c: Obj_from_store();
+ olc.c: do_olc();
+ shop.c: shop_producing(), list_all_shops(), list_detailed_shop();
+ spec_assign.c: ASSIGNMOB(), ASSIGNOBJ(), ASSIGNROOM();
+ utils.h: various macros;
+ Final (?) batch of NOBODY/NOWHERE/NOTHING changes.
+
+-- gg - db.h: Export "top_of_*" variables.
+
+12/10/2001
+
+-- ae - spec_procs.c: magic_user() special tried to cast SLEEP in combat.
+ SLEEP cannot be cast in combat -- changed this to POISON
+ instead. Reported by Jason Ziegler
+ limits.c, config.c: gain_exp() has a user definable bit of
+ behaviour to stop mortals from levelling up to immort level
+ if the mud admin desires. The default behaviour is to allow
+ this. Enough people asked how to do this so it got added.
+
+12/11/2001
+
+-- ae - 25.obj: Fixed some keys that were demarked as food. Doh.
+ Reported by The Arrow
+
+1/2/2002
+
+-- gg - act.wizard.c: do_stat(): Actually use the 'name' variable.
+ Reported by .
+
+-- gg - utils.c: number(): Duh, messed up the comment by accidently swapping
+ the 'from' and 'to' variables. Must've been late.
+ Noted by Juliano Ravasi Ferraz .
+
+1/10/2002
+
+-- gg - db.c: renum_zone_table(): Better explanation of what it does, also
+ noting some assumptions it makes. Fixed to use room_rnum
+ instead of just 'int'.
+
+-- gg - utils.c: room_is_dark(): New, from the old IS_DARK() macro.
+ utils.h: Change IS_DARK; tweak some bounds checking on macros.
+
+-- gg - act.social.c: free_social_messages(): New.
+ ban.c: Free_Invalid_List(): New.
+ boards.c: Board_clear_all(), Board_clear_board(): New.
+ boards.h: Prototyping the above.
+ comm.c: main(): Big list of other memory to free on shutdown.
+ db.c: free_text_files(), free_player_index(), free_help(): New.
+ do_reboot(): Use free_help().
+ db.h: Prototype the above three new functions.
+ fight.c: free_messages(), free_messages_type(): New.
+ mail.c: clear_free_list(): New.
+
+-- gg - castle.c: castle_mob_spec(): New.
+ assign_kings_castle(): Use castle_mob_spec().
+ castle_virtual(): Use correct NOWHERE/NOTHING/NOBODY.
+
+-- gg - shop.c: read_type_list(): Handle end markers a little better.
+
+-- gg - castle.c: block_way(): room_vnum not room_rnum.
+ From Juliano Ravasi Ferraz .
+
+1/13/2002
+
+-- gg - utils.c: get_line(): Handle \r in case the C library doesn't.
+ Fixes running under Cygwin which doesn't remove it.
+ From Patrick Dughi .
+
+-- gg - structs.h: Move toward unsigned index variables. Leave it as a
+ configuration option, defaulting to signed, for now.
+
+-- gg - act.wizard.c: do_purge(): Properly destroy equipment with
+ delayed extraction behavior. From
+ Juliano Ravasi Ferraz .
+
+-- gg - handler.c: extract_char(): Must remember the link-challenged.
+
+-- gg - act.other.c, act.wizard.c, class.c, comm.c, db.c, db.h, handler.c,
+ interpreter.c, limits.c, objsave.c: No longer twiddle the load
+ room in save_char(), nor pass it as a parameter. Any place
+ needing to change it use GET_LOADROOM. It's cleared upon login
+ to prevent it from sticking around forever, unless PLR_LOADROOM
+ is set. From Juliano Ravasi Ferraz .
+
+1/14/2002
+
+-- ae - doc: Added the new pdf versions of the documents that have outdated
+ all of the prior text files. With this patch level, most of
+ the documents are (unfortunately) only available in PDF
+ format, but with Patch Level 21, they will be available in
+ text and html also.
+
+1/15/2002
+
+-- gg - db.c: parse_simple_mob(): Format correct number (3) of arguments.
+ From Juliano Ravasi Ferraz .
+
+-- gg - act.wizard.c: do_teleport(): Stupid logic inversion fixed. This
+ was introduced in an earlier change this patchlevel.
+
+-- gg - act.wizard.c: do_load(): 'mob_vnum r_num'...? Fixed. Another
+ inter-patchlevel fix.
+
+-- gg - act.wizard.c: do_purge(): When clearing objects from characters,
+ also clear the ground afterwards.
+
+-- gg - ban.c: Free_Invalid_List();
+ db.c: free_text_files(), free_help(), free_player_index():
+ Make usable even when not shutting down.
+
+-- gg - act.informative.c: print_object_location();
+ objsave.c: Crash_is_unrentable():
+ '[<>]=? NOWHERE' is a nonsensical comparison.
+
+-- gg - shop.c: destroy_shops(): Make usable without shutdown.
+
+-- gg - Released patchlevel 20.
Index: circle/FAQ
diff -u circle/FAQ:1.14 circle/FAQ:1.16
--- circle/FAQ:1.14 Wed May 16 09:47:50 2001
+++ circle/FAQ Mon Jan 14 17:05:05 2002
@@ -1,3 +1,8 @@
+WARNING: THIS FAQ IS OUT OF DATE
+ Please reference the FAQ in the doc/ directory of the distribution
+ instead. It is significantly more current.
+
+
Frequently Asked Questions (FAQ) for Circle DikuMud with Answers
Alex Fletcher, furry@circlemud.org
@@ -159,7 +164,7 @@
6. CircleMUD 3.0 Questions
- 6.1 Are there any bugs in patch level 18?
+ 6.1 Are there any bugs in patch level 19?
6.2 How do I access Online Creation?
@@ -277,8 +282,7 @@
The latest full release of Circle is 2.20, released on November 17, 1993.
-Currently 3.0 is in beta, at patch level 18, released on March 18, 2001
-(3/18/2001, get it?).
+Currently 3.0 is in beta, at patch level 19, released on August 14, 2001.
1.5. What is the history of CircleMUD?
@@ -290,7 +294,7 @@
o Version 2.11: September 19, 1993
o Version 2.20: November 17, 1993
-Version 3.00 is currently in beta right now and is up to patchlevel 18. The
+Version 3.00 is currently in beta right now and is up to patchlevel 19. The
final release is due out Real Soon Now(tm). Don't bother posting requests
for it. It will be out when Jeremy gets it done, and it will be announced
on the mailing list and the newsgroup rec.games.mud.diku.
@@ -1141,7 +1145,7 @@
In /etc/rc.d/rc.local find where things like sendmail and (maybe) gpm
are started. Add something like:
-cd /home/mudlogin/circlebpl18/
+cd /home/mudlogin/circlebpl19/
su mudlogin -c ./autorun &
cd
@@ -1251,7 +1255,7 @@
6. CircleMUD 3.0 Questions
-6.1. Are there any bugs in patch level 18?
+6.1. Are there any bugs in patch level 19?
There are no bugs. Only features. Seriously though, if perchance you find
a bug, please mail it (along with a possible fix) to the bugs database
Index: circle/README
diff -u circle/README:1.12 circle/README:1.14
--- circle/README:1.12 Thu Aug 19 08:33:52 1999
+++ circle/README Thu Aug 23 08:32:28 2001
@@ -80,7 +80,7 @@
doc/README.UNIX - If you have any type UNIX system, including Linux,
MkLinux, Ultrix, HP/UX, Solaris, SunOS, IRIX, FreeBSD,
- OpenBSD, NetBSD, BSDi, etc.
+ OpenBSD, NetBSD, BSDi, Macintosh OS X, etc.
doc/README.WIN - If you have Windows 95 or NT.
@@ -89,9 +89,6 @@
doc/README.AMIGA - If you are using an Amiga running AmigaDOS. (If you're
running NetBSD or Linux on an Amiga, use README.UNIX
instead.)
-
-doc/README.MAC - If you are using a Mac running System 7/8. (If you're
- running MkLinux on a Mac, use README.UNIX instead.)
doc/README.ARC - If you are using an Acorn running RiscOS.
Index: circle/doc/FAQ.pdf
Index: circle/doc/README.CYGWIN
diff -u circle/doc/README.CYGWIN:1.5 circle/doc/README.CYGWIN:1.6
--- circle/doc/README.CYGWIN:1.5 Sun Mar 18 19:39:25 2001
+++ circle/doc/README.CYGWIN Wed Aug 29 08:39:56 2001
@@ -32,14 +32,14 @@
3) Download and uncompress the latest version of CircleMUD according to the
instructions in the main README file. (The FTP site is ftp.circlemud.org,
in the pub/CircleMUD directory). Make sure that if you have downloaded the
- "zipped" version (circle30bpl19.zip, or example), that you use an unzip
+ "zipped" version (circle30bplXX.zip, or example), that you use an unzip
program which can handle long file names to unzip it (like the Win32 version
of Info-Zip's "unzip"). Otherwise, download ther "tarred, gzipped" version
- (circle30bpl19.tar.gz), and extract the files using the versions of tar and
+ (circle30bplXX.tar.gz), and extract the files using the versions of tar and
gunzip which come with the full Cygwin package.
4) Start the "bash" shell and go to the directory where you have extracted
- CircleMUD (we will assume "C:\circle30bpl19", or "/circle30bpl19" from
+ CircleMUD (we will assume "C:\circle30bpl20", or "/circle30bpl20" from
within bash). DO NOT go into the "src" directory yet.
5) Run the shell script "./configure". This will automatically detect
@@ -51,9 +51,9 @@
an executable, you can also try "sh configure", "sh ./configure",
"bash configure" and "bash ./configure" until one of them works.
-6) NOW change to the /circle30bpl19/src directory, and type "make", and watch
+6) NOW change to the /circle30bpl20/src directory, and type "make", and watch
CircleMUD and the additional utilies included in the Circle distribution
- automatically being compiled and placed in /circle30bpl19/bin.
+ automatically being compiled and placed in /circle30bpl20/bin.
7) Make sure your TCP/IP stack is installed, correctly configured, and running.
If you are already using TCP/IP applications from your Windows machine such
@@ -68,7 +68,7 @@
YOU MUST INSTALL AND CONFIGURE YOUR TCP/IP STACK, EVEN IF YOU ARE NOT
CONNECTED TO THE INTERNET.
-8) Go back to /circle30bpl19, and run the MUD either directly by typing
+8) Go back to /circle30bpl20, and run the MUD either directly by typing
"bin/circle", or by using the "./autorun" script.
9) Start a telnet program (SEE NOTE BELOW). Open a connection to your
@@ -105,7 +105,7 @@
answered in this README file, or in other documents included in the CircleMUD
distribution. If you are still having problems and you're *sure* that this
your question is not answered in this document or in one of the others files
-in the /circle30bpl19/doc directory, try reading the CircleMUD FAQ at
+in the /circle30bplXX/doc directory, try reading the CircleMUD FAQ at
ftp://ftp.circlemud.org/pub/CircleMUD/FAQ. If all else fails, you can send me
or Jeremy Elson mail for help. Note, however, that if you ask me any question
that is answered in these documents, all we'll do is mail you the appropriate
Index: circle/doc/act.pdf
Index: circle/doc/admin.pdf
Index: circle/doc/building.pdf
Index: circle/doc/building.ps.gz
Index: circle/doc/building.txt
diff -u circle/doc/building.txt:1.3 circle/doc/building.txt:removed
--- circle/doc/building.txt:1.3 Tue Aug 14 21:49:06 2001
+++ circle/doc/building.txt Tue Jan 15 16:50:01 2002
@@ -1,2214 +0,0 @@
-The CircleMUD Builder's Manual
-Jeremy Elson, jelson@circlemud.org
-Revision 1.14, 30 September 1996, for CircleMUD 3.00
-
-This document describes how to create CircleMUD areas, and specifies
-the file formats for worlds, mobiles, objects, shops, and zones, as
-well as providing examples of each. All information necessary to
-build worlds can be found in this document. The intended audience is
-world builders interested in creating new worlds, implementors who
-need to decode existing world files, and coders extending the current
-world specification. Thanks to Jeff Fink (Teker) for documenting the
-shop format (as well as for submitting the shop code itself!), and
-Alex Fletcher (Furry) for writing parts of the Introduction. More
-information about CircleMUD, including up-to-date versions of this
-documentation in ASCII and Postscript, can be found at the CircleMUD
-Home Page or FTP site
-.
-______________________________________________________________________
-
-Table of Contents:
-
-1. Introduction
-1.1. Your Job as a Tinyworld Architect
-1.2. Game Balance
-1.3. Making Your Areas Interesting
-1.4. Using World-Building Programs
-
-2. The Mechanics of World Building
-2.1. Overview of the MUD World
-2.2. Learning By Example
-2.3. CircleMUD World Files
-2.4. Using Bitvectors
-2.5. Adding new areas to the MUD
-
-3. World (Room) Files
-3.1. The Format of a Room
-3.2. The Direction Field
-3.3. Room Extra Descriptions
-3.4. World File Example
-
-4. Mobile (Monster) Files
-4.1. The Format of a Mobile
-4.2. Type S Mobiles
-4.3. Type S Mobile Example
-4.4. Type E Mobiles
-4.5. Type E Mobile Example
-4.6. E-Spec Keywords Valid in CircleMUD 3.00
-
-5. Object Files
-5.1. The Format of an Object
-5.2. Object Value Definitions
-5.3. Object Extra Descriptions
-5.4. Object Affect Fields
-5.5. Object File Example
-
-6. Zone Files
-6.1. The Format of a Zone File
-6.2. Zone Commands
-6.3. Zone File Example
-
-7. Shop Files
-7.1. CircleMUD v3.0 Shop Format
-7.2. Item Name Lists for 3.0 Shops
-7.3. The DikuMUD Gamma and CircleMUD 2.20 Shop Format
-
-8. Spell Numbers
-
-9. Item Values for Drink Containers
-______________________________________________________________________
-
-1. Introduction
-
-1.1. Your Job as a Tinyworld Architect
-
-As a Tinyworld Architect or Builder, your job is to create the virtual
-world in which players can roam around, solve puzzles, find treasures,
-and gain experience. A Builder creates the rooms, objects, and
-monsters with which players will interact, defining their textual
-descriptions, stats, abilities, and other special properties. A
-Builder should not be confused with the MUD's Coder, whose job it is
-to modify the C code that makes the CircleMUD server actually run. A
-Builder does not need to be a programmer, and building is not
-programming; building is done by writing data files in a particular
-format, which this document describes in detail.
-
-There is a standard world included with the CircleMUD distribution
-which is intended to serve as a stepping stone and a basic guide to
-demonstrate what kind of worlds you can build for your MUD. To only
-use the standard CircleMUD world, without adding any original work, is
-to guarantee your MUD will be boring and largely ignored. MUDs are
-judged in many ways, but one of the most important is the number and
-quality of areas available. The areas are what tend to make a MUD
-original. For example, one MUD could be based upon a magic-rich world
-and the code and areas would reflect this, while another could revolve
-around cities and thieves. Each of these MUDs would have its areas
-designed in such a way to flesh out this theme. In essence, building
-an area is like writing a book. It needs to have a plot, needs to be
-descriptive, and needs to be populated with memorable people and
-places.
-
-Writing an area requires inspiration and imagination before all else.
-Ideas for areas often come from literature; for example, an area that
-traces Alice's adventures through Wonderland or Dante's trip through
-the Inferno. Areas usually start out on paper long before they reach
-a computer; a general map of the region can help to solidify the idea
-and a specific map of each individual room is absolutely required so
-that the rooms can be linked together in a way that makes sense
-geographically. Taking notes on ideas for which monsters should be
-encountered in the area, their descriptions, and in what location the
-monsters should appear can also help when planning an area.
-
-1.2. Game Balance
-
-``Game Balance'' is a term that brings a different thing to mind for
-every person that hears it. What is most important about game balance
-is to keep in mind for whom each area is designed--for example, high
-level players, newbies, or small groups. The objects and monsters
-found in the area should match the level, abilities, and needs of the
-players expected to use the area. Most players do not like to be
-given vast treasure with no difficulty in getting it, but on the other
-hand, nobody likes to fight the most difficult mobile on the MUD and
-get nothing for doing it. The job of the chief builder of a MUD and
-the authors of the individual areas is to find a happy medium between
-these two extremities. The process of finding that medium on your MUD
-is what makes MUDs original.
-
-The main factor that affects game balance is the areas that make up
-the MUD. Because of this, each area should be checked against the
-others to ensure that one area is not impossibly hard or absurdly easy
-or rewarding relative to the rest of the world. Each area that comes
-with the MUD or is added later should be checked by one or more
-implementors or builders, and the characteristics of the mobiles and
-objects should be changed to suit to the balance of the MUD. Each new
-area that becomes part of the world should not be added until it has
-been similarly balanced to the implementors' satisfaction.
-Understandably, builders want their zones to be popular, but they
-sometimes attempt to achieve this goal by purposefully making their
-zone unbalanced, adding powerful weapons or armor with no harmful
-side-effects or mobiles that are easy to kill yet give massive numbers
-of experience points. Such zones are destined both to become very
-popular and invariably to bring about the death of your MUD's game
-balance.
-
-An area's balance should be an integral part of the design process,
-not something to be tacked on as an afterthought. Too often, an area
-will be designed with outrageously good weapons and armor which throws
-off the balance of the game. Naturally, after such zone is added,
-players complain bitterly if it is ever removed or toned down. Also,
-because the rent system saves hitrolls, damrolls, and ac-apply's,
-veteran players will be able to hold on to their old, spectacular
-equipment unless it is explicitly taken from them, even after the area
-has been changed. This does nothing but generate bad feelings on all
-sides. Therefore, the wise implementor will always carefully check a
-zone for balance before it is added to the production MUD. It is
-generally not a good idea to ``let the players balance the area'' by
-unleashing an unbalanced area on them and watching to see where the
-hordes of players go.
-
-1.3. Making Your Areas Interesting
-
-An interesting area will always attract more players than a bland one.
-There are many ways to make an area interesting. Try to be as
-descriptive as possible; don't hold back on writing extra
-descriptions. Players are so accustomed to not having richly
-described areas that finding an extra description can often be a real
-treat. Also, one oft forgotten thing to describe are the door exits.
-Describing all of these can give a feel of standing out in a field and
-looking off to the north and seeing something like:
-
- The fields stretch off towards the large hills on the horizon. Far to
- the north you see what appears to be a plume of smoke.
-
-With door descriptions like these, an area will feel more fleshed out
-to the player. Many players (both experienced and first timers) read
-the descriptions carefully the first time they walk through an area,
-and having many extra descriptions helps them fill out their idea of
-what things actually look like.
-
-One thing that should never be done is to have generic room
-descriptions like ``You stand in a big room. It is very dark.''
-Descriptions like these detract in general from the rest of the world,
-and if they are found room after room can bore a player to tears.
-Such a description could be changed to:
-
- You stand in a room of very large size. Shadows cower along the
- walls and almost seem to be moving as you look around yourself. The floor
- is made of heavy stones which are very dark in color. The ceiling is
- quite some distance above you, but you can still make out objects hanging
- from it, ruining the smoothness that is characteristic of the rest of the
- room.
-
-Another way to make an area interesting is to create some sort of plot
-line for it, or a coherent theme, rather than a collection of
-haphazardly related rooms. The plot can be complex like infiltrating
-a castle to garner the war plans of the evil Lord Zygol, simple like
-ridding the caves of goblins, or anything in between. Often the plot
-in an area can be advanced by some fairly simple puzzles or
-descriptions. With the help of special procedures written in C by the
-MUD's coder, involved puzzles of Zork-like complexity can be readily
-created.
-
-Not all mobs have to be designed to be killed, nor does every
-shopkeeper have to buy or sell something--they could just be created
-so that they refuse to trade with any player characters. The players
-will then wonder why the shopkeeper exists. Perhaps giving him a
-jewel will make him more friendly. In this way, an area can be made
-infinitely more exciting by coding some special procedures for it.
-Perhaps random teleporters throughout the area, perhaps some
-procedures that have mobiles respond to questions from players.
-
-All in all, the best way to make an area interesting is to use
-variety, intelligence, and imagination in building. Try to imagine
-what it would be like for you to walk through and what you might try
-looking at or doing, and then try to incorporate that into your area.
-Show your area to others and take their advice. By taking all of this
-extra effort in creating your area, you will be rewarded by leaving a
-lasting memory of your area in the minds of many players.
-
-1.4. Using World-Building Programs
-
-In the old days, the only tool that was used (or required) to write a
-MUD area was a simple text editor. However, in the course of time,
-various people have written programs to help builders create worlds
-without having to understand the complex details of the world file
-format. World- building programs are becoming more popular,
-especially the fancy graphical builders that run under Microsoft
-Windows. You may prefer to use one of them rather than trying to use
-a simple text editor and understanding the format on your own. New
-world-builders are constantly being written and released, so any
-attempt to describe them here will almost certainly be obsolete by the
-time you read it. However, some of them can be found in the contrib
-section of CircleMUD's official FTP site
-.
-
-2. The Mechanics of World Building
-
-2.1. Overview of the MUD World
-
-CircleMUD's world is divided into distinct sections called zones. Each
-zone typically consists of a single, modular, geographically coherent
-region of the MUD's virtual world with a consistent storyline. Each
-zone can define its own physical space (the world), monsters (usually
-called mobiles), objects (such as armor, weapons and treasures), and
-shops, in which a mobile in a particular room can buy and sell objects
-to players.
-
-A single zone typically contain less than 100 rooms, 100 monster
-definitions and 100 object definitions, but a large region can be
-subdivided into several zones at the author's discretion. For
-example, the City of Midgaard is divided into two zones, one for the
-main city and one for the southern residential area. A zone can also
-use mobiles and objects defined by another zone, but this practice is
-discouraged because it makes zones less modular, meaning that it
-becomes more difficult to add or remove one zone without affecting
-another zone.
-
-Each room, mobile and object within a zone is given a unique number
-called a Virtual Number or Vnum. The Vnums for the rooms, mobiles and
-objects are independent, so there can be both a room number 3001 and
-an object number 3001. When defining and referencing parts of a zone,
-the zone author always refers to each entity by its Vnum and never by
-name. Vnums are normally not seen by players. Each zone itself also
-has a Vnum. A common convention is to number the zone with the Vnums
-of its component rooms, divided by 100. For example, Midgaard is zone
-30, consisting of rooms 3000 to 3099. Mobile and object numbering
-follows the same convention.
-
-The author of the zone can define aspects of each room such as the
-terrain type, special properties like whether the room has its own
-light source or is a death trap, and other parameters. A very
-important aspect of each room is the position of other rooms in
-relation to it; for example, from room 3014, one can go north to reach
-room 3005, east to room 3015, etc. Great care should be given to
-making the room links logical and consistent. A player who moves east
-and then immediately west should find herself back in the same room in
-which she started.
-
-Each mobile is given characteristics such as number of hit points,
-bare hand damage capability, strength, and special skills and
-abilities. Objects have parameters such as weight, value, and magical
-properties. The author can also choose how these three pieces of the
-world are combined to form the initial state of the zone: for example,
-the number of each mobile that exist and in which rooms they stand,
-the equipment that each mobile uses, objects which might be on the
-floor, and the doors which may be initially locked or unlocked.
-
-When the CircleMUD server runs the zone, it sets each zone to its
-initial state as defined by the author, and then makes the zone ``come
-alive'' by randomly making mobiles wander through the zone and, if
-desired, attack players. While the players are using the zone
-(killing the mobiles and picking up equipment) the server periodically
-resets the zone to its initial state (a zone reset) to prepare the
-zone for the next group of players.
-
-2.2. Learning By Example
-
-Before descending into the details of MUD building, it should be noted
-that the formats of the world files are sufficiently complex that it
-is probably not possible to gain a complete understanding of them
-merely by reading this documentation. This document is designed to be
-a reference manual and therefore may not serve as a particularly good
-tutorial. While there are examples provided at the end of each
-section, they are only meant to be representative and are not
-comprehensive examples of all possible ways to use the features that
-will be described. The most effective way is to learn by example:
-examine some of the areas that come with CircleMUD and try to figure
-out the meanings of the numbers in different rooms, objects, mobiles,
-and zone files, using this manual as a guide. Once you're proficient
-at reading world files, you'll find that creating them is a much
-easier task.
-
-2.3. CircleMUD World Files
-
-Each CircleMUD zone is defined by five types of files: world files,
-mobile files, object files, shop files, and zone files. World files
-(*.wld) define the actual rooms and the links from one room to
-another. Mobiles (*.mob) are the monsters which inhabit the MUD.
-Objects (*.obj) are the weapons, armor, treasure, and other objects
-manipulated by players and monsters. Shop files (*.shp) define the
-MUD's shopkeepers, controlling what they buy, sell, and say. Finally,
-Zone files (*.zon) bring all the previous elements together to define
-the initial state of the zone, describing how monsters should be
-equipped, where monsters should be placed, where objects on the ground
-should be, which doors should be locked, etc. These five types of
-files are collectively referred to as ``the world,'' or sometimes the
-``tinyworld files.''
-
-CircleMUD uses split world files to make the world easier to
-manipulate. Instead of all the rooms being lumped together in a
-single, cumbersome file, the rooms are split into many different
-files, one file for each area of the world. All five types of files
-are split in a similar manner. Circle has one directory for the room
-files (lib/world/wld), one directory for the object files
-(lib/world/obj), and so forth.
-
-Circle doesn't care how the world files are split or what the names of
-the files are, but certain conventions have developed to make
-management of the world easier. Each file typically contains
-information for only a single zone and the filename is typically the
-zone number, with an extension indicating one of the 5 file types.
-For example, the file 30.wld contains rooms 3000 to 3099 of zone 30;
-42.mob contains mobiles 4200 to 4299 of zone 42, etc.
-
-Also in each of these directories is a file called ``index'' that
-tells the server which files from that directory should be loaded when
-the server boots and a file called ``index.mini'' which (minimal) set
-of files should be loaded when the server is booted with the -m
-option.
-
-Every world file used by Circle (including the index files) must be
-terminated by the dollar sign ($) to tell the server that the file has
-ended. Without the dollar sign, the server will not boot properly.
-
-The split utility that comes with CircleMUD can be used to divide a
-large file into a number of smaller files; for example, if you have a
-large zone that you'd like to break into several smaller zones. See
-the CircleMUD Utility Manual
- for more
-information on how to use split.
-
-2.4. Using Bitvectors
-
-When learning about the formats of CircleMUD world files, you'll
-frequently see references to ``bitvectors.'' A bitvector is a group
-of flags which each can be either on or off. Bitvectors and their
-flags are used in many ways within CircleMUD, such as to define the
-personality of mobiles, the characteristics of rooms, etc.
-Understanding how to use bitvectors is essential if you want to build
-a CircleMUD world.
-
-At every point where this document says a bitvector is required, it
-will be accompanied by a table describing the flags which you can use
-with that bitvector. The table will look something like this:
-
- ______________________________________________________________________
- 1 a DIRTY The room is dirty.
- 2 b STINKY The room stinks.
- 4 c MUSHY The floor of the room feels mushy.
- 8 d SWAMPY The room resembles a swamp.
- ______________________________________________________________________
-
-Note there are four columns in the table. The first column contains
-the numeric value of the flag. The second contains the alphabetic
-representation of the flag. The third is the name of the flag, and
-the fourth is a description of what the flag does.
-
-There are two ways you can construct a bitvector with the table above:
-the numeric method and the alphabetic method. The numeric method is
-to select all flags you'd like to activate, take the numbers of those
-flags as listed in the first column of the table, and add them all up.
-The resulting sum will be the bitvector. The alphabetic method is
-much easier: just write down all the letters of the flags you'd like
-to use with no spaces in between. For both numeric and alphabetic
-bitvectors, use ``0'' to indicate a bitvector where none of the flags
-are set.
-
-For example, imagine you want to create a room that is dirty, mushy,
-and resembles a swamp, but does not stink. Using the numeric method,
-you'd look up the numbers of those three flags (1 for dirty, 4 for
-mushy, and 8 for swampy), and add them up to get 13. Using the
-alphabetic method, the bitvector would simply be ``acd''. Bitvectors
-are case-sensitive; ``acd'' is very different from ``Acd'' and
-``ACD''.
-
-At every point where the CircleMUD format requires a bitvector, you
-can write either a numeric bitvector or an alphabetic bitvector. They
-are completely interchangeable. However, be forewarned that if you
-use alphabetic bitvectors, your area will not be compatible with MUDs
-based on the original DikuMUD. Alphabetic bitvectors are a CircleMUD
-enhancement and may not be supported by MUDs based on Gamma Diku.
-
-In some bitvector tables, you will see values whose descriptions say
-``Reserved for internal use'' or ``Do not use''. You should never set
-those flag values in your world files.
-
-2.5. Adding new areas to the MUD
-
-After an area is written, there are three steps required to add it to
-the MUD for testing: copying the files into the proper directories,
-adding the new filenames to the appropriate index files, and running
-the MUD in syntax-check mode to make sure the new area is formatted
-correctly.
-
-All world-related files go in the directory lib/world. In this
-example, we will imagine that your new area is zone number 57 (which
-should consist of rooms, objects and mobiles numbered 5701-5799).
-Your zone probably has 5 files: 57.wld, 57.mob, 57.obj, 57.shp, and
-57.zon. The first step is to copy each of these files into their
-appropriate subdirectory: 57.wld should be copied to the directory
-lib/world/wld; 57.mob should be copied to the directory lib/world/mob,
-and so forth.
-
-The next step is to add the name of the newly copied world files to
-the index file contained in each of the world subdirectories. Note
-you will need to change 5 index files: one for each of the world files
-that you copied in the previous step. Adding the filenames to the
-index files tells CircleMUD that the files should be loaded; they will
-not be loaded simply by virtue of being in the correct directory.
-First, edit the file lib/world/wld/index; you should see a list of the
-current world (room) files. Add a single line that says 57.wld in the
-correct numeric order. Next, add a similar line in the other index
-files: add 57.mob to lib/world/mob/index; add 57.obj to
-lib/world/obj/index, etc.
-
-Now you can try to boot the MUD with the new world. If you're adding
-a new area which hasn't been debugged yet, it's usually a good idea to
-run Circle in its syntax-checking mode first. From Circle's root
-directory, type bin/circle -c to run Circle's syntax checker. If the
-check runs with no SYSERR messages, the syntax of the area is probably
-correct and the MUD can be safely booted. Otherwise, check the
-CircleMUD SYSERR List
- for more
-information on how to correct the formatting errors. Also, see the
-CircleMUD Administrator's Guide
- for more
-information on how to run CircleMUD or how to use the syntax checking
-mode.
-
-3. World (Room) Files
-
-3.1. The Format of a Room
-
-The format of a room is:
-
- ______________________________________________________________________
- #
- ~
-
- ~
-
- {Zero or more Direction Fields and/or Extra Descriptions}
- S
- ______________________________________________________________________
-
-There can be between 0 and 6 Direction Fields. There should not be
-more than one Direction Field for a particular direction. No Extra
-Descriptions are required but an unlimited number are allowed. Each
-room is terminated with the literal letter S.
-
- Virtual Number
- This number is critical; it is the identity of the room within
- the game. All other files will use this number to refer to this
- room. From within the game, this number can be used with
- ``goto'' to go to this room. The virtual numbers must appear in
- increasing order in the world file.
-
- Room Name
- This string is the room's title, which is displayed before the
- room description when players look at the room, or displayed
- alone if players are using ``brief'').
-
- Room Description
- The description of the room seen when they type ``look,'' or
- when they enter the room with brief mode off.
-
- Zone Number
- This number is obsolete and no longer used. Historically it
- contained the zone number of the current room but it is
- currently ignored. It is maintained as part of the format for
- backwards compatibility.
-
- Room Bitvector
- A bitvector (see section ``Using Bitvectors''), with the
- following values:
-
- ___________________________________________________________________
- 1 a DARK Room is dark.
- 2 b DEATH Room is a death trap; char ``dies'' (no xp lost).
- 4 c NOMOB MOBs (monsters) cannot enter room.
- 8 d INDOORS Room is indoors.
- 16 e PEACEFUL Room is peaceful (violence not allowed).
- 32 f SOUNDPROOF Shouts, gossips, etc. won't be heard in room.
- 64 g NOTRACK ``track'' can't find a path through this room.
- 128 h NOMAGIC All magic attempted in this room will fail.
- 256 i TUNNEL Only one person allowed in room at a time.
- 512 j PRIVATE Cannot teleport in or GOTO if two people here.
- 1024 k GODROOM Only LVL_GOD and above allowed to enter.
- 2048 l HOUSE Reserved for internal use. Do not set.
- 4096 m HOUSE_CRASH Reserved for internal use. Do not set.
- 8192 n ATRIUM Reserved for internal use. Do not set.
- 16384 o OLC Reserved for internal use. Do not set.
- 32768 p BFS_MARK Reserved for internal use. Do not set.
- ___________________________________________________________________
-
- Sector Type
- A single number (not a bitvector) defining the type of terrain
- in the room. Note that this value is not the number of movement
- points needed but just a number to identify the sector type (the
- movement loss is controlled by the array movement_loss[] in the
- file constants.c). The Sector Type can be one of the following:
-
- ___________________________________________________________________
- 0 INSIDE Indoors (small number of move points needed).
- 1 CITY The streets of a city.
- 2 FIELD An open field.
- 3 FOREST A dense forest.
- 4 HILLS Low foothills.
- 5 MOUNTAIN Steep mountain regions.
- 6 WATER_SWIM Water (swimmable).
- 7 WATER_NOSWIM Unswimmable water - boat required for passage.
- 8 UNDERWATER Underwater.
- 9 FLYING Wheee!
- ___________________________________________________________________
-
- Direction Fields and Extra Descriptions
- This section defines the room's exits, if any, as well as any
- extra descriptions such as signs or strange objects that might
- be in the room. This section can be empty if the room has no
- exits and no extra descriptions. Otherwise, it can have any
- number of D (Direction Field) and E (Extra Description)
- sections, in any order. After all exits and extra descriptions
- have been listed, the end of the room is signaled with the
- letter S. The Direction Fields and Extra Descriptions are
- described in more detail in the following sections.
-
-3.2. The Direction Field
-
-The general format of a direction field is:
-
- ______________________________________________________________________
- D
-
- ~
- ~
-
- ______________________________________________________________________
-
- Direction Number
- The compass direction that this Direction Field describes. It
- must be one of the following numbers:
-
- 0 North
- 1 East
- 2 South
- 3 West
- 4 Up
- 5 Down
-
- General Description
- The description shown to the player when she types ``look
- .'' This should not be confused with the room
- description itself. Unlike the room description which is
- automatically viewed when a player walks into a room, the
- General Description of an exit is only seen when a player looks
- in the direction of the exit (e.g., ``look north'').
-
- Keyword List
- A list of acceptable terms that can be used to manipulate the
- door with commands such as ``open,'' ``close,'' ``lock,''
- ``unlock,'' etc. The list should be separated by spaces, e.g.:
-
- door oak big~
-
- Door Flag
- Can take one of three values (0, 1 or 2):
-
- 0 An unrestricted exit that has no door, or a special door
- cannot be opened or closed with the ``open'' and ``close''
- commands. The latter is useful for secret doors, trap doors,
- or other doors that are opened and closed by something other
- than the normal commands, like a special procedure assigned
- to the room or an object in the room.
-
- 1 Normal doors that can be opened, closed, locked, unlocked,
- and picked.
-
- 2 Pickproof doors: if locked, can be opened only with the key.
-
- The initial state of all doors is open, but doors can be opened,
- closed, and locked automatically when zones reset (see the zone
- file documentation for details).
-
- Key Number
- The virtual number of the key required to lock and unlock the
- door in the direction given. A value of -1 means that there is
- no keyhole; i.e., no key will open this door. If the Door Flag
- for this door is 0, the Key Number is ignored.
-
- Room Linked
- The virtual number of the room to which this exit leads. If
- this number is -1 (NOWHERE), the exit will not actually lead
- anywhere; useful if you'd like the exit to show up on ``exits,''
- or if you'd like to add a description for ``look ''
- without actually adding an exit in that direction.
-
-3.3. Room Extra Descriptions
-
-Extra descriptions are used to make rooms more interesting, and make
-them more interactive. Extra descriptions are accessed by players
-when they type ``look at ,'' where is any word you
-choose. For example, you might write a room description which
-includes the tantalizing sentence, ``The wall looks strange here.''
-Using extra descriptions, players could then see additional detail by
-typing ``look at wall.'' There can be an unlimited number of Extra
-Descriptions in each room.
-
-The format of an extra description is simple:
-
- ______________________________________________________________________
- E
- ~
-
- ~
- ______________________________________________________________________
-
- Keyword List
- A space-separated list of keywords which will access the
- description in this E section.
-
- Description Text
- The text that will be displayed when a player types ``look
- ,'' where is one of the keywords specified in
- the Keyword List of this E section.
-
-3.4. World File Example
-
-Here's a sample entry from a CircleMUD world file:
-
- #18629
- The Red Room~
- It takes you a moment to realize that the red glow here is coming
- from a round portal on the floor. It looks almost as if someone had
- painted a picture of a dirt running through a field on the floor of
- this room. Oddly enough, it is so realistic you can feel the wind in
- the field coming out of the picture.
- ~
- 186 ad 0
- D0
- You see a big room up there.
- ~
- ~
- 0 -1 18620
- D1
- You see a small room.
- ~
- oak door~
- 1 18000 18630
- E
- portal floor~
- It looks as if you could go down into it... but you can't be sure of where
- you will end up, or if you can get back.
- ~
- S
-
-This room is virtual number 18629, called ``The Red Room.'' It is
-dark and indoors, with an ``INDOORS'' sector type. It has an exit
-north and east. The north exit leads to room 18620; if a player types
-``look north'' it will say ``You see a big room up there.'' The exit
-east is a normal, pickable door that leads to room 18630 and which
-takes key number 18000. There is one extra description for ``portal''
-and ``floor.''
-
-4. Mobile (Monster) Files
-
-4.1. The Format of a Mobile
-
-The format of a mobile is:
-
- ______________________________________________________________________
- #
- ~
- ~
-
- ~
-
- ~
-
- {type-specific information; see below for details}
- ______________________________________________________________________
-
-The format of mobiles varies depending on the Type Flag. See below
-for documentation of the formats of the various types.
-
- Virtual Number
- This number is critical; it is the identity of the mobile within
- the game. It is the number that will be used to reference the
- mobile from zone files and is the number used to ``load''
- mobiles from within the game. The virtual numbers must appear
- in increasing order in the mob file.
-
- Alias List
- The list of keywords, separated by spaces, that can be used by
- players to identify the mobile. The mobile can only be
- identified using the keywords that appear in its alias list; it
- cannot be identified by a word that appears only in its name.
- Great care should be taken to ensure that the spellings of names
- and aliases match. Fill words such as ``the,'' ``a,'' and
- ``an'' should not appear in the Alias List.
-
- Short Description
- The description of the mobile used by the MUD when the mobile
- takes some action. For example, a short description of ``The
- Beastly Fido'' would result in messages such as ``The Beastly
- Fido leaves south.'' and ``The Beastly Fido hits you hard.''
- The Short Description should never end with a punctuation mark
- because it will be inserted into the middle of sentences such as
- those above.
-
- Long Description
- The description displayed when a mobile is in its default
- position; for example, ``The Beastly Fido is here, searching
- through garbage for food.'' When the mobile is in a position
- other than its default position, such as sleeping or
- incapacitated, the short description is used instead; for
- example, ``The Beastly Fido is lying here, incapacitated.''
- Unlike the Short Description, the Long Description should end
- with appropriate punctuation.
-
- Detailed Description
- The description displayed for a mobile when a player looks at
- the mobile by typing ``look at .''
-
- Action Bitvector
- A bitvector (see section ``Using Bitvectors'') with the
- following values:
-
- ___________________________________________________________________
- 1 a SPEC This flag must be set on mobiles which have
- special procedures written in C. In addition to
- setting this bit, the specproc must be assigned in
- spec_assign.c, and the specproc itself must (of
- course) must be written. See the section on
- Special Procedures in the file coding.doc for
- more information.
-
- 2 b SENTINEL Mobiles wander around randomly by default; this
- bit should be set for mobiles which are to remain
- stationary.
-
- 4 c SCAVENGER The mob should pick up valuables it finds on the
- ground. More expensive items will be taken first.
-
- 8 d ISNPC Reserved for internal use. Do not set.
-
- 16 e AWARE Set for mobs which cannot be backstabbed.
- Replaces the ACT_NICE_THIEF bit from Diku Gamma.
-
- 32 f AGGRESSIVE Mob will hit all players in the room it can see.
- See also the WIMPY bit.
-
- 64 g STAY_ZONE Mob will not wander out of its own zone -- good
- for keeping your mobs as only part of your own
- area.
-
- 128 h WIMPY Mob will flee when being attacked if it has less
- than 20% of its hit points. If the WIMPY bit is
- set in conjunction with any of the forms of the
- AGGRESSIVE bit, the mob will only attack mobs that
- are unconscious (sleeping or incapacitated).
-
- 256 i AGGR_EVIL Mob will attack players that are evil-aligned.
-
- 512 j AGGR_GOOD Mob will attack players that are good-aligned.
-
- 1024 k AGGR_NEUTRAL Mob will attack players that are neutrally aligned.
-
- 2048 l MEMORY Mob will remember the players that initiate
- attacks on it, and initiate an attack on that
- player if it ever runs into him again.
-
- 4096 m HELPER The mob will attack any player it sees in the room
- that is fighting with a mobile in the room.
- Useful for groups of mobiles that travel together;
- i.e. three snakes in a pit, to force players to
- fight all three simultaneously instead of picking
- off one at a time.
-
- 8192 n NOCHARM Mob cannot be charmed.
-
- 16384 o NOSUMMON Mob cannot be summoned.
-
- 32768 p NOSLEEP Sleep spell cannot be cast on mob.
-
- 65536 q NOBASH Large mobs such as trees that cannot be bashed.
-
- 131072 r NOBLIND Mob cannot be blinded.
- ___________________________________________________________________
-
- Affection Bitvector
- A bitvector (see section ``Using Bitvectors'') with the
- following values:
-
- ___________________________________________________________________
- 1 a BLIND Mob is blind.
- 2 b INVISIBLE Mob is invisible.
- 4 c DETECT_ALIGN Mob is sensitive to the alignment of others.
- 8 d DETECT_INVIS Mob can see invisible characters and objects.
- 16 e DETECT_MAGIC Mob is sensitive to magical presence.
- 32 f SENSE_LIFE Mob can sense hidden life.
- 64 g WATERWALK Mob can traverse unswimmable water sectors.
- 128 h SANCTUARY Mob is protected by sanctuary (half damage).
- 256 i GROUP Reserved for internal use. Do not set.
- 512 j CURSE Mob is cursed.
- 1024 k INFRAVISION Mob can see in dark.
- 2048 l POISON Reserved for internal use. Do not set.
- 4096 m PROTECT_EVIL Mob is protected from evil characters.
- 8192 n PROTECT_GOOD Mob is protected from good characters.
- 16384 o SLEEP Reserved for internal use. Do not set.
- 32768 p NOTRACK Mob cannot be tracked.
- 65536 q UNUSED16 Unused (room for future expansion).
- 131072 r UNUSED17 Unused (room for future expansion).
- 262144 s SNEAK Mob can move quietly (room not informed).
- 524288 t HIDE Mob is hidden (only visible with sense life).
- 1048576 u UNUSED20 Unused (room for future expansion).
- 2097152 v CHARM Reserved for internal use. Do not set.
- ___________________________________________________________________
-
- Alignment
- A number from -1000 to 1000 representing the mob's initial
- alignment.
-
- -1000...-350 Evil
- -349...349 Neutral
- 350...1000 Good
-
- Type Flag
- This flag is a single letter which indicates what type of mobile
- is currently being defined, and controls what information
- CircleMUD expects to find next (i.e., in the file from the
- current point to the end of the current mobile).
-
- Standard CircleMUD 3.0 supports two types of mobiles: S (for
- Simple), and E (for Enhanced). Type C (Complex) mobiles was
- part of the original DikuMUD Gamma and part of CircleMUD until
- version 3.0, but are no longer supported by CircleMUD v3.0 and
- above.
-
- Check with your local implementor to see if there are any
- additional types supported on your particular MUD.
-
-4.2. Type S Mobiles
-
-For type S mobs, the type-specific information should be in the
-following format:
-
- ______________________________________________________________________
-
-
-
- ______________________________________________________________________
-
- Level
- The level of the monster, from 1 to 30.
-
- THAC0
- ``To Hit Armor Class 0'' -- a measure of the ability of the
- monster to penetrate armor and cause damage, ranging from 0 to
- 20. Lower numbers mean the monster is more likely to penetrate
- armor. The formal definition of THAC0 is the minimum roll
- required on a 20-sided die required to hit an opponent of
- equivalent Armor Class 0.
-
- Armor Class
- The ability of the monster to avoid damage. Range is from -10
- to 10, with lower values indicating better armor. Roughly, the
- scale is:
-
- AC 10 Naked person
- AC 0 Very heavily armored person (full plate mail)
- AC -10 Armored Battle Tank (hopefully impossible for players)
-
- Note on THAC0 and Armor Class (AC): When an attacker is trying to
- hit a victim, the attacker's THAC0 and the victim's AC, plus a
- random roll of the dice, determines whether or not the attacker can
- hit the victim. (If a hit occurs, a different formula determines
- how much damage is done.) An attacker with a low THAC0 is
- theoretically just as likely to hit a victim with a low AC as an
- attacker with a high THAC0 is to hit a victim with a high AC.
- Lower attacker THAC0's and higher victim AC's favor the attacker;
- higher attacker THAC0's and lower victim AC's favor the victim.
-
- Max Hit Points
- The maximum number of hit points the mobile is given, which must
- be given in the form ``xdy+z'' where x, y, and z are integers.
- For example, 4d6+10 would mean sum 4 rolls of a 6 sided die and
- add 10 to the result. Each individual instance of a mob will
- have the same max number of hit points from the time it's born
- to the time it dies; the dice will only be rolled once when a
- particular instance of the mob is created. In other words, a
- particular copy of a mob will always have the same number of max
- hit points during its life, but different copies of the same mob
- may have different numbers of max hit points.
- Note that all three numbers, the ``d'' and the ``+'' must always
- appear, even if some of the numbers are 0. For example, if you
- want every copy of a mob to always have exactly 100 hit points,
- write 0d0+100.
-
- Bare Hand Damage (BHD)
- The amount of damage the mob can do per round when not armed
- with a weapon. Also specified as ``xdy+z'' and subject to the
- same formatting rules as Max Hit Points. However, unlike Max
- Hit Points, the dice are rolled once per round of violence; the
- BHD of a mob will vary from round to round, within the limits
- you set.
-
- For BHD, xdy specifies the dice rolls and z is the strength
- bonus added both to BHD and weapon-inflicted damage. For
- example, a monster with a BHD of 1d4+10 will do between 11 and
- 14 hitpoints each round without a weapon. If the monster picks
- up and wields a tiny stick which gives 1d2 damage, then the
- monster will do 1d2 + 10 points of damage per round with the
- stick.
-
- Gold
- The number of gold coins the mobile is born with.
-
- Experience
- The number of experience points the mobile is born with.
-
- Load Position
- The position the mobile is in when born, which should be one of
- the following numbers:
-
- 0 POSITION_DEAD Reserved for internal use. Do not set.
- 1 POSITION_MORTALLYW Reserved for internal use. Do not set.
- 2 POSITION_INCAP Reserved for internal use. Do not set.
- 3 POSITION_STUNNED Reserved for internal use. Do not set.
- 4 POSITION_SLEEPING The monster is sleeping.
- 5 POSITION_RESTING The monster is resting.
- 6 POSITION_SITTING The monster is sitting.
- 7 POSITION_FIGHTING Reserved for internal use. Do not set.
- 8 POSITION_STANDING The monster is standing.
-
- Default Position
- The position to which monsters will return after a fight, which
- should be one of the same numbers as given above for Load
- Position. In addition, the Default Position defines when the
- mob's long description is displayed (see ``Long Description''
- above).
-
- Sex
- One of the following:
-
- 0 Neutral (it/its)
- 1 Male (he/his)
- 2 Female (she/her)
-
-4.3. Type S Mobile Example
-
- #3062
- fido dog~
- the beastly fido~
- A beastly fido is mucking through the garbage looking for food here.
- ~
- The fido is a small dog that has a foul smell and pieces of rotted meat
- hanging around his teeth.
- ~
- afghq p -200 S
- 0 20 10 1d6+4 1d4+0
- 0 25
- 8 8 1
-
-This is mobile vnum 3062. The Fido's action bitvector indicates that
-it has a special procedure (bit a), is aggressive (bit f), stays in
-its own zone (bit g), is wimpy (bit h), and cannot be bashed (bit q).
-Also, the Fido cannot be tracked (affection bit p), and has an initial
-alignment of -200.
-
-After the S flag we see that the Fido is level 0, has a THAC0 of 20,
-an Armor Class of 10, 1d6+4 hit points (a random value from 5 to 10),
-and will do 1d4 hit points of bare hand damage per round. The Fido
-has 0 gold and 25 experience points, has a load position and default
-position of STANDING, and is male.
-
-4.4. Type E Mobiles
-
-Type E mobiles are specific to Circle 3.0 and are designed to provide
-an easy way for MUD implementors to extend the mobile format to fit
-their own needs. A type E mobile is an extension of type S mobiles; a
-type E mobile is a type S mobile with extra data at the end. After
-the last line normally found in type S mobs (the one ending with the
-mob's sex), type E mobiles end with a section called the Enhanced
-section. This section consists of zero or more enhanced mobile
-specifications (or E-specs), one per line. Each E-spec consists of a
-keyword followed by a colon (``:'') and a value. The valid keywords
-are listed below. The literal letter E must then come after all E-
-specs to signal the end of the mob.
-
-The format of an E mobile is as follows:
-
-______________________________________________________________________
-
-
-
-{E-spec list}
-E
-______________________________________________________________________
-
-4.5. Type E Mobile Example
-
-Let's say that you wanted to create an enhanced Fido like the one in
-the previous example, but one that has a bare-hand attack type of 4 so
-that the Fido bites players instead of hitting them. Let's say you
-also wanted to give this Fido the a strength of 18. You might write:
-
- #3062
- fido dog~
- the beastly fido~
- A beastly fido is mucking through the garbage looking for food here.
- ~
- The fido is a small dog that has a foul smell and pieces of rotted meat
- hanging around his teeth.
- ~
- afghq p -200 E
- 0 20 10 1d6+4 1d4+0
- 0 25
- 8 8 1
- BareHandAttack: 4
- Str: 18
- E
-
-In the above example, the two E-specs used were BareHandAttack and
-Str. Any number of the E-specs can be used in an Enhanced section and
-they may appear in any order. The format is simple: the E-spec
-keyword, followed by a colon, followed by a value. Note that unlike
-type S mobiles, type E mobiles require a terminator at the end of the
-record (the letter E).
-
-4.6. E-Spec Keywords Valid in CircleMUD 3.00
-
-The only keywords supported under Circle 3.00 are BareHandAttack, Str,
-StrAdd, Int, Wis, Dex, Con, and Cha. However, the E-Specs have been
-designed such that new ones are quite easy to add; check with your
-local implementor to see if your particular MUD has added any
-additional E-Specs. Circle 3.10's Enhanced section will have
-considerably more features available such as the ability to
-individually set mobs' skill proficiencies.
-
- BareHandAttack
- This controls the description of violence given during battles,
- in messages such as ``The Beastly fido bites you very hard.''
- BareHandAttack should be one of the following numbers:
- 0 hit/hits
- 1 sting/stings
- 2 whip/whips
- 3 slash/slashes
- 4 bite/bites
- 5 bludgeon/bludgeons
- 6 crush/crushes
- 7 pound/pounds
- 8 claw/claws
- 9 maul/mauls
- 10 thrash/thrashes
- 11 pierce/pierces
- 12 blast/blasts
- 13 punch/punches
- 14 stab/stabs
-
- Messages given when attackers miss or kill their victims are taken
- from the file lib/misc/messages. The attack type number for
- weapons is 300 plus the number listed in the table above, so to
- modify the message given to players when they are mauled, attack
- type number 309 in lib/misc/messages should be changed. Note that
- adding new attack types requires code changes and cannot be
- accomplished simply by adding new messages to lib/misc/messages
- (see the CircleMUD Coding Manual
- for more
- information).
-
- Str, StrAdd, Int, Wis, Dex, Con, Cha
- The mobile's Strength, Strength Add, Intelligence, Wisdom,
- Dexterity, Constitution and Charisma, respectively. These
- values should be between 3 and 18.
-
-5. Object Files
-
-5.1. The Format of an Object
-
- ______________________________________________________________________
- #
- ~
- ~
- ~
- ~
-
-
-
- {Zero or more Extra Descriptions and/or Affect Fields}
- ______________________________________________________________________
-
-There can be an unlimited number of Extra Descriptions and up to 6
-Affect Fields.
-
- Virtual Number
- This number is critical; it is the identity of the object within
- the game. It is the number that will be used to reference the
- object from zone files and is the number used to ``load''
- objects from within the game. The virtual numbers must appear
- in increasing order in the object file.
-
- Alias List
- The list of keywords, separated by spaces, that can be used by
- players to identify the object. The object can only be
- identified using the keywords that appear in its alias list; it
- cannot be identified by a word that appears only in its name.
- Great care should be taken to ensure that the spellings of names
- and aliases match. Fill words such as ``the,'' ``a,'' and
- ``an'' should not appear in the Alias List.
-
- Short Description
- The description of the object used by the MUD when the object is
- used. For example, a short description of ``a long, green
- stick'' would result in messages such as ``The Beastly Fido
- picks up the long, green stick.'' The Short Description should
- never end with a punctuation mark because it will be inserted
- into the middle of sentences.
-
- Long Description
- The description displayed when the object is seen lying on the
- ground, for example, ``A furled umbrella is lying here.''
- Unlike the Short Description, the Long Description should end
- with appropriate punctuation.
-
- Action Description
- Action Descriptions are primarily used for magical objects
- (staves, wands, scrolls, and potions) to specify what message
- displayed to the room when the magical item is used. The Action
- Description should be given in the act format specified in
- act.doc. If no Action Description is present, a default message
- will be used:
-
- Staves: Rasmussen taps