Report was for
You finish taking off your boots.
You float gently to the altar. [destination was a red herring]
[take some action to run through moveloop() for next turn]
Your movements are slowed slightly because of your load.
Having float_down() do the next encumbrance check instead of
waiting for moveloop() to do so was straightforward. However,
while testing I noticed the reverse situation (not due to the fix
for the above) when putting on levitation boots
Your movements are now unencumbered.
You finish your dressing maneuver.
You start to float in the air!
Having float_up() do the encumbrance check isn't adequate to fix
this, because it takes multiple turns to put on boots but the
properties they confer are enabled immediately, so moveloop() runs
while hero is already levitating even though the game hasn't told
the player about it yet. Fix is a hack to defer the effect of
levitation on encumbrance until the boots are fully worn, which
might lead to strangeness somewhere. It's also boot-specific so
will need to be updated if some other multi-turn armor that confers
levitation ever gets added.
Noticed on nethack.alt.org; the Bell of Opening could trigger a
segfault if applied near a trap door or bear trap (and a few others)
that had no monster at the trap location. Reproducible if done
while mounted; {open,close}{fall,hold}ingtrap() would try to access
monst->mx and monst->my of a Null monst pointer if given one when
u.usteed was non-Null.
setmangry() and wakeup() were being used for multiple purposes. Add an
extra parameter to track which. This fixes several minor bugs (e.g.
whether monsters with no eyes were angered by (useless) gaze attacks
against them previously depended on the state of a UI option, and
the Minetown guards would be annoyed if you used a cursed scroll of
tame monster on a shopkeeper). It's also a prerequisite for the
Elbereth changes I'm working on.
Zapping wand of undead turning at self while inside a shop and
carrying a corpse caused the shopkeeper to claim a use-up fee for
the corpse regardless of whether it was owned by the shop.
Not mentioned in the report: casting stone-to-flesh as self while
carrying a figurine or statue behaved similarly.
I've hunted for other instances where monster hit points were set
to zero or less without calling the routine that kills off the
monster (see recent mon_unslime() vs zhitm()) and didn't find any
for mhp subtraction. I haven't checked for direct assignment yet.
For a while I thought I'd found several cases where a monster was
intended to be killed but got left with positive hit points, but
it turned out that lifesaved_monster(), of all places, was setting
them to zero. I've moved that to its callers so that it isn't so
well hidden. And changed several ''if ((mon->mhp -= dmg) <= 0)''
into separate subtraction and 'if' just so the mhp manipulation is
a bit more visible.
I think the only actual change here is the message for monster
being killed by lava, where glass golems now melt instead of burn.
Do it properly, using the arguments to xkilled() instead of reversing
the conduct counter after the fact.
The xkilled() flag value of '1' has been reversed. It used to mean
'display message' but now means 'suppress message' since both of the
other flag bits are for suppression. All callers have been updated
to specify either XKILL_GIVEMSG or XKILL_NOMSG so the underlying
number remains transparent.
Digging a grave witha a pick-axe converted the grave to floor but
did not dig a pit and unearth the grave's contents. [Caused by a
change to maketrap() intended to prevent wizard-mode wishing for
traps on top of furniture.] Digging a second time succeeded in
creating a pit since the location was no longer furniture.
... when exploding chest trap destroys uchain without using
unpunish() to un-wear it first. The '!carried(uball)' clause
should be applied to the uball->ox,oy test only, not to both
uchain->ox,oy and uball->ox,oy.
Reported directly to devteam (for 3.4.3 but still present in 3.6.0):
an unseen landmine explosion which caused scatter() to break a
boulder or statue would give feedback as if the hero could see the
boulder or statue being destroyed.
Also, a couple of landmine explosion messages didn't take deafness
into account.
There have been two or three reports on getting feedback about
amulets rusting. Object formatting doesn't display erosion for
them, so being told about damage then not seeing that damage
feels like a bug. Even if damage was displayed, it has no effect
on them so would still feel somewhat strange. It does display
erosion for wands and rings, which is strange too.
This limits erosion damage--and its feedback--to items which are
actually impacted by erosion: armor, weapons and weapon-tools;
also heavy iron balls and iron chains since they've traditionally
shown rust even though it has little effect.
A side-effect of this change is that flammable items (other than
armor and weapons) which don't burn up immediately will no longer
become burnt, then very burnt, thorougly burnt, and finally be
destroyed. Since the player couldn't see or possibly repair the
erosion state, it seemed incomplete. It could be reinstated by
making other flammable items be subject to erosion and displayed
as such by xname() & co.
Wishing now avoids applying erosion and erosion-proofing to items
that aren't affected by it, regardless of material. It also now
allows wishing for "rusty rustproof <iron-object>" which used to
suppress "rusty" in that combination and triggered a couple of
old bug reports.
Heavy iron balls and iron chains can have rust repaired and can
be made rustproof by wielding, then reading enchant weapon while
confused, as if they were weapons.
Based on a bug report from beta testers in 2010. mintrap()
already had partial checks for this (now fire vortex also burns
a web, as per suggestion in the bug report) but mfndpos()
lacked checks so mintrap() code was almost never exercised.
The report that a tame Archon got two "<pet>'s long sword is not
affected" messages thought there was some duplication error when a
flaming sphere exploded, which was incorrect. Since an Archon has
two weapon attacks, getting that message twice just meant that both
attacks hit. However, the player has only 1/6 chance to suffering
passive fire damage to weapon, where monster-on-monster or monster-
on-polyd-hero was inflicting that for every successful hit, so
there was a bug here after all. Give monsters the same 1/6 chance.
Also, add even more verbosity to that message--now that it won't be
delivered so often--to mention what didn't affect the item.
While investigating this, I noticed that hitting a steam vortex
with a flammable weapon was doing fire damage to that weapon. Fire
damage in the steam vortex definition makes some sense in that it
allows fire resistance to give protection, but dishing out actual
fire damage makes no sense and is now prevented for passive counter-
effects.
Adding deafness to the status line spurred me on to something I've
wanted to do for a long time. This adds 'Stone' and 'Strngl' as
new status conditions, and moves the five fatal ones: "Stone Slime
Strngl FoodPois TermIll" to the front of the status list since
information about them is more important than any of the others.
"Ill" has been renamed "TermIll"; "Df" has been renamed "Deaf";
"Lev", "Fly", and "Ride" are three additional new conditions, with
Lev and Fly being mutually exclusive. After the fatal ones, the
order of the rest is now
<hunger> <encumbrance> Blind Deaf Stun Conf Hallu Lev Fly Ride
To handle the longer potential status line, the basic bot2() is now
smarter. If the line is wider than the map, 'T:moves' is moved from
the middle to the end. If the line without time is still wider than
the map, then experience (HD if polyd, Xp:M/nnnnnn is showexp is on,
or Exp:M) is moved in front of time at the end. If the line without
experience and time is still wider than the map, dungeon level plus
gold is moved from the beginning to be in front of experience. The
fields are just reordered, not truncated, so if the interface code
can display lines wider than the map they'll retain the extra info.
The gist is than health and associated fields (Hp, Pw, Ac) get first
priority, status conditions get second priority, then the rest. In
the usual case where there aren't many conditions, status display is
the same as it has been in the past.
STATUS_VIA_WINDOWPORT has been updated too, and it builds for tty
and X11. But the bot2() revision to reorder sections has not been
implemented for that.
win/win32/mswproc.c has been updated but not tested.
STATUS_VIA_WINDOWPORT without STATUS_HILITES had several compile
problems; now fixed for core and tty. STATUS_VIA_WINDOWPORT with
STATUS_HILITES has not been tested.
Stepping onto lava destroyed water walking boots if they weren't
fireproof but didn't do that for other types of boots unless hero
was not fire resistant and got killed by the lava. Burn up all
non-fireproof leather boots when stepping onto lava.
This is a fix for H4101, bz192.
add non-audio (felt) outcome to yelp()
This also add #wizintrinsic command because testing this was a pain
without a simple, straightforward way to go deaf that didn't time-out
before the situation being tested recurred.
Dip the scroll labeled LEP GEX VEN ZEA into the fountain?
Your scroll called light fades.
The first prompt deliberately avoided 'called', 'named', and other
attributes to keep it short, but the discrepancy here is blatant, so
increase the verbosity in order to have the reminder that's included
in the prompt be the same as object name in the followup message.
Bonus fix, noticed while testing it: water_damage() was reporting
the "{blank,unlabeled} scroll fades" even though blank scrolls are
already as faded as they can get. Likewise for blank spellbook.
Noticed while testing the look-at vs vibrating square patch: I was
able to cover stairs with a trap via wizard mode wish. That wish can
achieve a lot of irregular things, but prevent this particular one.
Fix some more of the complaints from clang's static analyzer. The one
in options.c (manipulating warnings symbols) appears to be an actual bug.
All the rest are either because the analysis isn't quite sophicated
enough or outright bogus.
Two of them appear to be because a static routine is attempting to guard
against callers in the same file failing to pass in required output
pointers. Stripping away the check for missing pointer should convince
the analyzer that those output parameters always receive a value. We'll
see once the analysis is eventually re-run....
I think this should fix one of the valgrind complaints. Traps which
didn't use the trap->vl union field never initialized it, leaving a
bit of random garbage in the malloc'd trap structure. (And traps
which overwrote existing ones that did use it didn't reinitialize it
so kept stale data around.) Since those fields weren't in use by
the traps that don't care about them, this didn't provoke any actual
trouble.
Also reformatting....
Last few && or || followed by end-of-line comments, plus tab replacement
and 'return' parentheses. Not as many of those; some of these files had
already had that done.
Also, tweaked non-cursed scroll of charging read while confused to be a
tiny bit more effective.
To do: find and fix block comments that immediately follow a line with
an end-of-line comment and got misindented to line up with that comment.
Same sort of stuff as before: some continuation lines with operator
followed by end of line comment (only a few files with those still to
go...), plus tab replaced by spaces in comments, excess parenthesis
removal for return statements, and force function name to be in column
one in function definitions:
type name(args) /* comment */
argtype args;
{
to
/* comment */
type
name(args)
argtype args;
{
I've been spotting those by eye rather than rexexp, so probably missed
some.
End of first pass, but '[&|?:][ \t]*$' doesn't catch trailing operater
followed by end-of-line comment so more needs to be done. As with the
past couple of batches, I've removed redundant parentheses from 'return'
statements but only for files that had continuation fix-ups.
I've also removed tabs from comments in some of the files, but didn't
start until part way through this subset of the sources.
Flesh out wet towels a bit:
1) wielding a wet towel--or a dry one which becomes wet--won't give a
"you begin bashing with your wet towel" message when attacking;
2) if a formerly wet towel dries out completely while wielded, *do* give
"you begin bashing with your towel" on the next attack;
3) successfully hitting with a wet towel no longer always loses wetness;
4) water damage to dry towel always confers at least 1 point of wetness;
5) taking fire damage (via burnarmor() which is used for most types of
fire damage) has a chance to partially or fully dry a wet towel
(regardless of whether it's wielded at the time; applies to monsters
as well as hero; each towel being carried is checked until one is
affected, then any others escape drying.
Not done:
-) attacking with a wielded wet towel perhaps ought to be treated as a
weapon attack using whip skill rather than an augmented arbitrary-
junk-by-weight attack;
-) throwing a wet towel should probably ignore wetness--it's just a wet
piece of cloth when not finishing with a whip snap; right now, it
loses a point of wetness when thrown and usually--#3 above--another
point if it hits...;
-) hitting burning creatures is no different than hitting anything else;
-) likewise for hitting wet creatures.
Dipping a towel into a potion, fountain, or some other water source
makes the towel wet. Hitting with a wet towel deals up to 6 points
of damage, but every hit reduces wetness, as does throwing or applying
the towel. You can also wish for a moist or wet towel.
Replace instances of strings split across lines which rely on C89/C90
implicit concatenation of string literals to splice them together
with single strings that are outdented relative to the code that uses
them. It's uglier but it won't break compile for pre-ANSI compilers.
This covers many files in src/ that only have one or two such split
strings. There are several more files which have three or more. Those
will eventually be '(2 of 2)'.
Noticed along the way: the fake mail message/subject
Report bugs to devteam@nethack.org.
wasn't using its format string of "Report bugs to %s.", so would have
just shown our email address. Doesn't anybody enable fake mail anymore?
I modified that format to enclose the address within angle brackets and
made a similar change for the 'contact' choice of the '?' command.
If a trap is created on top of another trap, maketrap reuses
the trap struct in place, instead of deleting and recreating it.
If a squeaky trap was created on top of another trap, maketrap
first set the trap type to squeaky board, and then tried to
look through all squeaky boards on the level, to determine
what note the new trap should play. Unfortunately, the union
with the trap note most likely contained a rolling boulder
coordinate or something else outside the 12 note range, so
then the tavail-array lookup would cause a segfault.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
