From: garnett@gestalt.austin.tx.us (John Garnett)
Newsgroups: rec.games.mud.lp
Subject: MudOS 0.9.0 Fact Sheet
Keywords: MudOS LPmud 0.9 3.1.2 3.x
Date: 14 Nov 92 03:37:34 GMT

The MudOS driver development team is pleased to announce the release of an
enhanced LPmud driver, MudOS version 0.9.

MudOS 0.9 can be obtained via an ftp site near you.  For now, we have
made MudOS available on ucbvax.berkeley.edu via anonymous ftp.  Look
in the /pub/games/lpmud/MudOS directory for MudOS_0.9.tar.Z.

MudOS is an enhanced LPmud.  It is based on Lars Pensj|'s LPmud
version 3.1.2.  However, MudOS is not 100% compatible with all vanilla LPmud
mudlibs.

New features for all players:
   - faster
   - stable (fewer crashes).  Using the latest MudOS driver, Genocide
     hasn't crashed in over two weeks worth of wars.  Other MudOS muds,
     including Overdrive, report similar stability.
   - more powerful command parsing ability so that things such as
      aliases, history and nicknames are an easily added feature (via the
     process_input() callback in the player object).
   - network connectivity - the driver directly supports the
     ability to not only talk to other muds but also to talk to any network
     service! Expect to see features from your favorite mud such as
     mudwho, intermud tell, intermud finger, intermud mail, intermud who,
     intermud travelling.  You might even see mud to unix mail gateways or
     mud net-news readers.
   
New features for mud admins:
   - MudOS runs on more architectures including: Sequent Symmetry (System VR3),
     NeXT, RS/6000, SPARCstation (sun4), HP 9000, DECstation, VAX (Ultrix),
     and probably others as well.
   - support included for BSD malloc for those machines having slow
     system mallocs.
   - may be configured to use "lazy" resets.  Lazy resets allow the
     driver to call resets in an incremental fashion rather than all at once
     (at set intervals).  When lazy resets are configured, the driver will
     only attempt to call reset in an object when an object is touched
     via a call_other or a move_object (assuming enough time has passed that
     the object needs reset).  The main benefits of lazy resets are that
     less memory will be used and the driver won't lag when the reset time
     arrives.
   - true driver-level invisible objects are supported via the set_hide()
     efunction.  Efunctions have been modified to honor the driver-level
     invisibility flag (e.g. all_inventory() won't return information on
     invisible objects).
   - hname has been replaced by addr_server and a single running copy
     may be shared by multiple MudOS drivers.
   - comes with a miniature mudlib that demonstrates some of the new
     MudOS features (including an LPC implementation of the MUDWHO protocol
     using socket efunctions).
   - possible to disallow ANSI escape codes embedded in user commands.
   - use the same driver executable for several muds using a standard
     runtime configuration file
   - change many parameters of your driver at startup time using
     your runtime configuration file.  No more need to recompile to change
     your configuration (among the parameters that may be configured at
     runtime are: mud name, path to master object, path to simul_efun object,
     port number, mudlib directory, swapfile, include directories,
     reset interval, maximum eval cost, etc).
   - more secure - several more efuns are protected, and security
     is more difficult to spoof.
   - valid_override() in master.c can be used to control which functions
     in the simul_efun object may be overriden via the efun:: prefix.
     This addition makes it possible to control the use of various
     security sensitive efuns including destruct(), exec(), move_object().
     In fact, you can use this feature to ensure that move_object() (or
     any other efun) may only be called from within a specified source file
     (e.g. /std/move.c).
   - more configurable - think shadows are too insecure?  just
     change a compile-time option, and disable them.  Many other things
     like this are easy to remove.
   - no known memory leaks - keep the mud up for much longer than
     you were able to before
   - more flexible - less of the mudlib directory organization is
     mandated by the driver.  Lay things out in the most convenient way for
     you!
   - update the master object on the fly without crashing the mud
   - 'magic' command-line functions (dumpallobj, malloc, status)
     have been converted into efuns.
   - stats kept on all efun usage - makes it easy to see what's
     really taking all of the time in your mudlib
   - restricted ed mode - allow players to use ed in a secure
     fashion for things like mail, bulletin boards, etc.
   - automatic net death notification via a call to net_dead in the player
     object.
   - the shutdown() efun may be used to control what exit code the driver
     returns when it shuts down.  This feature allows intelligent scripts
     to be written when can behave differently based on how the driver
     was shut down.
   - new efunction uptime() which reports how long the driver has been up.
   - new efunction localtime() which is an interface to the UNIX(tm)
     localtime() system call which takes time zones into account.
   
