Greetings. :)

[Michael Hohensee]

On Mon, 31 Mar 1997 claw at null.net wrote:

> On 29/03/97 at 09:10 AM, Michael Hohensee
> <michael at sparta.mainstream.net> said:
> 
> >	After diddling around with C for half a year, I started to write 
> >what I call AeMud.  The acronym stands for Arbitrarily Expandable
> >MUD.   And, as you may have guessed, the idea was to make it so that
> >new things  would be easy to add.
> 
> I've not actually assigned a name to my server.  Way back in the dawns
> of time it was named the "Black Hat MUD Server" due to my penchant for
> fedoras, but that only lasted for the first couple weeks of
> development.  Since then it was called "Murkle" for all of about a
> week, and then nothing.  I guess I ought to name it some day.

Well, I was going to call it "MyMud" for a while, but then I found that 
name was already taken.  I used the name AeMud as a guide to my coding.  
Everthing has to work with everything else.  That's caused a few total 
re-writes. ;)
 
> >	A way of treating all objects (players, creatures, rooms, etc) as 
> >if they were the same for certain common uses. (common-use being
> >defined  as anything you want everyone to be able to do.)
> 
> Hehn.  I actually make no distinction among players, mobiles, rooms,
> objects, utility objects, etc.  There are just no unique object types. 
> They're all the same to the server.

Doesn't that waste memory?  I did that for a while, but I couldn't see 
why a jar needed to have a sex value... I solved it by using a two-level 
memory structure, like this:

struct generic_thingy
{
  STD_INFO                 std_info;
  union    {
    REGION_SPEC          Region;
    PLAYER_SPEC          Player;
    STATIC_ROOM_SPEC     S_Room;
    STATIC_CREATURE_SPEC S_Creature;
    STATIC_OBJECT_SPEC   S_Object;
    PORTAL_OBJECT_SPEC   P_Object;
    LIQUID_OBJECT_SPEC   L_Object;
    FIREARM_SPEC         Firearm;
    AMMO_SPEC            Ammo;
  }spec_info;
};

std_info contains data that everything needs to have, and spec_info is 
type specific.  The data in spec_info is rarely accessed, and checks are 
always made as to the type of the object (stored in std_info) before an 
attempt to access it is made. 



> >	Some of the cute things I've done with it are to make some really 
> >interactive portals, and liquids that spill out of containers.
> 
> How do you handle your liquids?  I have liquids which just do ajacent
> space counts ala "There are X units of liquid here, and Y units over
> there, to even things out X-Y/2 need to move..." etc.  This often
> resulted in one unit ripples, but was prerty tame for handling
> stream-type flows.

I treat liquids as independant objects.  I've got an update pulse 
(modeled after dikumud pulses) that will have the liquid check to see if 
it is in a watertight container.  If it isn't, some of it "leaks" out.  
The liquid object has an "amount" variable, and this is decreased when 
some leaves the container.  I've also got one function for moving things 
around, and it checks to see if the liquid has all been spilled (move 
whole object to outer container) and checks to see if there is a liquid 
of similar type in the outer container (sum the amount variables, and 
recycle one object.)

One thing I had to watch out for was having a liquid leak out of a room 
that wasn't carried by anything else.  That path leads to memory-holes. :)

> J C Lawrence                               Internet: claw at null.net

Michael Hohensee