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