]> granicus.if.org Git - nethack/commit
new container flags
authornethack.allison <nethack.allison>
Wed, 15 Dec 2004 23:50:18 +0000 (23:50 +0000)
committernethack.allison <nethack.allison>
Wed, 15 Dec 2004 23:50:18 +0000 (23:50 +0000)
commit5a433fe0e0c85e0226a0addbaaae3576c398b451
tree93466048feb555593ba8cc2200bc598d3716ce27
parent10b227e242452654a337ece51ce61be338cc16dc
new container flags

[Attention: This patch increments EDITLEVEL in patchlevel.h, rendering all
 previous save and bones files obsolete.]

Here's the first cut at the two recommended flags lknown and cknown.
I've attempted to stay close to Pat's recommendations:
   "Containers ought to have two new flags:  lknown for lock status known,
    and cknown for contents known (ie, `secret').  Formatted box and chest
    descriptions should include locked/unlocked/broken when that is known
    and empty/nonempty (or something like "holds N items") when contents
    are known. The contents indicator would also apply to nonlockable
    containers."

I probably overlooked a place where a flag should be adjusted, but this
should give us a good starting point.

I wasn't sure what to do with the case of the auditory feedback for
magical locking "Click" and "Clunk". The question that came to my mind
was: Should those reveal the locked or unlocked status of a box?
I suppose if you knew the type of wand you were zapping or the spell
you were casting, you could argue that they should.

In the end, I opted for setting lknown right off the zap/cast effect
for anyone playing a Wizard role, and not setting it for anyone else,
thus advancing class differentiation a little bit too.

I haven't checked the cknown results under all flags.menu_style options
at this point, only MENU_FULL.
doc/fixes35.0
include/obj.h
include/patchlevel.h
src/dokick.c
src/invent.c
src/lock.c
src/mkobj.c
src/objnam.c
src/pickup.c
src/zap.c