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!
...if the map is filled with monsters, and for some reason
the drowning just won't kill you.
Infinite looping cannot currently happen, because no-one who
can drown can keep surviving the drowning once their amulet
of life saving is used up.
modified: src/shknam.c
modified: src/trap.c
modified: src/zap.c
While polymorph was clearing the name because poly_obj
actually creates a brand new obj and copies field values
over, water_damage does not so the name persisted on
the blank spellbook. In this case, that isn't really
appropriate. Clear the name.
Ensure that cancellation has no effect on these
ordinary books.
Make the second-hand bookstore an option for holding
the book tribute item too.
Instead of just "while helpless", the death reason will tell
more explicitly why the player was helpless. For example:
"while frozen by a monster's gaze"
My dog bit an acid blob and triggered a crash, caught by SYSCF panictrace
but yielding confusing information. The backtrace included a call from
'rustm()+N' that turned out to be passivemm(), which was deferencing a
null pointer since no weapon was involved.
Restore the variant phrasing used when more than one stack of potions of
acid explode while being inflicted with water damage. First message:
"a potion explodes" or "some potions explode"; second and subsequent
messages: "another potion explodes" or "more potions explode". This
trivial feature stopped working when erosion handling was overhauled and
old water_damage was split into current water_damage_chain+water_damage.
Augment the message so that vague "potion" is only used when the object's
dknown flag isn't set (ie, object hasn't been seen yet). Use "<color>
potion" or "potion of acid" otherwise, depending upon whether such potions
have been fully discovered.
