[MUD-Dev] Unique items

Jon A. Lambert jlsysinc at ix.netcom.com
Tue Jan 13 00:34:52 CET 1998


On 12 Jan 98 at 20:11, Vadim Tkachenko wrote:
> Jon A. Lambert wrote:
> > 
> > I have properties in the objects which indicate their coverage area
> > or wear location (sound familar :> ) except my wear locations are
> > dependent upon the anatomy that the object was design for.  Multiple
> > areas of coverage can occur.  Thus, the pants cover both thighs and
> > lower legs, lower abdomen and rear.  Each object has a transparency
> > property; transparent, translucent or opaque.  I allow 4 layers and
> 
> Just an abstract note - 
> 
> This rings a bell immediately: Why 4? Why not 3 or 5? Don't be confused,
> I've read your Web page named 'Specifications for Wear Location System'
> really careful, and I like the idea, actually, I love the idea, but see
> - there's a common curse to limit ourselves to specific numbers, instead
> of abstract.
>

A well-taken point.  The original specification was written as a hack for 
a ROM mud <circa summer 95>.  There was also only one race, human.  My 
current server has a class BODY_TYPE which still has a the properties 
set for a fixed limit of 4 layers and 28 positions, but also includes 
pointers to the .GIF  representation and the hot-spot map, and initializers 
to other properties like height and weight. It is also used for generating 
hit locations.  Other BODY_TYPE's may be created with any number of wear 
positions and layers.  (I still have only one race BTW, Greeks).  Currently 
I'm using other BODY_TYPE's for creatures, which still run around naked. 
The seemingly random limitations are present for game balance reasons.  In 
reality, while one could wear 30 pairs of silk stockings, I don't wish to 
code this at that level of granularity where the bulk of the item 
influenced the number of layers.  And imagine, what if they were all 
magical stockings that had cumulative bonuses.

The way equipment objects were stored with the 6 flag limit is complete 
nonsense, although it makes sense in the flatfile ROM/Diku/Merc approach.

> OK, let me put it this way:
> 
> - Let's pretend there are N layers instead of 4.
> - What logical/physical layers are there, other than 4 mentioned?
> - What would be the object placement rule for an object?
> 
> Also, there's a chance for a number 28 to change, too - let's pretend a
> gauntlet has an extra hook to hang the car keys on it, which just adds
> 29th location, and so on.
>

The gauntlet would be created as an outside (inverted) container.

> > they are described from the outermost to inner most, being blocked
> > or modified by the transparency property or described differently
> > when partially blocked by lesser coverage of outer layered objects.
> 
> Also, just in unlikely case you've forgotten, if something heavy hits
> you, you may get
> 
> - a dent on your chain mail
> - crushed alchogol bottle stashed in its inner pocket (btw, one more
> wear location)

Chain mail would be an normal container and so would the bottle.

> - some bruise on your chest

Oh, the bruise goes at level 0, unlimited objects attached there. 
Level 0 is system-accessible only.  

> - add by taste
> 

Sadly, I'm strapped for time to get all my doc WEB-enabled and current. 
I've noted this on the page as Diku/Merc related and didn't even bother 
with formatting it <PRE></PRE>.  I did warn you that my web page was lame! 
That's a feeble excuse though. ;) 

--
Jon A. Lambert
"Everything that deceives may be said to enchant" - Plato



More information about the mud-dev-archive mailing list