MudOS 0.9.0 Fact Sheet
John Garnett
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 gar...@gestalt.austin.tx.us (NeXT Mail ok)
Adam Beeman
In article <BxqxG...@news.cso.uiuc.edu> nafp...@ux2.cso.uiuc.edu (Nicholas Nafpliotis) writes:
>
>Thanks again MudOS people.
>
>Nick Nafpliotis
>
>By the way. Anyone have a mudlib for this yet? *grin*
Ahh, a very good question you ask. You probably noticed a little thingy
included with the driver, that was enough to log into, but not a heck of
a lot more. There *is* a project under way, if not several of them.
Namely, I speak of the TMI-2 mudlib, which has been a not altogether
smooth experience of writing, since everyone and his mother seems to want
to do his/her own project instead of cooperate on a bigger one. If things
go well, I'll be making a beta copy available by late late saturday night,
and then we can find out just how pathetic the whole package really is and
make the necessary changes before releasing anything we'd recommend you
use.
So, the TMI-2 mudlib is moving along... I think there's some really killer
features included, such as virtual rooms, intermud mail/tell/finger,
n-dimensional nested properties, a pub, a shop, money, full manpages for
all efuns and driver applies, customizable login prompt/screen, objects
with variable security (if you want it), a newsreader (a little buggy still),
bulletin boards, monsters, channels, spells.... I must be forgetting a few
other things. Depending on how much progress we make in this next
week, you may or may not get my new, dynamic groups object that will
allow anyone to create or maintain a group and yet do it in a secure fashion
suitable for guilds, wiz ranks/domains, mailing lists, and anything else
that you might want.
Of course, there's no doubt some essentials missing somewhere, once we make
a beta release you will all come screaming back to us that it doesn't work.
If you're a serious LPC coder and have something insanely cool that you
think this mudlib should have, let us know.
Note that TMI-2 is very unlike TMI in some ways, namely that right now
we aren't even pretending to have the time to teach people how to use
ed and update a file and stuff. It could happen, at some point, and I hate
to sound like some sort of elitist, but please don't log in and pester us
for a directory like everyone did on TMI, we're not building areas for
players and we're not gifted with tons of disk space for every newbie wizard
to come and play in... maybe someday we will be... but not now.
Experienced coders are encouraged to log in if you're thinking of lending
a hand with the next-generation distribution mudlib. We're currently
coding away on our new site, which seems to be working out pretty nicely.
-Buddha@TMI-2
tmi.iastate.edu 5555
--
-------------------------------------------------------------------------------
From the Mind of Adam Beeman || Flames: root@localhost
#include <std/disclaimer.h> || other stuff: bee...@cats.ucsc.edu
-------------------------------------------------------------------------------
Yeah, I'm into MUDs, UNIX, philosophy, art, networking, and saving the earth,
the Information Age is here and my head is too small...
-------------------------------------------------------------------------------