From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.lp
Subject: Virtual Rooms and Objects (was: Re: MudOS a ripoff?)
Summary: what they are in the MudOS implementation
Date: 27 Aug 92 20:07:42 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: am.ucsc.edu


In article <37330@sdcc12.ucsd.edu> djohnson@cs.ucsd.edu (Darin Johnson) writes:
>
>Actually, what are virtual objects?  I've got virtual rooms on my
>mud, but that's with plain 'ol generic 3.1.2.  (of course, virtual
>can mean many things)
>

It does mean many things... the MOOs are using the term to mean a common 
room shared by several muds.  In MudOS, however, a virtual object differs
from a regular object *primarily* by its name.

There are two ways (so far) to create virtual objects, both of which I'll
explain here.  The first thing to explain is the mechanism used...

Let's say I type "goto /d/Sahara/desert_52,30" and there is no file called
"/d/Sahara/desert_52,30.c".  In most muds, the buck stops here... there's
no file, so if it's not loaded, then no go.  But instead, on a MudOS,
the string "/d/Sahara/desert_52,30" is passed to a function in master.c like:

object compile_object(string path) {
	return (object)VIRTUAL_D->compile_object(path);
}

which in turn passes this string to our virtual object daemon, which can
use many different methods to determine whether an object should be returned.
If the daemon decides that this isn't a virtual object filename, then it
returns 0, and the driver comes back with something like "failed to load file"
like any other LP would.

If, however, the daemon detects that this is a virtual object's filename,
then any object it returns will now have the filename identifier of
"/d/Sahara/desert_52,30"... so even file_name(ob) will return that.  What
this is useful for is a number of things.  In the case of the desert, rather 
than write a hundred rooms that all say, "This is barren, dry desert with
exits in all directions", I can just write a program that clones rooms and
sets their descriptions, then returns the rooms... and they get more useful
filenames than "/std/room#435".

The other thing the virtual object daemon might do is see if there's a file
without a .c extension in that place, that contains object description code
of some sort.  This allows us to write an object description language that
is far easier to use than LPC and much more memory efficient.  There is,
admittedly, a small CPU time tradeoff here.  However, cloning a generic
object is about 5 times as efficient as inheriting it, in many cases.
Efficiency debates aside, this lets me do something like orb.t:

--- cut here ---

short: A glowing golden orb.
value: 300
weight: 2
id: "orb" "glowing orb"
long:
This is the great orb of utter simplicity.
It appears to be pretty useless, but you could probably sell it.
**

--- cut here ---

And presto, there's your basic stupid object.  Useful for things that
don't need associated code.  And, the object description languages (ODLs)
have a long ways to go.  

Anyhow, I hope this helps explain something to someone.


>-- 
>Darin Johnson
>djohnson@ucsd.edu
>  - Grad school - just say no.

-Adam Beeman
Buddha@TMI


-- 
#include <std_disclaimer.h>
#define NAME	"Adam Beeman"
#define EMAIL	"beeman@{cats, ucscb}.ucsc.edu"
inherit SIGNATURE; // enhanced .sig virus