New features for mudlib developers:
   - all of the efunctions are documented in the included man pages.
   - socket efunctions - write an intermud mailer!, an intermud
     finger!, or maybe even a MUD to unix mail gateway.  By using socket
     efuns, objects have access to true sockets; that is, a single object
     can open any number (up to the maximum specified in the options.h file)
     of individual socket connections (including TCP and UDP sockets).
     Access to the socket efuns is controlled via valid_socket in master.c.
   - a socket efun tutorial (by Cynosure) makes the learning curve
     for this powerful feature less steep.
   - several examples of how to use socket efuns including a dictionary
     object allowing definitions of words to be looked up by connecting to
     a remote dictionary server.  This object should prove quite handy in
     the LPmud world given the demonstrated spelling prowess we are all
     so familiar with :) [don't despair, an approximation of the correct
     spelling is often enough for the dictionary to find the word you mean].
   - mappings (associative arrays) - mappings are similar to normal arrays
     but they may be indexed by strings, objects, arrays, and mappings, in
     addition to the usual index of type integer.  Mappings are also
     a sparse data structure.  Our mapping implementation is consistant,
     fast, and memory efficient.  Mappings are one of the more useful
     language additions to LPC that you may use.
   - virtual objects - probably one of the most useful new
     concepts in the driver.  The virtual object facility allows you to
     associate a given object with a filename not ending in .c (e.g.
     "/room/cool.r").  When MudOS attempts to load (via call_other() or
     clone_object()) a non-existent file (or one not ending in .c), the
     driver calls compile_object(filename) in master which is expected to
     return an object to be associated with the filename that the driver
     attempted to load.  From this point on, the virtual object is treated
     as if it were a normal object.  Efunctions such as find_object(),
     call_other(), clone_object() etc will work on virtual objects.
     The virtual object facility can prove quite useful.  For example,
     define an entire ocean in one file!  No need to generate every empty
     room, one after the other!  Another powerful use of virtual objects is
     the ability to design your own 'object language'.  Tired of room code
     that looks like this?
   
   void create () {
      set_short("yet another boring room");
      set_long("this is yet another boring room.  Sad isn't it?\n");
      set_light(1);
      set_exits(({"north","south"},
         {"/rooms/north_room","/rooms/south_room"}));
   }

   How about something that looked more like this?

   short : an exciting room!
   long : this is a really exiting room!  Isn't it cool?
   light : 1
   exits :
      north  /rooms/north_room
      south  /rooms/south_room

   - pass arguments through input_to() - no more need to have
     objects that only one user can manipulate at a time (because
     of global variables that can't be safely shared).  Pass
     down all of the info your function might need (as extra parameters).
   - pass multiple arguments (instead of just one) through call_out().
   - use a single interface for all communication - replace say,
     shout, write, etc. with message().  message() allows you to do things
     such as communicate with an intelligent client, write easily
     customizable earmuffs, write your own custom snoop to only catch
     certain types of messages, and much more!
   - other useful new efuns include : children() - find every
     object cloned from a given object, set_hide() - become truly invisible
     to the mud, ....
   
New features for driver hackers:

   We know that no driver totally answers all of your needs, and
   although we've tried, we know that some of you will want to make your
   own mods, so we've made it easy to do that as well.

   - easier to debug memory usage - more debugging support can be
     enabled and disabled at compile time or runtime.
   - easier to debug communication usage - more debugging support through
     incremental levels defined at compile time
   - modularization of efunctions - efuns are now much more modular.
     Instead of adding a new efun by adding a new case to the (previously)
     huge switch() statement in interpret.c, new efunctions may be added
     to any source file (the name of the driver function should be
     f_efun_name() where efun_name() is the name of the efun as added to
     func_spec.c).
   - the driver now has room for up to eighty (80) new efunctions so you will
     be able to add local enhancements without running into space
     limitations in the efun table.
   - no 100k+ files to compile.
   - runtime configuration makes it easy to test mud under various different
     configurations
   - statistics for function cache hit rate kept, and accessible
     via efuns.
   - statistics kept on all efun usage.

--
John Garnett                   garnett@gestalt.austin.tx.us (NeXT Mail ok)
Newsgroups: rec.games.mud.lp