Fix the problems From a bug report. So having
OPTIONS=IBMgraphcs
OPTIONS=noDECgraphics
would yield an ASCII display instead of showing IBMgraphics, but IBMgraphics
flag in the Options list would falsely show as on. Manually toggling it off
put things back into sync.
Avoiding the false setting is completely trivial. And fixing the
inappropriate override turns out to be easy too, unless I've bungled this.
One thing it does not do is try to warn about attempts to set conflicting
options like
OPTIONS=IBMgraphcs
OPTIONS=DECgraphics
Fixing that seems to be too messy to bother with, particularly since the
game runs ok (leaving the setting handled last in place).
Noticed when incorporating the "vampire dancing" patch: losing a level
while polymorphed would subtract from your normal hit points but didn't
affect your monster hit points. Now they'll lose d8 from max and current,
similar to the amount they increase when gaining a level.
This also addresses an issue from the newsgroup a few weeks back:
someone mentioned an assumption that Stormbringer drained an amount other
than d8 for monsters who use some other formula for their hit points. It
wasn't true, but now it will be (approximately). Most monsters with unusual
hit points aren't subject to level drain, so it shouldn't have much impact.
From a bug report, applying a
mirror at sleeping Medusa yielded "too tired to look at your mirror" even
even though the item being used was listed in inventory as "looking glass".
Several other messages and any target monster would produce similar things.
Perhaps they should auto-ID when applied, but I changed messages to use
the description if real name isn't known.
This also treats incubi identically to succubi regarding mirrors:
they like to see their own image and will take the mirror away when one is
applied at them.
Fix the problem pointed out by <email deleted>
where polymorphing into a new man at level 1 could be used to approximately
double or triple your hit points and spell power. With means to drain
level back down to 1 and with amulets of life saving to survive those times
you lose levels instead of gain, you could do this repeatedly and end up
with HP and Pw values in the millions.
This uses the earlier patch that records the HP and Pw increments from
level gains. Now when polymorphing into a new man, level based HP and Pw
are removed from the current values, remainder get multiplied by 80%, 90%,
100%, or 110% (average 95%, so tend to drop slightly), then a brand new set
of level gain increments (reflecting new man's Con and Wis) are added in.
Code for calculating spell energy is moved from pluslvl() and u_init()
into new routine newpw(). It and newhp() take over responsibility for
remembering the level based increments from pluslvl() which didn't deal
with the initial amount (stored in slot [0]; earlier patch didn't need it).
<email deleted> sent a report with
subject "Vampire-dancing can give you unlimited maxhp/maxmp" about how you
can manipulate your hit points and spell energy by using equipment to
lower Con and Wis prior to deliberately losing a level, then switching to
alternate gear to raise them prior to gaining the trivial 1 XP needed to
regain the lost level. With Stormbringer (to toss up so that it falls on
your head) or spell of drain level (to cast at yourself), you can do this
level toggling as much as you like since it doesn't consume any resources
in the process. All you is a supply of non-threatening monsters to kill
for the regaining half.
In March he sent "vampire-dancing (patch)" which didn't include a
patch but did give a URL ( http://nethack.angband.pl/vampdance.patch )
for one. That contained his suggested fix: recording the hit points and
energy points given each time you gain a level and then using those exact
amounts when you lose the corresponding level. It's still possible to
manipulate HP and Pw by losing multiple levels after you've boosted Con
and Wis to ascension ready status (you'll lose the original values but can
expect to get better ones when gaining levels back), but can only gain a
modest improvement and repeating it doesn't augment the effectiveness.
Plus it's much harder to regain multiple levels than it is to get just one.
His patch had a couple of bugs which I've fixed. I suppose that there
could be additional potential problems but the idea and its implementation
are both pretty straightforward. (This doesn't address the other recently
reported situation of using polymorph into "new man" while at level one to
multiply HP and Pw.)
From the newsgroup three or four weeks ago: sleeping or pararlyzed
unicorns would catch thrown gems despite being unable to move. Now they'll
magically dodge instead--in other words, thrown gems will always simply
miss the target (and land at its feet) when a unicorn is unable to move.
The unicorn won't be angered or awakened by the attempt.
From a bug report. Pushing one
boulder from a location which had more than one would open up line of sight
at that spot as if all boulders there were gone.
From a bug report: #M30: 3.4.2 bugs and ideas); describe
flyers (poly'd hero or riding flying steed) as flying when they use ladders
or jump down holes. This also gives feedback when using the stairs in the
ordinary up or down case, where no message was previously given.
From a bug report, player's character inflicted
with lycanthropy doesn't gain level drain resistance when in normal form
even though lycanthrope monsters do have it when in their human form. The
report claimed that the character didn't gain it when in beast form either,
but the code--and testing--suggests otherwise.
The same resist_drli() call used for monsters is used for the hero,
but the is_were() check there isn't able to recognize a lychanthrope hero
since youmonst->data doesn't track that when in human/normal form. This
adds another more specific check to handle that case.
Fix the crash caused by division by zero (attempt to compute rn2(0))
when deciding prayer boon for a character whose Luck went negative during
the course of the prayer. <email deleted> triggered it
by killing a shopkeeper with the ongoing damage from a scroll of stinking
cloud; his non-chaotic character was branded a murderer and lost two points
of Luck after the prayer was already in progress. (Prayers fail when Luck
is already negative, so the code to pick a boon expects non-negative values;
the fact that is always adds at least +2 leads to me to suspect that someone
already realized that luck timeout on Friday 13th could result in Luck of -1
at the end of a successful prayer--that value doesn't trigger this crash.)
For "the hair on the back of your neck stands up" or "the hair on
your head seems to stand up" make subject and verb agree when poly'd into
forms where "hair" is replaced by something explicitly plural like "scales"
or "cilia".
Fix the problem From a bug report. Presumeably the corpse exclusion at <u.ux,u.uy>
was intended to be for killing your way out of an engulfer, but there wasn't
any comment to that effect. The exclusion still applies if you were inside
the monster when it died; ridden steed is the only other way I can think of
to have a monster die at your location, so it should be the only case which
gets affected. Neither steed nor engulfer is allowed to generate a random
item when upon death; you already know what was carried in those cases.
The bulk of the diff is from reorganizing the relevant `if' and
subsequent indentation changes.
I've gotten tired of seeing newsgroup claims along the lines of
"since devteam is aware of this and has chosen not to eliminate it, they
must endorse it", so weaken the tactic of "pudding farming". It is still
possible to gain unlimited experience (past level 15 or so there's not
much point), but will be less effective for gaining items and for providing
sacrifice fodder. Keep track of which monsters have been created via
cloning (mostly puddings; gremlins and blue jellies are affected too but
nobody's likely to care much about them) so that they can receive special
handling. Make cloned monsters progressively less likely to leave corpses
as the number killed for a particular type goes up, and also much less
likely to drop random items at death. This is sure to need some tuning
once hard core farmers point out how they can still abuse it. For the
absurdly extreme case, see
http://scavenger.homeip.net/farmbot/HomePage
FYI, farmbot/PuddingFarmingHOWTO includes an impressive screen shot of a
dungeon level where rampant farming is taking place.
A cased missed by "alteration of shop-owned objects" patch in April.
If Sting or Orcrist is created in a shop using an unpaid weapon, update the
bill to reflect that weapon's increase in value. No new fixes entry needed.
When lit due to being wielded by a monster, Sunsword continued to emit
light after that monster was killed. This was fixed by <Someone> in 3.4.1 but a
change I made for 3.4.3 broke that fix. When mdrop_obj() was split out of
relobj(), relevant unwielding code ended up only being executed for monsters
who were still alive.
Fix the reported bug about an inappropriate space in the message
"For you, scum ; only N zorkmids for that foo."
when an angry shopkeeper quotes a price for an item which has just been
picked up. Also, suppress "only" in that case; just include it when the shk
isn't angry. And the word "zorkmids" was actually missing, so I added it.
I think the semi-colon should actually be a comma, but I've left that as is.
From <Someone>, half a year or so ago:
> When you've already entered the Castle, I think your God shouldn't be
> giving you the two Castle-related messages anymore.
>
> This might be difficult to track, I realise that.
It already suppressed the tune delivery feedback if you had opened the
drawbridge with music or if that drawbridge had been destroyed. And if
you've entered the castle by the back door or via wand of opening/spell of
knock, learning the tune could still be useful, so I didn't try to extend
dungeon tracking to the point of "entered the castle". However, if you've
already passed beyond the valley below then you most likely no longer have
much interest in the drawbridge, so add a check for that to the prayer
feedback suppression.
<Someone>'s real concern was probably more about the message phrasing
than the "useless" prayer boon (since it says "to enter the castle" rather
than "to open the castle drawbridge"), and that does make the god sound a
bit silly if you've already entered the building. It would make sense to
skip the first of the two messages if you make it inside without opening or
destroying the bridge, but this patch doesn't attempt to address that.
When you first attempt to walk down the stairs from the Valley of the
Dead to the second level of the Gehennom branch, the game prompts you about
whether you really want to proceed. But if wasn't keeping track of whether
you had previously level teleported past that point (which is possible when
starting from the Valley rather than from higher up), so would still issue
that once-only prompt if you used the stairs later. Mark the prompt as if
it has already given whenever you reach a Gehennom level beyond the Valley.
From a bug report: the invulnerability conferred
during the multi-turn delay for a successful prayer was not protecting
against damage inflicted by hostile mind flayer's "wave of mental energy".
Make it easier for a low level character with ordinary Max HP to get
the healing result from a successful prayer. Mid level characters are the
same as before: will be healed if at 1/7 (or worse) of max. High level
characters, or anyone with Max HP really high for their level, will need
to wait until current HP is lower before being able to obtain that result.
This mainly affects spoilers; the actual impact for any player who doesn't
know the old formula is fairly small. The exception is for "protection
racketeers" who manage to build up a high HP without gaining any levels;
a level 1 character will only get healed when at HP 5 or less, regardless
of what percentage of max their current hit points are.
Under the old system you could get healed at 6 HP if you had 42, at
7 HP out of 49, and so forth. Now you'll need to be at least level 2 to
get healed at 6 HP out of 30 or more, at least level 3 for 7-9 out of 35-45.
"Normal" max is capped at 15 times level and anyone above normal is treated
as if their max was that lesser normal value. Levels 1 to 5 use a new
threshold of current HP being 1/5 (or worse) of max, levels 6-13 use 1/6,
14-21 retain old 1/7 threshold, 22-29 now use 1/8, and level 30 uses 1/9.
The somewhat odd level break points are based on where rank titles change.
I think being asleep or unconscious ought to override vision the way
that being blinded does, but that's a more ambitious change than I care to
tackle. This replaces You("see ...") with You_see("..."), comparable to
You_hear(). It catches the reported door case and several variations of
light sources burning out while on the floor rather than in inventory, but
it probably misses some other cases. zap_over_floor() in particular is
highly suspect.
From a bug report. <Someone> as slashem-Bugs-883643 on 1/24/2004. To avoid
using the possibly invalid object pointer after calling bhit(), changed as
suggested to add another level of indirection allowing bhit to null the
object pointer before returning. Callers that are affected update their
object pointers after bhit returns.
Make petrification initiation or termination go through a new routine,
make_stoned(), instead of manipulating its countdown timer and delayed
killer directly. No change in behavior.
There's no reason in terms of bug risk or game play or saved data why
this shouldn't be done in the branch too, but so much of the surrounding
context has already diverged between trunk and branch that it's trunk only.
Make the names of the macros for handling the hero be similar to those
for monsters (where mis-use of `sensemon()' was the cause of a recently
reported bug). `senseself()' becomes more restrictive in what it specifies,
and current uses of it are replaced by new `canspotself()'.
From a bug report: zapping force
bolt broke an adjacent potion of blindness (possibly carried by the monster
he was attacking) which caused "it suddently gets dark" but further course
of the bolt resulted in now blinded hero recieving "a door appears in the
wall". make_blinded() was deferring vision recalculation until next pass
through moveloop() (or until next pline()--if the "gets dark" message had
been delivered after the call to make_blinded() instead of before, this
wouldn't have been noticeable). Fix is trivial: just recalculate vision
immediately when temporary blindness is toggled. [It might also be needed
for involuntary blindfold removal, although I suspect that that is always
accompanied by corresponding pline() which gets vision back into synch.]
<Someone> recently reported that after lieutenants had been genocided,
he saw a sergeant drink a potion of gain level and then vanish, leaving
behind its gear but no corpse. The message about growing into a lieutenant
and subsequently dropping dead would only be given if the monster could
be sensed via telepathy, not when it occurred in plain sight. I'm not
absolutely sure that this was unintentional, since sensing the dying
monster's mind might be giving additional information about what was
happening. But there was no comment stating that and I think such behavior
violates the principal of least surprise, so seeing it happen will now give
the message too.
Because the description seen by the player is "you have never changed
form" rather than "you have never polymorphed yourself", make death by fully
turning into green slime (even if that death is avoided via lifesaving)
violate the conduct. Suggested by <Someone> 9-Dec-2004. Likewise, eating
a mimic corpse and temporarily turning yourself into a pile of gold also
violates that conduct. Mentioned by someone--probably <Someone>, or possibly in
the newsgroup--a long time ago.
A post-3.4.3 change dealing with reaching into pits resulted in "you
sit on the air" if you used the #sit command after escaping a pit trap.
Change can_reach_floor() so that caller explicitly controls whether being
on the brink of a pit is a condition that prevents reaching the floor.
This also splits a fairly common message about not being able to reach the
floor into a separate routine.
There is still oddness here: if you're polymorphed into a flyer,
#sit yields "you sit down" followed by "you fly over a pit" (latter occurs
when escaping trap activation). A ceiling hider behaves similarly, but
the second message is "you escape a pit" and doesn't sound quite as silly.
Perhaps #sit should pass TOOKPLUNGE to dotrap(), or maybe there's some
better way to handle this?
Accept OPTIONS=pettype:horse quietly instead of issuing "unrecognized
pet type 'horse'" message. It doesn't actually do anything from player's
perspective--knights always get a pony and other roles always get a cat or
dog, as before.
I had a much more elaborate version which recognized "pony" (plus
"kitten", "little dog", "puppy" and assorted other variations of the
acceptable types), but it was absurd overkill for something that never
come up during actual play. If someone tries to specify "kitten" and gets
"unrecongized type", it shouldn't take him longer to figure out "cat" is
what's needed even without resorting to actually reading the Guidebook.
Can someone generate an up to date Guidebook.txt and check it in?
<email deleted>, attempting to #chat
with quest leader who was raised from the dead yielded "impossible: invalid
quest character". The code attempted to handle that but the conditional
logic for preserving the m_id field was backwards. 3.4.3 only dealt with
the corpse revival case; dev code tried to support it for statue animation
too but still had the same problem.
Several apparent bugs remain: if the leader is angry (perhaps hero
killed him before reviving him) he won't give an angry response if the
player initiates #chat rather than wait for adjacent leader to do so. If
it's an archeologist reviving the statue of petrified Lord Carnarvon, hero
gets a rather ironic message about feeling guilty for destroying historic
statue. Lastly, shouldn't there be a comparable quest_status.nemesis_m_id
so that if one player lugs the corpse or statue of his quest nemesis back
into the main dungeon and another one revives that, it won't start behaving
like 2nd player's nemesis? Live nemesis is explicitly kept out of bones
but I don't think the corpse or statue of one is blocked and its monster
behavior after revival is based on mon->data->msound==MS_NEMESIS rather
than on m_id of current game's active nemesis monster.
My previous change underwent a last minute simplification that changed
behavior. This puts things back to how I intended: at the "add new
autopickup exception pattern" prompt, empty input returns you to the upper
add/list/remove/exit menu and ESC returns you past that (back to play or to
other pending 'O' changes, if any). The previous change accidentally made
empty input behave the same as ESC.
1) in the autopickup exception sub-menu from 'O', change the selector for
"exit" from 'e' to 'x' so that the entries occur in alphabetical order.
Also frees up 'e' for some hypothetical future "edit" entry (I'm not
planning on attempting to implement anything along those lines though).
-1) I wanted to make 'x' start out preselected to show that it's the default
choice, but that doesn't work correctly--at least for the tty interface.
PICK_ONE menus don't know how to deal with having a preselected item and
in this case it ended up returning 'x' no matter what choice I made.
Even if that aspect gets fixed, it might have trouble with explicitly
picking the preselected entry since that would probably be toggled off
in the process. So the preselection bit of this menu is commented out.
2) at the prompt for adding new exceptions, quit adding instead of giving
"invalid syntax" warning if user enters empty input.
3) allow <ESC> in the "list" or "remove" submenu to quit all the way out of
the upper menu too.
4) simplify the way magic numbers are used for action_titles[] menu setup.
5) greatly simplify return value of special_handling().
6) avoid a potential for getlin() or strcat() buffer overflow if getlin()
were ever to be changed to return BUFSZ-1 characters instead of COLNO or
whatever its narrower current limit is.
I'm pretty sure that I've run into the issue of being unable to have a
preselected entry in a PICK_ONE menu before, but I can't recall if I ever
mentioned it. Fixing that looks like it'd be pretty messy and would need
to be done for all the interfaces. Ick.
I ran into a bit of a mess while working on some other minor change.
Remove trailing spaces and tabs, convert multiple spaces into tabs when
appropriate, discard spaces in <space><tab> sequences, plus a couple of very
small reformatting bits. No change in game behavior, or even any difference
in generated object file once line information is suppressed. Some of the
whitespace cleanup is for post-3.4.3 code, so the trunk and branch diffs
aren't equivalent.
Further discussion in the newsgroup pointed out a case not involving
<ESC> where the "In what direction?" prompt remained displayed after it was
no longer applicable: throwing something where there's no monster target
in the line of fire. You don't get any hit or miss message in a case like
that, so the last message (the prompt) stays in view. I don't think there
are any cases where getdir()'s caller deliberately wants to leave the old
prompt up, so just clear it unconditionally as soon as the user answers.
> clear stale prompt
[...]
> Can someone who understands the relevant windowing code fix ^R in getpos()?
I still don't understand why it wasn't working as expected, but moving
the existing cursor positioning after flush_screen() instead of before now
makes ^R work ok during getpos(). It doesn't restore the top line text so
isn't a transparent redraw but it now displays a prompt string there instead.
Likewise after typing '?' for help so that it should be move evident that
nethack is still waiting for you to move the cursor somewhere.
Also add support for ^L in numpad mode. I almost never use that and
didn't think of it the first time around.
From the newsgroup: applying various types of tools (example was a
mirror; figurine is another case) and then typing <ESC> at the "In what
direction?" prompt would leave the prompt displayed. User complained that
he tried to answer the no longer valid prompt--even though the cursor had
correctly moved back to the '@' on his map--and ended up walking into lava
instead. Suggested fix in the newsgroup was to use pline("Never mind.")
the way many commands already do, but it's simpler and more robust to clear
the message window before getdir() returns. Callers can issue Never_mind
feedback on a case by case basis as before; I haven't added any here.
Perhaps getpos() should get passed an extra argument telling it to issue
that message; then a dozen or so pline(Never_mind) calls could be removed.
I also was annoyed that ^R gave me the command assist display instead
of redrawing the screen with the prompt intact. This fixes it for getdir().
The corresponding fix for getpos() doesn't work correctly; it successfully
redraws the screen but leaves the cursor at the end of the 2nd status line,
despite the fact that it is followed by an existing cursor position call.
Can someone who understands the relevant windowing code fix ^R in getpos()?
(Easiest test case is probably just ^T in wizard mode.) I have't added an
entry for ^R to the fixes file since it isn't fixed yet. And I didn't look
to see whether yn_function() ought to handle ^R too; it might be used in
contexts where map redraws don't make sense.
I was going about the use of tmp_at() from the wrong direction.
Instead of trying to replicate how a monster has been displayed, just pick
whatever is shown at its location and then redisplay that after it's gone.
This uses Michael's suggestion for keeping the display up to date when
removing a djinni or water demon in advance of granting a wish (so that it
won't be present in a bones file if the wish is fatal--problem with earlier
fix was that player could notice monster was already gone while responding
to the wish prompt). It's not quite as straightforward as I was hoping for
and would get a lot messier if it needed to cope with Warning & Warn_of_mon.
Fix the problem From a bug report, so finding it in a bones file yielded a fully functional magic
lamp. Fix as user suggested: convert the lamp first.
It also left the djinni who would normally have disappeared right after
the wish. Water demons from fountains have that problem too. Unfortunately
my fix is a bit buggy: when removing the monster before granting the wish,
the player can notice. Is there a straightforward way to display a monster
where none is present on the map? Or do we need something comparable to the
obj->in_use flag for monsters, so that the bones code can discard particular
ones?
Pointed out by <Someone>: engraving with a cursed wand should pose a
risk of having it explode just like zapping does. [At the moment when one
explodes, any existing engraving doesn't get changed.] Suggested by someone
(<Someone>?) some time back: explosion due to recharging could be consolidated
with explosion due to zapping cursed wands. And noted by <Someone> in the
newsgroup: '+' in an engraving--perhaps written by someone trying to leave
bones file notes--should have a chance of being partially rubbed out to '-'.
Reviving a corpse or statue restores the monster to life before
deciding whether the object which was used up in the process belongs to a
shop. This resulted in a rather strange situation when the revived monster
was the shopkeeper involved. The object can't have been stolen; there was
no shk to own it at the time it got used up.
Manlobbi's statue of a shopkeeper comes to life.
You owe Manlobbi N zorkmids for it.
Suppress "of a shopkeeper" in such a case, and do not charge the hero for
using up the statue. The corpse case only needed the second part.
This revises post-3.4.3 code so doesn't warrant a fixes entry.
My previous fix (trap.c) prevented the panic, but didn't actually stop
gold possessed by a reanimated statue from doubling. That problem was due
to how the monster info was saved rather than to how it was restored.
The previous fixes entry applies.
From a bug report, using stone to flesh to
reanimate a petrified monster who was carrying gold (in his case, it was
a shopkeeper) resulted in gold in the monster's inventory. Somehow it was
also being duplicated in the mgold field--I didn't try to figure that part
out--so killing the monster produced double gold. More significantly,
probing such a monster prior to killing it caused a panic when the monster
inventory was being massaged for formatting.
Fix is trivial: use a routine which knows about special handling for
gold when transferring statue contents to resurrected monster. Both aspects
of the problem only occurred for the !GOLDOBJ configuration (which is our
default). However, any objects which confer something special when simply
being carried would have also been misbehaving--automagic animation of
cursed figurines is the only applicable situation; too rare for anyone to
have noticed.
Implement the suggestion that Fire Brand avoids damage from rust traps
by boiling away the water. Rather than making this be trap-specific, it
applies to all types of erosion which go through erode_obj(). That includes
hitting rust monsters but not dipping into potions or fountains, nor falling
into moats. And it doesn't provide 100% protection, just a high chance of
avoiding rust damage. Also, Frost Brand gets similar protection by freezing.
The message handling needed some rewriting for the branch version.
That compiles ok but hasn't been tested. It would have been simpler just to
move Yobjnam2() over even if nothing else was changed to use it yet....
