When unlocking a trapped container, any blessed key was behaving
as if it was the rogue's Master Key of Thievery: detecting the
trap, asking whether to untrap, and always succeeding if player
responds with yes. The intended behavior is that the Master Key
will behave that way for a rogue if not cursed and for non-rogue
if blessed; it wasn't supposed to affect ordinary keys at all.
Fixes#503
Change Trollsbane versus troll corpse revival: instead of revival
failing if Trollsbane is wielded at time of revival attempt, mark
the corpse no-revive if killed by Trollsbane (whether by the hero
or a monster).
If a no-revive corpse is within view when time to revive occurs,
give "the troll corpse twitches feebly" even when the hero isn't
responsible. That used to only apply if the hero zapped the
corpse with undead turning, which would have become inoperative
because now being zapped by undead turning clears the no-revive
flag and revives as normal. In other words, undead turning magic
overrides killed-by-Trollsbane or non-ice troll having been in an
ice box.
Player's pet killed a troll with Trollsbane and the corpse later
revived. He assumed that killing a troll with Trollsbane is what
prevents troll corpse revival but that is inhibited by the hero
be wielding Trollsbane at the time revival is attempted.
Having killed-by-Trollsbane be the reason for blocking revival
would be much better but looks like a lot of work for something
which was supposed to be a one-line enhancement to an under-used
artifact. This extends revival inhibition to having anyone on
the level be wielding Trollsbane rather than just the hero.
Not a proper fix but I think it's better than nothing.
Closes#475
This replaces the arcane system previously used by getobj where the
caller would pass in a "string" whose characters were object class
numbers, with the first up to four characters being special constants
that effectively acted as flags and had to be in a certain order.
Because there are many places where getobj must behave more granularly
than just object class filtering, this was supplemented by over a
hundred lines enumerating all these special cases and "ugly checks", as
well as other ugly code spread around in getobj callers that formatted
the "string".
Now, getobj callers pass in a callback which will return one of five
possible values for any given object in the player's inventory. The
logic of determining the eligibility of a given object is handled in the
caller, which greatly simplifies the code and makes it clearer to read.
Particularly since there's no real need to cram everything into one if
statement.
This is related to pull request #77 by FIQ; it's largely a
reimplementation of its callbacks system, without doing a bigger than
necessary refactor of getobj or adding the ability to select a
floor/trap/dungeon feature with getobj. Differences in implementation
are mostly minor:
- using enum constants for returns instead of magic numbers
- 5 possible return values for callbacks instead of 3, due to trying to
make it behave exactly as it did previously. PR #77 would sometimes
outright exclude objects because it lacked semantics for invalid
objects that should be selectable anyway, or give slightly different
messages.
- passing a bitmask of flags to getobj rather than booleans (easier to
add more flags later - such as FIQ's "allow floor features" flag, if
that becomes desirable)
- renaming some of getobj's variables to clearer versions
- naming all callbacks consistently with "_ok"
- generally more comments explaining things
The callbacks use the same logic from getobj_obj_exclude,
getobj_obj_exclude_too and getobj_obj_acceptable_unlisted (and in a few
cases, from special cases still within getobj). In a number of them, I
added comments suggesting possible further refinements to what is and
isn't eligible (e.g. should a bullwhip really be presented as a
candidate for readying a thrown weapon?)
This also removed ALLOW_COUNT and ALLOW_NONE, relics of the old system,
and moved ALLOW_ALL's definition into detect.c which is the only place
it's used now (unrelated to getobj). The ALLOW_ALL functionality still
exists as the GETOBJ_PROMPT flag, because its main use is to force
getobj to prompt for input even if nothing is valid.
I did not refactor ggetobj() as part of this change.
further adjustments to the window port interface to pass a pointer
to a glyph_info struct which describes not just the glyph number
itself, but also the ttychar, the color, the glyphflags, and the
symset index.
This affects two existing window port calls that get passed glyphs
and does the parameter consistently for both of them using the
glyph_info struct pointer:
print_glyph()
add_menu().
The recently added glyphmod parameter is now unnecessary and has been
removed.
Move the core's global restoring flag (not the same as main()'s
local resuming flag) to a more logical place. Add a saving flag
in the process, but it isn't being set or cleared anywhere yet.
(Once in use it will probably fix the exception during save that
was just reported, but before that it would be useful to figure
out what specifically caused the event.)
The program_state struct really ought to be standalone rather
than part of struct g but I haven't made that change.
Removing an unused variable for wishing and some reformatting
that whent along with it got mixed in. Removes some trailing
whitespace in sfstruct.c too.
Only lightly tested...
... on the floor, in monster inventory, and in hero's inventory.
Items in your inventory being ignited produce a message even if you're
blind - you can see the lit-state by viewing inventory anyway, so just
give player the message.
(via xNetHack)
Allow a hero in silver-hating form to ring the Bell of Opening when
on the vibrating square so be able to perform the invocation ritual.
But only at that location and only if the stairs aren't there yet.
This is about on par with being able to read the Book of the Dead
while blind although that isn't limited to a specific location.
The report about problems after stone-to-flesh on a petrified
long worm included stethoscope feedback of 0(-1) hit points, after
life-draining. I was unable to reproduce a maximum hp of -1 and hope
that it was a side-effect of the [already fixed] stale mon->wormno
value used when resurrecting the long worm. Anyway, this changes
life-draining to never take mon->hpmax below mon->m_lev + 1 (the +1
is needed to cope with m_lev==0 monsters). The same limit is also
applied to monster life-saving but more to avoid replicating the
arbitrary minimum of 10 (four instances) then because it might be
less than m_lev+1 somehow.
Sanity checking now tests whether a monster's max HP is less than
its level + 1 so if there are ways other than life-drain attacks for
it to drop that low, the fuzzer will choke. The new check also tests
whether a monster's current HP is greater than max HP.
Polymophred hero killing a golem or vortex by vampire bite reported
"<Mon> dies." Give an alternate message since those aren't alive.
This reverses all of c67f1dd710
except for the fixes37.0 entry and does a better job in a cleaner
fashion. If Sting is going to start glowing and "you materialize
on a different level" is pending, give the materialize message
before the glowing message. Otherwise handle both stop-glowing
and/or you-materialize in the normal fashion.
Provide a way to communicate additional behaviors and/or appearances
desired from NetHack window port menus.
This is foundation work for changes to follow at a future date.
Setting or clearing u.ustuck now requires that context.botl be set,
so make a new routine to take care of both instead of manipulating
that pointer directly.
groundwork only - window port interface change
This changes the last parameter for add_menu() from a boolean
to an unsigned int, to allow additional itemflags in future
beyond just the "preselected" that the original boolean offered.
There shouldn't be any functionality changes with this groundwork-only
change, and if there are it is unintentional and should be reported.
Report stated:
"Poes deliberately slither onto a polymorph trap!" ... it's only one cat, er,
black naga. Why does the parser treat the name as plural? There are lots of
singular words and names that end in -s or -es!
H9249 1780
Make some progress on a couple of next minor release checklist
items, hopefully without introducing too many new bugs. This
is just the initial commit, and work continues.
Checklist items:
Savefiles compatible between Windows versions, whether 64-bit
or 32-bit in little-endian field format.
Selection of file formats:
historical (structlevel saves),
lendian (little-endian, fieldlevel saves),
and just for proof-of-concept, ascii fieldlevel saves
(the ascii is huge! 10x bigger than little-endian).
For the fieldlevel save, all complex data structures recursively
get broken down until until it is one of the simple types that
can't be broken down any further, and that gets when it gets
written to the output file.
New files needed for this build:
hand-coded:
include/sfprocs.h
src/sfbase.c - really a dispatcher to one of the
output/input format routines.
src/sflendian.c - little-endian output writer/reader.
src/sfascii.c - ascii text output writer/reader.
auto-coded (generated):
include/sfproto.h
src/sfdata.c
This is just one approach. I'm sure there are countless others
and they have different pros and cons.
For producing the auto-coded files a utility called
universal-ctags, that is actively maintained and evolving,
was used to do all the heavy-lifting of parsing the
NetHack C sources to tabulate the data fields, and store
them in an intermediate file called util/nethack.tags
(not required for building NetHack if you already have a
generated include/sfproto.h and src/sfdata.c)
util/readtags (also not required for building NetHack
itself) will decipher the nethack.tags file and produce
the functions that can deal with the NetHack struct data
fields.
You can obtain the source for universal-ctags by cloning it
from here:
https://github.com/universal-ctags/ctags.git
The combination universal-ctags + util/readtags has been
tried and tested under both Windows and Linux, so it is
not tied to a particular platform.
Note: util/readtags will work only with universal-ctags
output, so other ctags are unlikely to work as-is.
Universal-ctags can be build from source very easily
under Linux, or under Windows using visual studio.
I went through the places that set context.botl/botlx in src/a*.c to
see whether I could find any unnecessary status updates. I didn't
find anything interesting, mostly some minor sequencing issues plus
a couple of redundant sets (call foo() which includes setting botl,
then explicitly set botl after it returns). If you issue pline first
and then set context.botl, bottom lines won't be updated until the
next message or next pass through moveloop. If you order those the
other way around, status will be updated as the message describing
the reason for the update is being delivered.
Dropping an existing fragile item while levitating will usually
break it. Getting a new wished-for fragile item and dropping it
because of fumbling or overfull inventory never would.
Some callers of hold_another_object() held on to its return value,
others discarded that. That return value was unsafe if the item
was dropped and fell down a hole (or broke [after this change]).
Return Null if we can't be sure of the value, and make sure all
callers are prepared to deal with Null.
Replace recent "(light blue aura)" with
"(flickering light blue)" if there are 1..4 orcs,
"(glimmering light blue)" if 5..12, or
"(gleaming light blue)" if there are 13 or more, and move its place
in the formatted name.
_3.6.1_: Sting (weapon in hand) (glowing light blue)
_recent: Sting (weapon in hand) (light blue aura)
_now___: Sting (weapon in hand, flickering light blue)
The thresholds for intensity may need to be tweaked. The start
message has been changed from "glows" to "flickers/glimmers/gleams"
and is given when the intensity changes (up or down) as well as when
first glowing. Stop message will usually be "stops flickering" but
some form of mass kill (genocide for sure, maybe explosion, probably
not wand zap) might result in stopping directly from higher intensity.
It still "quivers" if hero is blind when there are orcs on the level,
but no name augmentation shows in inventory for that situation;
describing it as "(weapon in hand, quivering)" would be too silly.
Also, the quiver or glow intermediate message if blindness is toggled
while Sting is active only worked for make_blinded(), not for putting
on and taking off a blindfold. Now fixed. I think becoming blind due
to polymorphing into an eyeless form is still not handled, but there
are no eyeless creatures capable of wielding weapons so that can wait.
Polymorphing from eyeless to sighted is handled but moot for Sting.
Latent bug: if a non-role-specific artifact which could be invoked
for charging existed, it would never work as if blessed because the
test for no-role was wrong. Caused when 3.3.0 changed the Role_if()
predicate and artilist[] array to use monster index numbers (PM_foo)
instead of role letters; the non-role value changed from '\0' to
NON_PM (-1) but the test for non-role didn't.
No fixes36.1 entry; there aren't any artifacts which were affected.
Make #untrap while carrying the non-cursed (for rogues) or blessed
(for non-rogues) Key work the same as #invoke has been doing (without
regard to its bless/curse state): when used on trapped door or chest,
that trap will always be found and disarming it will always succeed.
It should work when carried by monsters too: if they try to open a
trapped door while carrying the Key (must be blessed since they're
not rogues) the trap will be automatically disarmed. (Caveat: that
hasn't been adequately tested.)
TODO (maybe...): change the #invoke property to detect unseen/secret
door detection instead of #untrap. The latter isn't completely
redundant; it works when the Key is cursed. But quest artifacts
strongly resist becoming cursed so that isn't a particularly useful
distinction.
Also, trap hints when wielding the Key without gloves didn't notice
adjacent door and chest traps. Now it does. And the behavior is
slightly different: known traps covered by objects or monsters are
treated like unknown traps as far as the hot/cold hints go.
If the key is wielded and touching skin (that is, you're not
wearing gloves), it will give heat-related messages like
minesweeper, counting the undetected traps around player.
