This is similar to commit 98d381de46
(which mis-classified the bug as post-3.6), using #rub on a lump
of royal jelly and supplying '-' rather than an egg as the target
yielded "You mime rub the royal jellying on something." Change
it to be "You mime rubbing the royal jelly on something."
Restore some old behavior for the apply command that was changed
by the "getobj refactor" patch. You couldn't attempt to apply
potions to determine whether they were oil, couldn't apply gray
stones once touchstone was discovered, and attempting to apply
arbitrary items gave "that is a silly thing to apply" rather
than "sorry, I don't know how to use that."
Latent bug: selection_do_line() for a single point produced
spurious line(s).
I haven't got a test case so am taking this one on faith....
While in there, do some nearby formatting fixups in sp_lev.c.
Fixes#492
Don't include "Click!" in the feedback when a rolling boulder
trap is triggered if the hero is deaf. Some feedback based on
being able to see a monster be hit by a rolling boulder should
also be reported if the location can be seen and an invisible
monster can be sensed there. Change "you hear rumbling in the
distance" to "you hear rumbling nearby" when unseen activity is
close. If the boulder itself is visible when it starts to roll,
report seeing that instead of hearing rumbling.
Fixes#490
Issue is about monster shape changes being sensed via telepathy
while hero is swallowed, so player gets told about things that
aren't being shown on the map. Similar situation while underwater;
only monsters in adjacent water spots are shown on the screen, but
messages about sensed monsters will continue to be given. It isn't
limited to shape changing; lots of places include telepathy,
extended monster detection, and warning against specific types of
creatures as criteria to decide whether the hero 'sees' something
that isn't directly visible happen.
Change sensemon() to behave as if being swallowed or underwater
blocks telepathy, extended monster detection, and warning. I
consider this to be experimental, but it needs much wider testing
than would take place if put into its own test branch. It can be
tweaked or reversed if that turns out to be necessary.
There should be no change in behavior when not swallowed and not
underwater. But for either of those two situations, some messages
that have been getting delivered may be different (such as using
"it" instead of sensed monster's name) or suppressed.
Fixes#486
The message given when attempting to light a lantern with no power
left described it as a lamp. Change that to lantern. Also, "has
run out of power" duplicates the message given when it burns out;
change that part to "is out of power".
Your lamp has run out of power. -> Your lantern is out of power.
Fixes#489
A display optimization assumed that the color of a glyph wouldn't
change unless the glyph itself changed, but there is a single glyph
for all altars and unaligned is shown with a different color than
the three aligned ones. If there was an unaligned altar outside
of Gehennom (orcish mine town, some quests) and an invisible hero
(without see invisible) converted it, it stayed the old color until
there was some other reason to update that screen location.
Fixes#491
We used to have the contents of chests and large boxes be immune to
water damage, oilskin sacks immune unless the sack was cursed, other
containers be vulnerable. Some reddit discussion about ice boxes in
unnethack indicates that they are treated like oilskin sacks, which
makes sense. This adds that to nethack and also makes chests and
large boxes behave similarly. So it's now: nothing is immune even
when cursed (except statues); oilskin sacks, ice boxes, and other
boxes are immune to water damage unless cursed; all other containers
vulnerable even when not cursed.
|
| Old New
|immune all statues, statues
| the time chests, large boxes
|
|immune when BU, oilskin sacks oilskin sacks,
| vulnerable if C ice boxes,
| chests, large boxes
|
|vulnerable ordinary sacks, ordinary sacks,
| all the time bags of holding, bags of holding
| ice boxes
|
I suspect that the old ice box classification might have been an
accident caused by the Is_box() predicate yielding False for it.
The changes won't make much difference to actual play. Chests and
large boxes are rarely carried and never start out cursed, ice boxes
even more so, and sacks/bags haven't been changed. However, players
might intentionally curse a container to keep strong pets from
picking it up, or be carrying a box because they haven't found a bag
yet and then muck about with fountains or thrones and get it cursed.
'final_fpos' shouldn't have been moved to the 'g' struct. Even if
a game went all the way through topten and was restarted as a new
game that also went all the way through topten, 'final_fpos' would
get a new value rather than being messed up by a stale old one.
From a beta tester six years ago: specifying 'scores:own' resulted
in an option setting of 'scores:3 top/2 around/own' when player
wanted 'scores:0 top/0 around/own'. Change it so that when fewer
than all three fields are given new values, the others are reset
rather than having their old values merge with new settings.
Also, 'scores:none' can be used to get 'scores:0 top/0 around/!own'
to skip the scores at the end without skipping notification of
whether the ending game's score made it into the top N list.
Options parsing accepts '!scores' and then ignores the negation.
Changing the optlist flags for 'scores' to allow negation resulted
in a complaint about missing value; I gave up instead of pursuing
that. 'scores:none' should suffice.
Setting 'scores:!top/own' or 'scores:!around/own' would behave as
'scores:1 top/!own' or 'scores:1 around/!own', respectively.
'scores:!top/!around/own' behaved as 'scores:1 top/1 around/own'
(note affect of two prior negations on final field compared to
single negation in the earlier two variations). This fixes those.
Prayer reward can already uncurse a cursed saddle because hero is
stuck on it. Allow scroll/spell of remove curse to do so too.
The original riding implementation in slash'em operated with the
saddle in hero's inventory rather than in the steed's, so it would
have handled this without any extra effort. Presumeably that was
overlooked when incorporating riding into nethack changed it to
have saddle be part of the steed's inventory instead of hero's.
When swallowed and blind, the swallowing monster is described
accurately, but being held rather than swallowed describes the
monster as "it". That's normal, but the status feedback section
of ^X output lists
|You are held by it.
which looks pretty weird. Change that to be
|You are held by an unseen creature.
Zapping wand of opening or spell of knock at engulfer while swallowed
would make the engulfer expel the hero; this change makes zapping
other holders release their hold. Zapping self now achieves the same
effect, as does breaking a non-empty wand of opening. When poly'd
hero is holding a monster rather than being held, that monster will
be released.
Engulfers can't re-engulf for 1 or 2 turns after releasing the hero
in order to prevent hero from being immediately re-engulfed. Impose
the same limitation on other holders.
From newsgroup discussion where slash'em changes have revealed a
latent nethack bug: prevent placing level teleporters in single-
level branches. The Knox level doesn't have any level teleporters
(or random traps) but wizard mode wishing could create them there.
They wouldn't do anything because the only possible destination
would be the same level. Pushing a boulder onto one used to trigger
an infinite loop (and still does in slash'em, which has other
single-level branches besides Ft.Ludios) trying to relocate it.
Boulder pushing was changed 15 years ago to prevent the infinite
loop and to avoid giving "the boulder disappears" message when a
level teleporter failed, but rolling boulder traversal lacked that
same change--it wasn't vulnerable to looping but could give an
inaccurate message claiming that the boulder disappeared when it
actually didn't. Fixing this is a bit late; rolling boulder trap
creation was recently changed to not choose a path that rolls over
teleportation or level tele traps any more.
The #twoweapon command was flagged as autocomplete back when using
an extended command was the only way to execute it. Take that off
since simple 'X' suffices. Do the same for wizard mode commands
that can be invoked with control characters. Probably ought to do
the same for #overview too but this change doesn't.
I started to add the autocomplete flag for #exploremode but that
would require an extra letter for #enhance so I decided not to.
There are some wizard mode commands that can't be executed under
X11 because they aren't flagged to autocomplete and its extended
command selection widget only offers autocomplete commands as
choices. I haven't attempted to change that.
Always require paranoid confirmation for #panic rather than just
when it has been enabled for #quit.
Pull request fixed two genetic engineer problems:
1) lack of "you hit <foo>" message when you were poly'd into one;
2) lack of shield effect animation ('sparkle') when a genetic
engineer hit magic resistant hero.
That opened a can o' worms.
3) hero lacking see invisible, poly'd into genetic engineer, and
turning target into an invisible stalker got no feedback about
the target vanishing.
A genetic engineer attacking a monster would polymorph it turn
after turn.
4) put back the teleport capability I removed when bringing it over
from slash'em;
5) have genetic engineer teleport away after polymorphing someone.
The various mhitm_ad_XXXX() routines used g.vis to have caller
decide visibility, but hmonas() for poly'd hero didn't set that so
some messages--not just attack induced polymorph--were based on
visibility of earlier monster vs monster activity.
6) have hmonas() set up g.vis even though it doesn't use that.
There may have been one or two other minor fixes before I managed
to force the lid back onto the can.
Fixes#485
When travel destination is one step away the code stops probing
for a path and reverts to normal movement, but it wasn't handling
the case where the one step was an impossible diagonal except for
hero being a grid bug. If the situation was a diagonal that's
too narrow to squeeze through, travel would end and regular move
would fail.
I've rejected the suggested fix and done it differently, without
attempting to figure out why the change to end_running() would
have been wrong. Clearly it was code that called end_running()
which needed to be fixed.
The test case was
..x|.
..|@.
.....
while carrying enough that directly moving from '@' to 'x' will
not be allowed. '@' would move one step south west and then stop
because findtravelpath() had ended travel due to single step move.
A similar case is
###
|x-#-
|0@.|
where 'x' is a doorway with intact open door and '0' is a boulder.
Prior to this fix, player would get "a boulder blocks the way" and
not move. After, '@' will move northeast then northwest then west
to get into orthogonal position and finally south into the doorway.
Even though it definitely fixes both mentioned test cases, I won't
be surprised if this results in regressions for other situations.
Fixes#487
Change how menu choice 'A' (auto-select everything) works. It will
now auto-select all things that match any other choices (object
class(es) or BUCX state(s) or possibly unpaid status). So it still
skips the second menu of specific objects. And it still picks all
objects when it is the only choice or if player uses '.' to select
it along with all the rest of the first menu's possibilities.
This change won't help anyone who picks 'A' without really meaning
to. (Maybe add a paranoid_confirm setting to for full-menu-A?)
Affects container apply/#loot and Drop-multiple. The invent.c part
is just formatting.
Change Trollsbane versus troll corpse revival: instead of revival
failing if Trollsbane is wielded at time of revival attempt, mark
the corpse no-revive if killed by Trollsbane (whether by the hero
or a monster).
If a no-revive corpse is within view when time to revive occurs,
give "the troll corpse twitches feebly" even when the hero isn't
responsible. That used to only apply if the hero zapped the
corpse with undead turning, which would have become inoperative
because now being zapped by undead turning clears the no-revive
flag and revives as normal. In other words, undead turning magic
overrides killed-by-Trollsbane or non-ice troll having been in an
ice box.
Report states that the dungeon overview menu doesn't honor the
'menu_headings' option. However, dungeon overview is not a menu.
Despite that, switch its hardcoded use of bold and inverse to use
the option value instead. It doesn't really need two different
highlights and this allows user to control which video attribute
gets used. If someone wants different highlighting for overview
than for menus, they're out of luck.
Fixes#481
Report raises two issues:
1) if you perform magic mapping while engulfed (or underwater) the
map got updated and player could view it with cursor+autodescribe,
but when done viewing it did not switch back to the limited engulfed
(or underwater) display.
2) when picking a teleport destination while engulfed/underwater you
have to pick the spot while seeing only the limited view of the map
that is shown while engulfed/underwater.
This fixes#1. I'm inclined to classify #2 as traditional behavior
and am not going to try to figure out a fix for it.
Fixes#483
Homemade tin would yield a flat 50 points of nutrition even when
made from a corpse that provides less than 50 points. Take the
minimum of the two amounts instead of always 50.
Fixes#478
Statues on Medusa's level are supposed to be from petrified creatures
rather than somebody's artwork, so creatures that can't be turned to
stone aren't eligible. However, creatures who change form when hit
with stoning damage (foo golems to stone golem) were being allowed.
Also, statues in cockatrice nest rooms are supposed to be from former
characters and take their names from the high scores file. But when
'record' is empty, the statue would be of a random creature instead
of being changed into a player character, so both not the latter and
possibly something that can't be petrified.
I've taken the Medusa part as-is but did the cockatrice nest part
differently. It rejected statues of non-stonable creatures in case
the named character attempt failed. I've changed things so that when
a named player character can't be created, it will use an unnamed one
instead of random creature. The issue of maybe ending up with a non-
stonable form goes away because all player characters are vulnerable.
Fixes#479
Player's pet killed a troll with Trollsbane and the corpse later
revived. He assumed that killing a troll with Trollsbane is what
prevents troll corpse revival but that is inhibited by the hero
be wielding Trollsbane at the time revival is attempted.
Having killed-by-Trollsbane be the reason for blocking revival
would be much better but looks like a lot of work for something
which was supposed to be a one-line enhancement to an under-used
artifact. This extends revival inhibition to having anyone on
the level be wielding Trollsbane rather than just the hero.
Not a proper fix but I think it's better than nothing.
Closes#475
when wearing an amulet. Wearing any amulet while having the
Protected attribute was conferring an amulet of guarding's +2 MC
bonus. Mattered when Protected via worn ring(s) of protection or
wearing Mitre of Holiness or wielding Tsurugi of Muramasa for
hero, or the latter two or being a high priest[ess] for monsters.
(Being Proteced via cloak of protection already yields maximum MC,
or via amulet of guarding yields intended result.)
The fixes37.0 entry oversimplifies.
Fixes#477
A polymorphed hero who exploded when attacking thin air would use a
radius based on experience level rather than the fixed radius that
the monster form itself used. When exploding at a monster it didn't
wake other monsters at all.
Fixes#465
When wights were given a cold attack back in January, their
difficulty rating wasn't re-evaluated. The dummy monstr.c
produced by 'makedefs -m' puts it at 8 rather than previous 7.
Adopt a feature mentioned in the xNetHack release announcement.
If you use the fire ('f') command when wielding a throw-and-return
weapon while your quiver is empty and the 'autoquiver' option is
Off, throw the wielded weapon instead of prompting to fill the
quiver. It will usually return and be re-wielded, so be ready to
fire again.
Implemented from scratch.
Apply visibility fixups for monsters triggering door trap
explosions or digging through doors similar to the monster-opens-
door-handling from a couple of days. Again, the issue is that
hero/player can see a closed door in situations where they can't
see an open one, and messages about the door being opened or
destroyed need to take that into account when seeing a closed
door go away.
Not as thoroughly tested as monster just opening closed door.
It was possible to wish for a secret door, if done at a wall or
door location, but not for a regular door. Add that. (Dig
followed by locking magic possibly followed by open or by kick
could cover most of the details without wish support, but there
wasn't any way to force a closed or locked door to be trapped.)
The wish request can include "trapped" (or "untrapped", the
default) and/or one of the 5 door states: "locked", "closed",
"open", "broken", or "doorless" (default is "closed"). If more
than one state is specified, the last one in the wish text
overrides others. If trapped is specified with open or broken or
doorless, it will be ignored.
Allow "looted" when wishing for a fountain, sink, throne, or tree.
For the ones with multiple loot tracking bits, it sets them all.
Explicitly reject a wish for a wall rather than claiming nothing
of that description exists.
Formatting: wrap various wide lines.
Report from roughly two and half years ago was about "<monster>
opens the door" without displaying <monster>.
Monster movement first decides whether a monster can pass closed
door. If so, the monster is placed at the door spot, a message
is given about that movement (unlock, open, smash down, &c), and
finally the map is updated.
Changing the sequence to update the map before issuing the door
message was not sufficient to fix this. In the corridor plus
closed door plus lit room map fragment shown here, when 'O' moved
to '+', you would see it there if the hero is at '1' or '2', but
not if at '3', '4', or '5'; open door was shown instead. But the
message described 'O' accurately rather than as "it" for all those
hero locations.
: -----
: #O+1...
: |2...
: |3...
: |4...
: |5...
: -----
For 3,4,5 the #vision command shows the closed door as 3 before
the O move, but blank (0) after. In other words, the closed door
is within line of sight but once opened, the doorway spot isn't.
It makes sense that the closed door behaves like a wall but I'm
not sure whether the behavior for an open door's breach does too.
I had an awful workaround that successfully displayed the monster,
but it wouldn't show the same thing if the door was already open,
so I've changed the situation to yield "You see a door open."
For !force_invmenu when attempting a command that needs an object,
if inventory is completely empty
What do you want to <foo>? [*]
will report "Never mind" and stop asking if player presses return
or report "Not carrying anything" and reprompt if player types '*'.
But for force_invmenu, it would report
Not carrying anything. Never mind.
without any reprompting in between the two messages. Just skip
the second message in that situation.
Perhaps the first case should avoid reprompting too but I haven't
gone that far.
Incorporate the changes from pull request #467, which itself
incorporates a fix for issue #441. Allows hands/self to be an
acceptable but hidden choice (don't think any command actually
needs this). When 'force_invent' option is on, show all the
acceptable but usually hidden choices if no ordinary candidates
are available instead of having an empty menu. Also, omit
force_invent's "* - (list everything)" extra menu entry if the
menu already contains everything.
Cleans up a couple of whitespace issues too. I changed at least
one more and added a couple of comments. I'm not sure about the
comment change that I made in hack.h; the original said "foo is
identical to foo" but the revision might not be accurate.
Fixes#467Fixes#441
The pull request that fixed a couple of instances where it was
possible to have multiple entries for gold in inventory indirectly
pointed out that the error checking was clumsy. If you executed
the #adjust command while having two '$' items in inventory, you
were told twice that you had multiple stacks of gold in inventory.
Change how that's handled so that the warning appears at most once
for any given #adjust command. Also avoids having #adjust's use
of getobj() re-scan entire invent for every item in invent.
Also, if player did manage to get two or more '$' entries, #adjust
would allow moving any but the last to a letter entry. Once in a
letter, further #adjust with count specified could split the letter
gold entries into even more gold entries. Now, if the player picks
gold as the #adjust 'from' item (which is only possible when there
are wrong letter gold entries or multiple ones or both) then #adjust
will now force 'to' slot to be '$' (without asking player to pick).
Lastly, the inventory check for multiple and/or wrong slot gold is
now performed by wizard mode sanity_check() in addition to #adjust.
for invalid 'O' values when option error messages are issued after
theme rooms have left iflags.in_lua set. The pull request just
turned the flag off but lua code turns back on and off after that
for other dungeon levels. nhlua probably shouldn't be sharing the
same error routine as options processing, or at least it should
toggle the flag on and off at need instead of pretending that it
can be global.
Fixes#471
Assigning a partial stack of gold to quiver (Qnn$) resulted in
an extra '$' slot in inventory, one for the unquivered part and
another for the quivered part.
Throwing a non-quivered partial stack of gold at self (tnn$.)
also resulted in an extra '$' slot after throwing at self was
rejected.
For the first case, reject the quiver-subset-of-gold attempt.
For both cases, recombine the two stacks back to original amount.
Fixes#469
If a monster read a scroll of earth and got killed in the process,
there would be an "dealloc_obj: obj not free" panic when trying to
use up the scroll. It was dropped to the ground with any other
possessions and no longer in the monster's inventory at the time
m_useup() was called. Use up the scroll before performing its
effects.
The patch does something similar for potion of polymorph, but if
newcham() can kill the monster then there are other problems
besides trying to use up the potion. I kept that in anyway.
Fixes#468
Post-3.6 change to monster inventory handling could result in hero
remaining mounted on an unsaddled steed (if saddle was removed via
opening magic).
Hero falling out of saddle would fall to the ground and take damage
even if levitating or flying without steed's help after dismount.
Fixes#470
Reported directly to devteam: constructing a verb by applying
"ing" to "dip <item> into" (when attempting to dip into '-')
didn't work too well. It yielded
|You mime dip <item> intoing something.
instead of
|You mime dipping <item> into something.
Reported seven years ago: when class genoicde (blessed scroll)
attempts to genocide something that has already been wiped out
|All foos are already nonexistent.
should be simplified to
|Foos are already nonexistent.
I think the redundant "All" was just there to avoid capitalization
handling for the monster species but that's trivial to deal with.
Add new '|' command, aka #perminv, which allows the player to
send menu scrolling keystrokes to the persistent inventory window.
Implemented for X11, where its usefulness is limited, and for
curses, where it is more needed and also more fully functional.
The interface can either prompt for one keystroke, act upon it,
and return to normal play, or it can loop for multiple keystrokes
until player types <return> or <escape>. X11 does the former if
the 'slow' application resource is False so that prompting uses
popups, and the latter when 'slow' is True where prompting is in
a fixed spot and doesn't end up causing the persistent inventory
window to be stacked behind the map window. curses always does
the loop-until-done approach. It also accepts up and down arrow
keys to scroll one line at a time.
Also adds two new menu scrolling commands, menu_shift_right (key
'}' by default) and menu_shift_left ('{') if wincap2 flags contain
WC2_MENU_SHIFT. Shifting allows different substrings of too-long
lines to be seen.
For X11, neither works because their handling requires a horizontal
scrollbar and for some reason that escapes me our menus don't have
one of those. If they did, shifts could work for all menus but a
shifted window would hide the selection letters. So shifting would
be most usefully done as: pan right, read more of any long lines,
immediately pan back to the left.
For curses, they only apply to the persistent inventory window.
Shift right redraws it with class headers and inventory letters
shown normally but the item descriptions omit their leftmost
portion, showing more text towards the end. Shift left reverses
that and does nothing if the beginning is already in view. Forward
and backward scrolling while shifted leave the shift in place.
Give the window-port side of *_update_inventory() an argument.
Calls in the core still omit that; invent.c's update_inventory()
is the only place that cares.
OPTIONS=menu_previous_page:\mv
BINDINGS=M-v:menu_previous_page
both worked, but
OPTIONS=menu_previous_page:M-v
BINDINGS=\mv:menu_previous_page
both failed. Make all four variations work. Tiny change made large
by the need to move some things around.
The option definition for menu_first_page had a couple of its flag
bits swapped. I didn't try to figure out whether that had any impact.
