Pasi Kallinen [Tue, 19 Apr 2022 11:56:51 +0000 (14:56 +0300)]
Fix panic on thrown potion of acid when swallowed
When you're swallowed and throw a missile that kills the swallower,
the thrown missile is picked up by the swallower before death.
This caused a panic when you threw a potion, which was first picked up
by the swallower, which upon death dropped the potion on the floor,
but then throw code was trying to destroy the potion ...
From 6 year old email: m_detach (monster death or removal from play)
and relmon (monster migrating to another level) both take a monster
off the map but they weren't consistent with each other. Change them
to use a common routine for that.
I'm not sure whether the inconsistencies resulted in any bugs. The
email was concerned about handling for monsters that emit light, but
those aren't actually common to the two removal methods and turned
out to be ok.
This attempts to make item-actions, #herecmd, and #therecmd be more
robust. When rhack() or yn_function() take queued input off cmdq
and get something unexpected, discard the rest of the queue.
It also fixes the two crash cases that entrez reported. There are
bound to be others though.
I think a lot of actions that can be executed by queued input are
going to need nomul(0) calls to handle repeat counts that should be
ended early if something unexpected happens or something expected
fails to happen. But that clears cmdq so may be tricky to decide
where to use.
Fix eat floor food and drink from dungeon feature via #herecmdmenu.
That uses queued commands, but those two actions were changed to
skip the floor when queued input was present because asking about
floor items interfered with context-sensitive inventory item-actions.
I was misled by a comment that says it couldn't insert an m-prefix;
that was for treating the 'm' key as typed text rather than as a
command. There's no problem with inserting a #reqmenu command which
is what 'm' is these days. So item actions can force 'm' to skip the
floor and go directly to inventory, also the #eat and #quaff commands
don't have to alter their behavior when queued input is pending so
the #herecmdmenu usage for them gets fixed.
For Qt with 'popup_dialog' off, if I typed "#quit" then the prompt
"Really quit?" was displayed in the message window as expected.
But if I typed "#" and then clicked on [quit], sometimes the prompt
wasn't visible even though the program was waiting for me to answer
it. I've noticed this a time or two in the past and just pretended
that it hadn't happened; since I usually enter extended commands by
typing their name, it didn't stand out much. Testing #repeat with
extended commands brought it back to mind.
I don't understand what's going on, but this one-line patch seems
to solve it. (With a multi-line message window, clear_nhwindow()
doesn't erase anything, but for Qt it does update the most recent
entry.)
Using '&#' or '?f#' showed "# perform an extended command (##)".
The "(##)" part looks rather silly and is not helpful. Expand the
text a little and omit command name for that particular command:
"# enter and perform an extended command".
The comment preceding new 'savech_extcmd()' said that the core didn't
care whether it was given the full command name or just enough leading
substring to be unambiguous. Then it tested the string against
"repeat" which contradicts that comment. Didn't seem to be an actual
problem because "#repeat" is not flagged for auto-completion, but fix
the code to match the intent of the comment and reword the comment to
match the code.
Fix '#repeat' for tty; both it and ^A can repeat an extended command.
Fix both for curses; they can repeat an extended command instead of
just repeating the initial '#' to start getting an extended command.
X11 (tested), Qt (tested), and probably Windows GUI (not tested)
behave the same as before: ^A (or #repeat) after an extended command
just repeats the # to run the dialog to get an extended command.
I hope this introduces fewer bugs than it fixes but I don't think I'd
bet on that....
Picking a potion from inventory and then picking 'quaff this potion'
from the context menu needed handling similar to eat/offer/tin: skip
floor candidates. If you were on a fountain or sink, picked a potion
from inventory and then the quaff option for it, you weren't prompted
to drink from the fountain but you were prompted for what potion to
drink instead of using the one that had already been picked to
initiate drinkig.
If you used ^A to repeat a command which had taken no time, the
repeat execution would take time. This fixes that. Also, give some
feedback when trying to repeat an invalid command.
Internals bit: don't use 'X == cmd_from_func(do_repeat)' to decide
whether key X is the key for #repeat. Both X and Y might be bound to
that action and cmd_from_func() could return Y rather than X.
There is another ^A bug that I haven't figured out how to fix:
t ESC start to throw but don't finish
^A nothing seems to happen
^A "You don't have that object."
The first ^A repeats 't', doesn't display a prompt for what to throw,
but does request input for it. The second ^A fulfills that input and
doesn't match any inventory item. Either 't' shouldn't have been put
into the do-again buffer or do-again handling should have ceased when
it was taken out and there was no further remembered input, so that
normal prompting would resume. My tentative attempts for both those
approaches didn't work.
Issue #734 reported as "parse function" by Meklon2007: the change
yesterday intended to make ^A work for commands that were preceded
by a prefix was triggering a crash if used after a keystroke that's
not assigned to any command.
'M^A' or '~^A' would segfault by derefencing a null pointer when
checking whether 'M' or '~' was a prefix. This prevents the check
attempt from doing that, but a better fix would be to not put the
invalid command keystroke into the do-again buffer in the first
place.
Pasi Kallinen [Fri, 15 Apr 2022 15:52:46 +0000 (18:52 +0300)]
Revisit the Valkyrie goal level hack
Instead of hardcoding the lava terrain change in core, if the stairs
are created in a fixed location, force the terrain to room floor first.
Move the surrounding lava changing to room floor to the Val-goal lua
file.
Reported by luxidream via the web contact form and also as github
issue #732: using the repeat command after F+direction would take a
step in direction if there was no target to fight.
The direction was being repeated without the F prefix. It wasn't
specific to F; m+dir misbehaved too. This fix seems to work but it
should be replaced with something more robust.
Reported by k2, arriving at the final level of the Valkyrie quest
can issue a recently added impossible
| mkstairs: placing stairs up on molten lava at <68,13>
The report said it was easy to reproduce, but it took me multiple
tries (so not hard to do, but not a sure thing on any given attempt).
The stairs on that level are placed at specific coordinates that
are outside the pre-mapped area, so there's no guarantee that their
spot will be suitable for stairs. The underlying terrian changes
from lava to stair, but only after the warning about molten lava.
This hack solves that particular level but is not a general solution
for this type of thing. When about to make stairs on a lava spot,
change that spot to normal floor first. Plus 50:50 chance to change
each adjacent lava spot to floor too so that there's decent chance
for some elbow room upon arrival.
Also, turn the no-flip attribute off for that level so that 'fixed'
location of the stairs can occur in four different places.
Reported by gebulmer: if charging exploded a ring, the ring's memory
got freed but the stale pointer was passed to cap_spe() which accessed
it again. Fix by setting the object pointer to Null after using up
the ring. This was a post-3.6 bug.
Make being offered floor food and declining behave similarly to
being offered a chance to drink from or dip into a fountain and
declining: insert "else" into
| "You don't have anything [else] to {eat | offer | tin}."
when there is nothing applicable in inventory.
Simplify the recently added handling for inserting "else" into
| You don't have anything [else] to {drink | dip into}.
after declining to use a fountain/pool/sink at the spot when not
carrying any potions.
Allow the player to precede q/#quaff or M-d/#dip with the 'm' prefix
to skip asking about fountains, sinks, or pools if one of those
happens to be present, similar to how using it for e/#eat skips food
on the floor and goes straight to inventory.
If you use it and don't have any potions, you'll get "you don't have
anything to drink" or "you don't have anything to dip into", same as
when there is no suitable dungeon feature present combined with no
potions. However, if an applicable dungeon feature is present and
you don't use the prefix but answer 'no' to drink from fountain,&c
and you don't have any potions, "else" will be inserted into the
message: "you don't have anything else to drink".
A big part of the diff is just a change in indentation level for
code that is now inside 'if (!iflags.menu_requested) {' ... '}'.
rhack() normally calls parse(), parse() sets context.move to True
assuming that the player's next action will take game time, then
when it returns, rhack() sets context.move back to False if the
assumption turned out to be incorrect. But when performing actions
after picking something in inventory, rhack() doesn't call parse()
so context.move is left at False.
This was hidden by making the inventory command take game time if
the player picked an item and set up an action to be done with it
even though the action hadn't taken place yet. So time was being
accounted for but if the hero didn't get consecutive moves then
monsters got their turn between the shouldn't-take-time inventory
command and the ought-to-behave-like-normal-command queued action.
My initial attempt to fix this (before figuring out how context.move
works) by stopping inventory from taking time didn't work because
queued item-actions stopped taking time too, or rather the fact that
they took no time became exposed. This second attempt doesn't have
that problem and I think it is correct.
Normally dipping gets the thing to dip first and what to dip it
into second and the item-action handling knows that. I'm not sure
why that wasn't working as intended and I couldn't figure out how
to make it do that, so went another way: this adds an internal
extended command that executes an alternate dip routine which gets
the potion to dip into first and the thing to dip into it second.
The #dip command should allow an 'm' prefix to skip fountains and
pools, similar to how eating accepts it to skip food on the floor.
But this doesn't implement that.
Picking a corpse while looking at inventory issued a menu that had
entry for eating that and if on an altar another one for offering
that. Picking the eat or offer choice worked as long as there
weren't any other corpses on the ground or altar. If there were
others, they'd be skipped but you'd get prompted for which item in
inventory to eat or offer instead of operating on the one that was
used to initiate the action.
Issue reported by Meklon2007: picking a container from inventory
didn't offer #tip as a possible use of the item.
Implemented in commit 7b351bc20d60aa4e70a7433fa5776a81c0f2a4b4
but I forgot to close the issue, so this adds a fixes entry for
it in order to do that.
Add a menu option for #tip when selecting a container from inventory.
Also, move the recently added 'unwield' option to the order it gets
placed in the menu for primary weapon: before 'a' because it's
spelled '-'.
Noticed when adding a 'tip container' choice to item-actions for
context sensitive inventory (update pending). Putting items into a
container with menustyle traditional and then takiing them out with
the #tip command while 'sanity_check' is On would produce warnings
once they were on the floor.
askchain() uses object bypassing to be able to cope with multi-drop
potentially changing invent, and it tried to reset that when done.
But it did so with the original object list (invent in this case)
and that doesn't reset individual objects that have been moved to
any other list. The between-turn resetting of bypass bits wasn't
doing so for container contents. The sanity check wasn't--still
isn't--checking those either, so it wasn't noticeable while items
were still inside the container. But taking them out with #tip
doesn't touch any bypass bits, so between-turn reset isn't triggered
and the items that came out of the container with bypass set
continued to have it set while on floor. sanity_check complained.
Change clear_bypasses() to handle container contents, and change
askchain() to call it instead of just clearing bypasses for whatever
is left of its input chain. (The latter probably isn't necessary
now that the between-turn cleanup deals with contents.)
Add '-' choice if player picks wielded weapon. 'w-' is effectively
the unwield command but a normal inventory list doesn't present '-'
as something that can be picked, so there's no context menu entry
that can suggest wielding it.
Make 't' clearer. Don't offer it as a choice when selected item is
worn, distinguish between throwing and shooting, and introduce a bit
of plural handling.
Since we aren't using a magic 'A' command to "equip" and "unequip",
make the uses of P/R/T/W match up with how they normally operate so
that player can learn them while using item menus.
\#dotypeinv ('I') - show title for inventory subset
When asking for an inventory subset for one of the meta-classes that
can generate output which spans object classes (so B,U,C,X, and P),
insert a title at the start of the resulting inventory list. (Iu and
Ix produce alternate output that already includes a title.)
Also, stop handling '$' differently for menustyles traditional and
combination from full and partial. 'I$' was running the '$' command
for the first two styles but just showing the inventory entry for
gold for the last two. Change to the latter for all styles.
Pasi Kallinen [Sun, 10 Apr 2022 13:09:40 +0000 (16:09 +0300)]
X11: set menu entries to same length
While testing the new mouse action menus, it was quite annoying
to try and hit some shorter entries. Make all the selectable entries
the same maximum length, and with text left justified.
Stop attempting to catch up for lost time for shop damage repair
when getlev() loads a previousl visited level. Normal shopkeeper
behavior will take care of that.
Also, fixes the display related aspects of shop damage repair
interacting with ball and chain. They don't happen when its done
while the map is being shown.
preliminary fix for github issue #726 - restdamage
Reported by entrez, restoring a saved game runs the shop wall/floor
damage repair routine. It was taking place before attached ball
and chain were fully restored so the repair routine treated them as
ordinary objects if they happened to be in a wall gap that gets
fixed on the same turn as restore takes place. They could end up
being moved to a spot that's too far from the hero and then trigger
an impossible "b&c distance".
This restores ball and chain before shop damage repair takes place
so the repair routine deals with them sanely and the impossible won't
occur any more. However, the repair still happens before the current
level's map has been displayed and that looks pretty strange during
the shopkeeper's message. Also, if the hero and the ball start on
opposite sides of the gap, after the gap is repaired the ball will
still be shown as a remembered object at its old spot even though it
ends up being located at the hero's feet.
When punished, the ball gets formatted as
| heavy iron ball (chained to you)
but the chain was just "iron chain". Since iron golems leave some
of those behind, doname() shouldn't just assume that you know which
chain is locked to your leg. Change the formatting for uchain to
| iron chain (attached to you)
If setworn() issues "Setworn: mask = 1234.", format the number in
hexadecimal so that the high bits are easier to decipher. Noticed
when experimenting with ball and chain where the decimal values of
their worn-masks are beyond the range of powers of 2 I recognize.
Issue #722 posted by copperwater and commented on by Entrez: both
shk_your() and the() inserted "the" in front of a unique monster's
corpse, yielding "the Lord Surtur's corpse glows iridescently" and
"the Lord Surtur's corpse drops to the floor."
Teach both of those routines to skip "the" when used for monsters
with personal names. It now omits "the" for "Medusa's corpse" but
still gives "the Oracle's corpse".
shk_your() operates on an object and can deal explicitly with corpses
of named monsters. the() operates on text and has to guess whether
it is being used in a similar situation. Right now the guess is just
"is there an apostrophe present?" and might need further refinement.
Pasi Kallinen [Sat, 9 Apr 2022 12:19:52 +0000 (15:19 +0300)]
Context sensitive item usage from inventory
Allow selecting an item from inventory and show a menu of actions
applicable for that particular item. Some of the entries might
be slightly spoilerish (eg. it'll reveal that you can read T-shirts),
but the improved usability for new players is more than worth it.
Generally known as "item actions", this was first implemented
in AceHack by Alex Smith.
Michael Meyer [Thu, 7 Apr 2022 18:54:00 +0000 (14:54 -0400)]
Fix: object detection vs mimic statue disguise
Cursed potions of object detection were showing all mimics disguised as
statues as 'i' glyphs, because object_detect used PM_TENGU as the
corpsenm of any mimic disguise. Instead, use MCORPSENM when available
so that hidden mimics will be mapped with glyphs corresponding to their
actual disguises.
Give some feedback for monster detection if drinking from a fountain
fails to find any monsters. Potion or spell gives "strange feeling"
feedback in that situation but fountain didn't report anything.
Michael Meyer [Thu, 7 Apr 2022 16:51:35 +0000 (12:51 -0400)]
Add message for failed fountain monster detection
When the fountain quaffing monster detection effect was triggered on a
level without any monsters, no message would be printed. I think this
was the only scenario where drinking from a fountain wouldn't print
anything, so it stood out as unusual.
Print a messsage in the case monster detection fails, to make it
consistent with other fountain effects and ensure it's clear the hero
did still drink from the fountain on that turn. I used "the water
tastes like nothing" for the (sort of tenuous) connection to there being
nothing living on the level, but there might be a better message to put
in there.
Make sure xstart and ystart are always zero when not in_mklev
Running #wizloadlua to run Lua scripts that use coordinates in any way
would work differently if you were on certain levels for the first time
versus leaving and returning to them. This is because various bits of
level creation routines can leave xstart and ystart set to non-zero
values, which are then zeroed at some point when leaving and returning
to the level.
Since xstart and ystart are only relevant to level creation and lua
commands, this fixes the problem by zeroing them after leaving mklev
routines. (Saving them with the level doesn't work because xstart and
ystart are relative to the last used des.map, of which there could be
multiple, e.g. in Asmodeus's level or if two map-based themed rooms
happen to generate. I can envision a more complex solution in which
every des.map used in the level can be associated with an identifier,
whose xstart and ystart are saved for use by later post-level-creation
lua scripts, but currently I just want to make them consistent between
level visits.)
Fix: monster gender could not actually be specified in lua files
Noticed when I tried to create a male monster of a species that permits
both males and females (i.e. not a single-gender or neuter species),
half the time the monster ended up female anyway. This was because
get_table_montype picks a random monster gender for such species, and
lspo_monster just sets it to that, making it impossible to deliberately
have a monster of a certain gender.
This fixes that by defaulting the "female" table argument to random
instead of false, and then checking to see whether the level file set it
to something other than random. If so, it uses that value.
I debated whether this should allow a level designer to make a monster
of a gender that conflicts with their species, such as a male nymph, but
erred on the side of respecting the species. So attempting to specify a
male nymph, etc. will still result in a female one.
I was looking into "The Lord Surtur's corpse" and got side-tracked by
something else: move a priest hack for avoiding "aligned" in a corpse
description from corpse_xname() to obj_pmname(). The old variation
always picked "priest corpse" over "priestess corpse". The new one
will use either one of those if the corpse is flagged as such, or use
"cleric corpse" (avoiding "aligned cleric corpse") if it's flagged as
random.
Hide 'altkeyhandling' from the 'O' menu for !WIN32 builds. If
present in run-time config file it will be parsed and then ignored.
Instead of showing "unknown" for the value of the 'hilite_status'
compound option, show "none" if there are no highlighting rules, or
a pointer to other option "status highlight rules" when there are.
Deal with a few function parameters that are used for some
combination of build-time config settings and unused for others.
Remove redundant 'if (K)' from there_cmd_menu(). The !K case doesn't
get there and that test's presence fools the compiler (oldish clang)
into warning that 'npick' might be used uninitialized.
Change 'O's sub-menu for selecting new msg_window option setting to
work similar to the one for menustyle: show a description of what
the values mean with a two-line, two-column menu entry. Also make
its current value be pre-selected.
msg_window is a bit more complicated than menustyle because only
some interfaces support it and curses only supports two of the four
choices. It currently has one hard-coded reference to "^P" (in the
tty-specific 'combination' choice). Changing that is feasible but
seems like more trouble than it'd be worth.
Implement the suggestion by entrez to avoid "while helpless" in the
reason for the second death if hero gets killed, life-saved, and
killed again at the same time. Life saving sets 'multi' to -1 which
prevents the hero from moving again until next turn and is intended
to make the sequencing of "you survived that attempt on your life"
work if you're being interrupted during some multi-turn activity.
It used to behave differently when the first death occurred while
engaged in some voluntary multi-turn activity. I've removed that
because I couldn't figure out why; it might need to be put back.
Pasi Kallinen [Sat, 2 Apr 2022 15:16:19 +0000 (18:16 +0300)]
Fix stuck travel for good
My fixes to the travel stuck oscillation did not fix all of them,
and I've even seen a 3-step loop - which my fixes cannot detect.
I guess there could be arbitrary-sized loops too.
To definitely fix this, keep track of all the map locations travel
has moved the hero through, and if it tries to go on a location already
used, stop travel and give the unsure -message.
menuitem_invert_test() is intended for invert-all/invert-page/
select-all/select-page but was being called for group accelerators.
In the #wizidentify menu, the 'all' choice specifies ^I as a group
accelerator but that stopped working on tty when it recently became
flagged as skip-invert.
Use 'fuzzymatch(,," -",)' when checking whether the name specified
in a player's wish text matches an artifact name so that extra or
omitted spaces and dashes are ignored. Wishing for "firebrand" will
yield "Fire Brand" and "demon bane" will yield "Demonbane".
"The glob of <type> dissippates completely" was misspelled. Instead
of just fixing the spelling, switch to a different term since
dissipate is also being used for gas clouds and globs aren't gaseous.
git issue #717 - avoid putting monsters on scare \
monster and Elbereth unless there's no other choice.
Suggested by NetSysFire, don't create new monsters on top of scrolls
of scare monster. Not mentioned in the suggestion: unless they are
a type of monster that isn't affected by such scrolls. This extends
it to teleport destination too.
Avoid placing a monster on a scroll of scare monster or on engraved
Elbereth if there are other locations available. Only performed for
callers of goodpos() who explicitly request it, which at the moment
are makemon(), rloc(), and enexto().
Also, propagate 'mmflags_nht' to a bunch of places that were left
using long or unsigned for makemon() and goodpos() flags. I didn't
attempt to be systematic about that though.
PatR [Thu, 31 Mar 2022 11:48:26 +0000 (04:48 -0700)]
github issue #715 - losing stoning resistance \
while wielding a cockatrice corpse without gloves
Reported by vultur-cadens: if safely wielding a cockatrice corpse
without gloves due to temporary stoning resistance or wearing yellow
dragon scales/mail, having the resistance be lost to timeout or to
taking off the dragon armor should have turned the hero to stone but
didn't.
Extend the handling for taking off gloves to cover these other two
cases too. The feedback for these deaths is usually too verbose to
fit on the tombstone but does show up in logfile.
PatR [Wed, 30 Mar 2022 21:41:53 +0000 (14:41 -0700)]
github issue #716 - teleporting onto pits
Implement the suggestion by NetSysFire that a levitating of flying
hero won't treat pits and holes as off limits when testing potential
destinations during teleport.
PatR [Wed, 30 Mar 2022 21:11:29 +0000 (14:11 -0700)]
fix #K3564 - obj sanity failure: N globs for N>1
Using #name and picking an item on the floor to be assigned a type
name allowed any of the four types of globs to be named. After
that, wishing for those by the assigned name bypassed the code that
forced the quantity to stay at 1. Asking for "3 foo" could then
produce "3 small globs of gray ooze" which fails obj_sanity() and
issues an impossible warning (which the fuzzer escalates to panic).
The "getobj refactor" patch changed the return value of call_ok().
When it gets used to check whether an object on the floor could have
a type name assigned (rather than as a getobj() callback), the test
that should have rejected the naming attempt accepted it instead.
Update the wishing code to handle globs differently: you can still
specify the relative size via small, medium, large, or very large,
but now you can specify a count either instead or in addition. A
count of more than 1 is used to multiply the created glob's weight,
although it's less likely to be honored as-is when the size is bigger
than small. Quantity is always forced to 1, at a different place in
readobjnam() than previously.
PatR [Tue, 29 Mar 2022 18:24:45 +0000 (11:24 -0700)]
couple of Guidebook bits: autopickup, tile_file
The change in the long-standing default for 'autopickup' warrants
mention in the Guidebook. Also, the X11 interface can switch to
alternate tiles but doesn't use the 'tile_file' option to do so.
In Guidebook.mn, the list of options pads ones shorter than 8
characters with trailing spaces, necessitating quotes. A few longer
ones had such quotes and even trailing spaces. Take those away.
projects / nethack / log