If a character dies with 'multi' at a non-zero value, the reason for
helplessness is appended to the cause of death. But that was taking
place in writeentry(), which is used for every score entry while
rewriting 'record' when a new high score is added. So whenever a new
score with helplessness was added, all existing entries got corrupted
by having the newest game's reason for helplessness tacked on.
Append the helplessness reason while formatting the cause of death
instead of when writing out score and logfile entries. xlogfile is
handled a little differently in case the cause of death plus reason
for helplessness is too long so truncated for record and logfile.
Full reason is still put into xlogfile.
Changes to be committed:
modified: doc/fixes36.1
modified: src/ball.c
I looked up the original bug report that led to bug page C343-20
"When dying immediately on entering a level, the map may show you dying on the previous level."
It was received public report U891:
> When one is being punished and goes down a staircase and dies because the
> ball and chain fell on their head, one gets the message about their death
> while the old level is still being displayed. I wasn't sure whether this
> was a bug or not because on one hand it wouldn't make much sense to
> generate a new level if the character is going to die anyway. However,
> that being said it does make a difference if the character is about to go
> down into a level where one cannot leave bones files, ie medusa or the
> first level of the mines (if i remember correctly). So, if your character
> dies from this does the bones file get left on the level you were on
> (which is still displayed at the time of death) or the level you died as
> soon as you got to (but was never displayed)? Thanks!
Pat had remarked in response: "So this is just a display issue; game play works as intended
(for the program; I imagine you weren't planning to get killed."
A debug trace in wizard mode 3.6.1 beta shows that the relevant code path is this:
NetHack.exe!done(int how) Line 908
NetHack.exe!losehp(int n, const char * knam, char k_format) Line 2678
NetHack.exe!drag_down(...) Line 823
NetHack.exe!goto_level(d_level * newlevel, char at_stairs, char falling, char portal) Line 1316
NetHack.exe!next_level(char at_stairs) Line 1157
NetHack.exe!dodown(...) Line 954
NetHack.exe!rhack(char * cmd) Line 3416
NetHack.exe!moveloop(char resuming) Line 464
NetHack.exe!main(int argc, char * * argv) Line 104
This patch clears the display for the situation in drag_down(),
so the old level is not shown.
If player specified all four facets of role: role, race, gender, and
alignment, via command line or option settings, the tty interface still
asked the player to confirm whether the character's role/&c was ok?
Skip that confirmation when all four things have already been chosen.
The menu for picking an item to name when using the "on discoveries list"
choice for #name or C when that list spanned multiple pages was exiting
for <space> instead of advancing to next page. Space was being assigned
as the selection letter for class header lines, which made no sense.
Make a fix suggested during beta testing: you can read scrolls while
blind if you know the label, and you can write a scroll with a magic
marker while blind, but the result was flagged as description unknown
so you couldn't read the newly written scroll until regaining sight
or obtaining object identification. So change writing a previously
discovered scroll while blind to set dknown since a successful write
always yields the type of scroll requested. Getting lucky while
attempting to write an undiscovered scroll--which has to be done by
scroll's type name (for instance "food detection") rather than by its
label ("YUM YUM")--still leaves the description flagged as unknown
since hero hasn't seen the what sort of label the new scroll has.
Along the way I got side-tracked by the possibilty of writing a scroll
of mail. It's allowed and yielded the same result as finding such a
scroll in bones, or wishing for one: when read, it was junk mail from
Larn. Make one written via marker give different feedback since it
comes from creation of a stamped scroll without any stamps available.
Also, suppress an "argument not used" warning for readmail().
A couple of reports asked what weird unit of measure was used for the
'realtime' value in xlogfile. It was just seconds, but was accumulating
incorrectly whenever game-state got saved for the checkpoint option.
Now it really is seconds, or rather whatever unit you get for the delta
of two time_t values; usually seconds but not guaranteed to be that.
60: getpos() doesn't report the offending keystroke accurately when
rejecting M-something as a movement keystroke while moving the cursor;
61: typing M-N as a command keystroke produces
|Unknown command 'M-
| '.
where the '.' on the second line clobbers the top line of the map.
I can't reproduce the first one without extending the altmeta hack
[a run-time option to treat two char sequence ESC c as M-c] to getpos()
and nh_poskey(), which I've done for testing but am not including here.
I can't reproduce the second as it's described, but M-^J produces
|Unknown command 'M-
|'.--More--
and this fixes that, with a general fix that applies to any meta char.
The diffs include some cleanup/groundwork for maybe extending altmeta.
When I updated recover.6 last week, I was under the mis-impression that
the INSURANCE compile-time option had been made unconditional. It has
not, and after undoing that, there was no substantive change, so put it
back to how it was at release.
Passage 1 of the Colour of Magic: 'bazaars' was misspelled 'bazarrs'.
There were a couple of other things that didn't match the paperback copy
I recently recovered from loan: 'radiation' should be 'radiations', and
'dark' was omitted from 'a tall dark figure'.
Unlike the later Harper editions, the early Signet ones retain British
spelling (at least for 'colour'). I failed to find the second passsage
via flipping through the pages, so wasn't able to proof-check that one.
Changes to be committed:
modified: doc/fixes36.1
modified: src/dogmove.c
A bug reporter wrote:
> comments:
> "You sense a little dog appear where Poes was!"
>
> seems strange to me, perhaps it should be "appearing", or the hero shouldn't
> notice at all if it's out of sight.
>
> Not sure it was out of sight, anyway, because I saw the d from the shop
> doorway.
>
Change the wording to:
"You sense that a little dog has appeared where Poes was!"
Author: PatR <rankin@nethack.org>
Date: Sun Dec 13 06:06:58 2015 -0800
fix #H4066 - bug eating ring of protection
Intrinsic protection of 0 (usually from having a gremlin steal divine
protection, but also possible by eating a +0 ring of protection) does
not contribute to "magic cancellation", the defense attribute that
makes some special attacks fail. That's intended. Negative intrinsic
protection (not possible from having divine protection, but turns out
to be possible from eating negatively enchanted/charged rings of
protection), did contribute. That wasn't intended, so stop it.
(Positive intrinsic protection gives a magic cancellation of 1 if worn
armor doesn't provide any MC.)
High priests used a different message to refuse accepting a user-supplied
name than regular temple priests because they're flagged as unique. The
effect was cosmetic; it didn't reopen the hole that let you recognize
which high priest was which via the 'C' command on the Astral Plane.
[I never received the mail for #H4062 but saw it in bugzilla.]
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.
Entered in bugzilla prior to release: "slice of birthday cake" became
"slouse of birthday cake" when made plural. "slice of pizza" used to
work, but adding an entry for "louse" <-> "lice" to one of the special
handling lists for singular/plural broke "slice" since only a trailing
substring match is performed for entries in that particular list.
In 3.4.3, reading an uncursed scroll of enchant armor while wearing
a piece of cursed armor performed an uncurse as well as raising
enchantment. A fairly big patch to redo how pending shop bills were
affected by altering the items on the bill accidentally took away
the uncurse part when modifying the scroll code to use the bless()/
uncurse()/curse() functions instead of manipulating the armor's
blessed and cursed flags directly.
Requested by a beta tester back in June: naming Sting or Orcrist
violates illiterate conduct. I left it at that; any object naming
could be construed as being literate, but I don't think breaking
conduct for doing such would be a good idea.
Vampires who were currently shape-shifted into a fog cloud, bat, or wolf
became an unkillable fog could, bat, or wolf if the player genocided
vampires. When such a creature was killed, the attempt to transform it
back into a vampire failed, but the monster continued to be resurrected
anyway.
Options parsing didn't support "default" (shown by the 'O' command)
or "Default symbols" (menu entry for choosing a symbol set via the
'O' command. Symbol handling is somewhat confusing, but this seems to
do the trick. They can't be truncated, but they're case-insensitive,
and "Default" and "symbols" can be separated by dash or underscore as
well as space, or run-together with no separator.
distant_name() temporarily blinded the hero before calling xname() or
doname() in order to prevent the object being formatted from having
its dknown flag set. The Eyes of the Overworld override blindness, so
that bit got set for heros wearing them regardless of intention. This
switches to a file-scope global instead of blindness as the way that
distant_name() tells xname() not to set dknown.
This bug has been present ever since the Eyes were added (3.3.0?).
Move the 'if (wizard) { /* give feedback for named fruit */ }' code
in ^X/enlightenment into an #if DEBUG block, and expand the if (wizard)
predicate with '&& explicitdebug("fruit")' to require that 'fruit' be in
DEBUGFILES. So, build with DEBUG enabled and run via
|% DEBUGFILES='fruit' nethack
to get it back....
This isn't actually a bug fix and it isn't necessary for 3.6.1, but I
got tired of seeing ^X and end-of-game disclosure of attributes end with
three lines about fruit when I'm not doing anything with named fruit.
Update the man pages and generated text copies for nethack and recover.
I haven't looked at the other four (dlb, makedefs, dgn_comp, lev_comp).
recover's page referred to INSURANCE as being conditional, which is no
longer the case. nethack's page was missing a bunch of files to be
found in the playground and also a couple of environment variables.
I haven't read through the text of the page to try to see whether other
updates are warranted.
The generated text is wider than the previous copy (one or two space
right margin instead of 5 or so). I just used 'make nethack.txt' and
'make recover.txt' so don't know why that changed. (The older, wider
margin looks better, so if anyone knows how to fix this, please do.
And there's got to be a better way to force a blank line inside a
table than my <space><tab> hack.)
Another issue from old beta-tester mail: #annotate and #overview were
missing from the list of extended commands. M-A and M-O were listed
but marked "(if supported)" even though they've become unconditional.
Same for M-R, although in its case #ride wasn't missing.
Some old beta-tester mail suggested mentioning the implicit_uncursed
option in the "Curses and Blessings" section; this patch does that.
It also mentions that option in the "Configuring Menu Colors" section
since anyone trying to specify a color for " uncursed " will want
objects to be explicitly described as "uncursed".
The changes to the LaTeX version haven't been tested. The generated
plain text version has a lot of spurious changes due to the padding
method it uses to right-justify short lines.
Another bit prompted by vibrating square testing:
|You see a strange vibration beneath the little dog's rear claws.
Fix up some body parts: dog, cat, and yeti-class (includes sasquatch,
monkey and ape, owlbear) already have "paws" instead of "fore claws".
Take away all 'Y' except owlbear from that list and add rodents to it.
Give them "rear paws" instead of "rear claws" for their feet; for legs,
use "foreleg" instead of "forelimb" and "read leg" instead of "rear limb".
For yeti/sasquatch/monkey/ape/carnivorous-ape, switch from paws to hands
since they have opposable thumbs, and switch to arm, leg, foot instead
of forelimb, rear limb, and rear claw. I've left "fore claw" for finger.
Fix the reported bug that attempting to cast an expired spell, which
causes confusion and/or stun, was replacing the duration of any existing
confusion or stun with the new amount rather than increasing it by that
amount.
Attempting to cast any spell while stunned will now fail immediately,
and casting an expired spell while confused will increase confusion
duration (and/or set stun duration) rather than override it.
When doing some more reformatting I came across something I've been
meaning to tweak for a long time, and since the change is only a couple
of lines I'm putting it in now instead of waiting. Make potions of
gain energy more useful for actually regaining energy so they might not
be relegated to alchemy all the time. The adjustment is probably too
low to really achieve that, but I didn't want to risk going too high.
Increase to max energy is only a little higher (average 10.5 vs 9 for
blessed, 7 vs 4 for uncursed) but to current energy is noticeably higher
(31.5 vs 9 for blessed, 21 vs 4 for uncursed; capped by max energy so
bigger increase only matters if current is below max when quaffing).
Another code change while reformatting: '#turn' by non-priest/non-knight
casts the "turn undead" spell if the hero has learned it, but it was
forcing the spell code to aim at self rather than ask for a direction.
Evidently nobody has ever used that while knowing the spell and able to
cast it....
Fix the problem reported by ais where it was possible for one monster
to knock the hero onto a level teleporter (or trapdoor or hole),
destination was selected and allowed-to-level-teleport checks were made,
then for another monster to knock or teleport the not-yet-relocated-hero
onto the Amulet and have auto-pickup move it into inventory. At the end
of that turn's monster movement, hero would level teleport successfully
despite carrying the Amulet.
This short-circuits monster movement if the hero is scheduled to be
moved to a different level. The monsters who haven't moved yet don't
lose their pending movement points; they'll catch up if/when the hero
returns to the level.
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.
