Some monsters can't be named, but if the user tried to assign them a
name that matched what they were already called, the rejection message
could be silly. Reported case was "I'm Izchak, not Izchak!". The fix
is more general than just for shopkeepers, although their reject
message was silliest when complaining about the name already in use.
For the cited case, feedback will now be 'He is already called Izchak.'
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.
_M_UNIX (SCO UNIX) and __linux__ (all flavors of linux?) both call
has_colors() for TTY_GRAPHICS+TEXTCOLOR configuration, but neither
declared it. The new declaration is just a guess based on usage.
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.
Give all the attribution lines more indentation than a single tab so
that they never line up exactly the same as the text which precedes them.
Combine some attribution lines that had been split across two or three
lines but could reasonably fit on one or two.
Include a second boomerang quote from Pratchett--currently commented out
since the first boomerang quote is also from him.
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.
