A change earlier today resulted in infravision being described by
enlightenment (wizard mode only) as "from current creature form" when
it was actually due to hero's non-human race. Now it'll be "innately".
In light of the recent 'bad options' feedback issue where \r messed
up message display, try to to make newline handling be more consistent.
I'm sure there are lots of places that still handle \n manually, but
it's a start.
Duplicate of another recent report as far as drain resistance from
Excalibur/Stormbringer/Staff of Aesculapius not being shown by
enlightenment goes, but this one mentioned that it also wasn't being
shown for lycanthropy. Being inflicted by that does confers level-
drain resistance. were_change() wasn't calling set_uasmon() since
it isn't changing youmonst.data, but set_uasmon() is were intrinsics
conferred by creature form are set up. So call it when changing
were-form. Direct access to u.ulycn wasn't calling it either, so add
a new routine to assign the value to that instead doing so directly.
Mentioned in a completely unrelated report (about energy drain for
vortex attack): the message given if a tame mind flayer is killed by
attempting to eat Medusa's brains had "then is passes" where "then it
passes" was intended.
Reporter thought the fact that two different DREN cases had different
chances to inflict energy drain was an inconsistency, but it was
intentional. Attack for DREN damage has 25% chance to drain energy,
and is never used since no monster has such an attack. Engulf for
DREN damage has 75% chance to drain energy; energy vortices have this,
and the higher chance to be drained while engulfed was intentional.
So add comments explicitly spelling out the 25% and 75% chances.
During beta testing there was a complaint that the energy drain was
much too severe: once hero's current energy drops to 0, excess drain
for current attack and future drains come out of max-energy instead.
That's survivable for caster-type characters with really high energy,
but drained low energy characters to 0 max energy very quickly.
I agreed with the complaint but didn't implement a fix until too late
for 3.6.0. I've since thrown that one out and done this one instead.
Change base drain amount from 4d6 to 2d6, and weaken it more to 1d6
when energy is low or strengthen it to 3d6 when energy is high. It
almost certainly will need further tuning.
Discovered while testing the from-what enhancements to enlightenment.
Polymorphing into a vampire confers the ability to sense humans and
elves without having telepathy or being triggered by blindness. That
would be taken away if you polymorphed into something else, but was
being left in effect if polymorph just timed out and hero returned to
normal form.
Same thing occurred for sensing shriekers if you poly'd into a purple
worm and then reverted to normal (something much less likely to get
noticed and not really subject to abuse if it ever did).
Bonus fix: the code involved was using 0 to mean that Warn_of_mon
from polymorph wasn't in effect, but 0 is also giant ant. This makes
it use NON_PM for that instead.
Enlightenment/attribute disclosure while in wizard mode shows reasons
for some of the intrinsics. This adds some more of those: innately
due to polymorph for lots of things, and innately due to role for
knight's jumping. (Drain_resistance from equipped item came with the
'resistance from Excalibur' patch.)
Enlightenment and end of game disclosure didn't report level-drain
resistance if that was obtained via wielding Excalibur (or Stormbringer
or Staff of Aesculapius). Drain_resistance wasn't one of the attributes
set for intrinsics/extrinsics when wielding or unwielding weapon or
wearing/unwearing other equipment. loseexp() checks resists_drli()
which does check for items in use, so level drain would be aborted,
possibly after messages claimed that it was taming place. I didn't try
to untangle any of that, just changed set_artifact_intrinsic to include
a test for DRAIN_RES.
Reported directly to devteam (12 Dec), user had a config file originally
from MSDOS or Windows and used it on a linux system. That works as-is
except when it contained an invalid option line. Feedback was
"ad option line: "whatever-the-line-was
because of the carriage return character staying in the option buffer
after linefeed was stripped off from CR+LF line end.
He included a patch which replaced this existing fixup after fgets()
if ((p = index(buf, '\n')) != 0) *p = '\0';
with a loop over the whole string changing either '\n' or '\r' to '\0'.
This uses
if ((p = index(buf, '\n')) != 0) {
if (p > buf && *(p - 1) == '\r') --p;
*p = '\0';
}
instead. Ordinarily I would have just cloned the original line and then
substituted \r for \n in the copy, but the report mentioned "I couldn't
get index to work with carriage return". I don't know what he tried to
do or why simple index(buf,'\r') might not work as intended on his
platform, so I went with something that will work even if index()
behaves as strangely as the report suggested.
(We already have a couple of index(string,'\r') calls in use, but I'm
not going to change those unless someone complains about a problem.)
Some people are confused by the boulder -option, and
SYMBOLS=S_boulder, so allow defining symbols with
OPTION-lines in addition to the SYMBOLS.
So these are the same thing:
SYMBOLS=S_boulder:0
OPTIONS=S_boulder:0
Some people try to set boolean options in the config file
by giving the option a parameter, so allow that:
OPTIONS=color:true
Allowed parameters are "true", "yes", "false", and "no".
Negating an option and giving it a parameter is an error.
Explosion caused by an unseen gas spore resulted in messages about
"explosion" instead of "gas spore's explosion", which is intended, but
followed that with a death reason of "killed by a died" which isn't.
Test case: Bigroom, full of boulders, with a single
path from travel start to travel end. Boulders (and
doors) are added to the travelstep[xy] arrays multiple
times, and will overflow the arrays.
Original patch via Acehack by Alex Smith
Test case: U-shaped corridor, with a known trap in it.
Before this change, travel would try to move straight at
the target, bumping the wall or walking into a dead-end.
After this, travel will go along the corridor and then stop
right before the trap.
Original patch via AceHack by Alex Smith.
Shorten the dip-into-fountain, dip-into-pool, and dip-into-potion prompts
when flags.verbose is off. For non-verbose, use "it" (or "them") instead
of the formatted object name of the item being dipped.
Also, the "What do you want to dip <object> into?? [xyz or ?*]" prompt
for dipping into a potion had an extra question mark. I must have seen
that umpteen times before it actually registered.
No fixes entry; these are changes to post-3.6.0 changes....
The 3.6.0 feature of dipping only a subset when attempting to dip a large
stack of potions into another potion (other than water) was calculating
the size of the subset poorly. Dipping 9 non-magic potions would always
dip the whole stack, but attempting to dip 10 would split the stack and
dip 2..9, so manually splitting off 9 in advance let the player always
get maximum yield. This anomaly didn't extend to dipping magic potions,
where dipping 2 always dipped "all" 2 and attempting to dip 3..N dipped
2..min(N,9) regardless of N. Also, the decision about whether what you
were dipping was magic was based on the potion being dipped even though
most alchemy formulas yield the same outcome when dipping magic potion
into non-magic or vice versa.
Change the splitting calculation to yield 3..min(N,8) for magic and 7..N
for non-magic, with no extra threshold that can produce anomalies in the
result. Also, the determination of magic vs non-magic is based on the
outcome rather than either of the inputs--unless the outcome is random,
in which case it will be treated as magic if either of the input potions
is magic.
Putting gold into a hero-owned container on a shop's floot gave credit
for the amount of the gold but also set the gold object no_charge, so
it could be taken out without taking away the credit. Then put back
in and taken out as many times as the player liked, doubling the gold
each time until the shopkeeper was out of cash.
I think the proper fix would be to avoid giving credit instead of not
marking the gold no_charge, but that would require multiple additional
changes so I took the easy way out.
Most of the changes to pickup.c are reformatting that it escaped prior
to release. The changes to shk.c are cosmetic and not part of the fix.
Avoid "spellbook of novel" after novel becomes discovered. Now it will
just be "novel". Prior to discovery, it might be on the list as "book
called whatever" if the player assigns a type name.
Also, make novel become discovered after reading one instead of only via
object identification. It already shows up as "novel" in inventory, but
changing its definition to designate it as not-interesting-to-discover
feels disrespectful to the tribute.
Requested during beta testing: if hero can't jump, have #jump command
attempt to cast the jumping spell. This is similar to how #unturn and
^T cast spells when used while lacking the innate ability.
Reading a non-cursed scroll of enchant weapon has a side-effect of
uncursing a weapon welded to hand(s). Make it do the same thing for
cursed tin opener, the only non-weapon/non-weptool that welds to hand.
Applying a non-wielded tin opener and then declining to pick a tin to
open would wield the opener without having any time elapse.
Reformat the new tin opener code.
Remove a no-longer-used label in doapply() in order to avoid a warning
from gcc.
Bug bz14, no web id.
Steps to reproduce:
- have a stethoscope handy.
- place an amulet in a doorway and move one square outside the room's door.
- create and lead an invisible stalker to be on top of amulet, with you
just outside the room beside the door square.
- zap the stalker asleep with a wand of sleep.
- put on a blindfold.
- quaff a potion of object detection.
- amulet shows in the doorway.
- save the game and keep the savefile for ease of returning to this point.
Bug 1 observed (remember that you're blind due to blindfold):
- zap a wand of death at the stalker that you know to be on top of
the amulet, but that the game gives no indication of.
- if the stalker left a corpse, and you apply a stethoscope to the
doorway, the game tells you that "You determine that that unfortunate
being is dead" yet no being or corpse is displayed, still just the amulet.
Fix that by calling map_object(corpse, TRUE) in its_dead() under these circumstances.
The circumstances in the original report were also reproduced, specifically:
If a stethoscope finds an unseen monster on a square with an
object-detected object while blind, after killing the monster, the
object isn't remembered.
That remains unfixed because the I (invis monster glyph) aleady overwrote the
detected object glyph, so it is a much tougher situation.
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.
Suppress a couple of 'dead increment' diagnostics from the clang static
analyzer. The assignments are dead, but keeping the variable up to date
is more valuable (in case someone someday changes the code to use the
affected variable somewhere farther along in that function) than changing
the code to avoid the assignments in order to prevent the diagnostic.
This will only work to suppress the analyzer's diagnostic messages if
either FORCE_ARG_USAGE or GCC_WARN is defined when compiling makemon.c.
Avoid the possibility of a user-supplied name interfering with killer
reason truncation. A monster named ", while" that killed the hero
would result in "killed by <mon-type> called " being displayed on the
tombstone after stripping while-helpless reason to shorten the text.
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.
Like the just fixed naming for discoveries list, there are several
other add_menu() calls which specify <space> instead of 0 as a useless
selector on separator lines. These others are all for role selection,
where menus don't get big enough to need next-page.
I don't know what I was thinking at the time, although it must have
seemed like a good idea for some reason....
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.
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.
