CIRCLE 3.0 ABRIDGED WORLD BUILDER'S GUIDE - PRELIM (fwd)

From: Eric Pilcher (rasta@CSOS.ORST.EDU)
Date: 04/04/94


Okay, just a few questions here and there to help me understand a little
better:

> #define ITEM_DRINKCON  17		/* Item is a drink container	*/
> #define ITEM_FOUNTAIN  23		/* Item is a fountain		*/

A lot of Dikus use DRINKCONs with no TAKE flag as fountains.  Apparently the
code permits them to drink from an object not in inventory.  The one problem
I have seen with this is that the fountain often runs dry.

2 questions:  1) why is it an advantage to have a seperate flag for fountains?
	      2) could it be coded such that a value of -1 for units left
		 would result in a never empty fountain, similar to setting
		 -1 for hours on a light source.

> #define ITEM_GLOW          (1 << 0)	/* Item is glowing		*/
> #define ITEM_HUM           (1 << 1)	/* Item is humming		*/
[... etc. ...]

Older Diku docs had a #define ITEM_DARK which remained unimplemented (to
my knowledge) for Gamma 0.0.  I have a suspicion of what was intended
for that flag.

On Tiny and Teeny type Muds, a dark object is one which does not send a
long description to the room.  The idea here is that a player must READ
the room description to find out a CLUE about a HIDDEN item.  And possibly
have to read through several nested extra descriptions to find out more
about it.  

Now, illiminating an objects Long description, sends an unsightly blank
line to the room, which most veteran players know to look for.  If you
don't know what I'm talking about, go look around the city hall in
Thalos.  You'll see the blank lines which indicate a desk in one room,
a fountain in another, and a cabinet in a third.

Okay, now the proposal:

#define ITEM_DARK	(1 << ?)  /* Item is hidden in the room */

A item with a DARK flag will not simply send a <CR> for it's long desctiption
(NOT a blank line).  And an attempt to 'get all' will ignore the item.

> #define APPLY_AC               17	/* Apply to Armor Class		*/
> #define APPLY_ARMOR            17	/* Synonym for APPLY_AC		*/

Question:  why are there 2 #different define lines for this when they both
search for the same value (17)?

> /* Container flags - value[1] */
> #define CONT_CLOSEABLE      (1 << 0)	/* Container can be closed	*/
> #define CONT_PICKPROOF      (1 << 1)	/* Container is pickproof	*/
> #define CONT_CLOSED         (1 << 2)	/* Container is closed		*/
> #define CONT_LOCKED         (1 << 3)	/* Container is locked		*/
> 
Something that would be kind of nasty:

#define CONT_TRAPPED	(1 << 4)  /* Container is trapped	*/

Although to include this we'd probably want to come up with several different
types of traps.

Maybe:

#define CONT_TRAP_FIRE
#define CONT_TRAP_GAS
#define CONT_TRAP_ACID
#define CONT_TRAP_ELECTRIC
#define CONT_TRAP_FROST

(Yep, a find/remove trap thief skill or a 'trigger' spell would be in order).

-Eric



This archive was generated by hypermail 2b30 : 12/07/00 PST