Make sure u.uswallow is cleared when u.ustuck gets set to Null so
that they won't be out of sync with each other. Having u.uswallow
be non-zero does imply that u.ustuck is non-Null.
Running #panic while swallowed didn't produce any anomalies for me,
either before or after this change.
Change trappers and lurkers above to remove digestion damage. They
fold themselves around rather than swallow the victim. There were
are lot of places that assumed that an engulfer which is an animal
would swallow and digest the victim. In hindsight, it might have
been simpler to take the M1_ANIMAL flag off of trappers and lurkers
above.
This adds a new digests() predicate for creatures with AT_ENGL+AD_DGST
(purple worm) and also enfolds() for AT_ENGL+AD_WRAP (both 't'-class
critters).
There are several minor fixes mixed in with this. I didn't record
them as I went along but the two I remember are
1) if poly'd into a holder and holding on to a monster, the '<' and
'>' commands refursed to work; release the held creature first
and then treat those commands as normal;
2) throwing a non-weapon while engulfed by an ochre jelly reported
"the <item> vanishes into the ochre jelly's /currents/".
This needs a lot more testing. I found and fixed multiple minor
details before my own testing burned out.
These bugs are currently latent only because no role's starting
inventory happens to satisfy the conditions under which it would show
up. This commit contains the xNetHack fixes for them.
Bug 1: if a role received a specific charged ring (versus a random
ring), it would be possible for that ring's charge to be <= 0, since the
code currently only caught this case for random rings. Move that clause
outside the if (UNDEF_TYP) clause.
Bug 2: non-ring oc_charged items of UNDEF_TYP that randomly rolled a
starting charge/enchantment <= 0 would always be enchanted, sometimes
very highly, because their enchantment was getting set to rne(3) by
hitting this case, which is only intended for rings as a comment
indicates. In particular, Archeologists' starting pick-axe would hit
this case after moving it out of the UNDEF_TYP block, but it would also
apply to any role receiving a random tool or weapon-tool at the start
of the game.
find_skates was still in use for its one intended case, but objdescr_is
has been around for a few years now and can do just as good a job
without having to hardcode the first and last boots in objects[].
Issue reported by GorillaSapiens: you get notified if a lamp burns
out even if you're blind at the time.
That is intended behavior; you can feel the heat or lack of heat
from a lamp or candle. But the comment from copperwater pointed out
that you shouldn't be able to feel that for a brass lantern.
This suppresses the "power has run out" feedback if blind at the
time. However, applying a lantern to turn it on or off still gives
the on/off feedback on the assumption that there's a switch and you
can feel its position. When hero is blind and lantern is out of
power, trying to turn it on yields "nothing seems to happen". It's
not completely consistent since you would feel the switch in its On
position but claiming that the lantern is on would be a lie.
The basic on and off messages referred to "lamp" even when using a
brass lantern. I thought that that had been fixed a long time ago.
Fixes#842
invent.c: In function 'getobj':
invent.c:1579:29: warning: 'cnt' may be used uninitialized [-Wmaybe-uninitialized]
1579 | if (cnt < 1 || otmp->quan <= cnt)
| ~~~~~~~~^~~~~~~~~~~~~~~~~~~~
invent.c:1529:10: note: 'cnt' was declared here
1529 | long cnt;
| ^~~
../win/X11/winstat.c: In function 'update_fancy_status_field':
../win/X11/winstat.c:1920:28: warning: declaration of 'active' shadows a global declaration [-Wshadow]
1920 | static boolean active = FALSE;
| ^~~~~~
In file included from ../include/hack.h:196,
from ../win/X11/winstat.c:36:
../include/wintype.h:180:5: note: shadowed declaration is here
180 | active = 0x001,
| ^~~~~~
... using the same hack when zapping themselves: If the level is
no-teleport, the monster will learn of teleport traps, and if
it knows about them, won't try using teleportation again.
The mind blast code was previously a part of dochug().
This commit pulls that code into its own function, and also
happens to eliminate a goto and label with no change in functionality.
This commit removes the gotos from set_apparxy, making it easier to read.
It also cuts out at 1-2 variable assignments on certain calls,
so technically it is an efficiency win as well.
According to comments in the code, this feature was disabled
because it never triggered, making it useless. I enabled the code
again, and monsters demonstrated a willingness to zap the player
with wands of teleportation. I am not sure of what exactly changed,
but I think this feature could trigger some interesting situations,
and absolutely deserves to make a comeback.
When you steal from a shop, its shopkeeper will remember you as a thief
and charge you higher prices in the future (as well as be more curt and
less polite in interactions with you, though not outright hostile) even
if you pacify them, or die on the level and revisit it later as a bones
file. This was an idea aosdict had, and I think it makes sense that a
shopkeeper doesn't forgive and forget, immediately returning to treating
you exactly like anyone else, just because you were terrorized into
paying her back. Paying a shopkeeper off may cause her to stop actively
attacking you, but it feels like she'd have her eye on you as a known
thief going forward (and maybe would hang up a sign with your picture,
saying something like "DO NOT ACCEPT CHECKS FROM THIS HERO").
This surchage already existed, but since it was tied to active anger
(which typically causes a shopkeeper to quickly abandon their shop to
follow you) it was somewhat rare to see it in action.
I did not implement it here, but one possible further tweak might be to
clear the surcharge if the shopkeeper is pacified via taming magic
(which more-or-less magically brainwashes the target to feel positively
towards the hero) but not if you simply pay your debts.
Whether a trap exists is independent on the underlying terrain type, so
putting a check for traps in a block structured like
| if (IS_ROCK(levl[x][y].typ) || levl[x][y].typ == ROOM)
| ; /* do nothing */
| else if (levl[x][y].typ == CORR)
| do_corridor();
| else if ((trap = t_at(x, y)))
| avoid_trap(trap);
would mean that the check for traps only happens on terrain other than
normal room and corridor spots. As a result, it wasn't being evaluated
in most places where traps might actually occur.
Move the test for traps outside of the terrain type evaluation if/else
series, so that it happens independent of terrain (and remove the
'continue' so it doesn't preclue evaluation of the terrain).
Once the rule actually started coming into play, it became clear the
avoid_moving_on_trap message was being printed in cases where the hero
didn't actually stop (i.e. shift-dir runmode, the "if you must" case),
so I also modified the value for that parameter so it will match the
situations where the hero stops running.
The refactor of domove made it impossible to run onto a trap (or water,
if blind), even in the shift-dir mode where the hero is meant to stop
only upon "hitting a wall or running into something". I use this
runmode to sprint large distances across the map, and the change to this
behavior meant that it was no longer possible to press shift-dir again
to continue past the trap. This restores the old behavior of allowing
shift-dir running to carry you onto a trap (though the hero will still
stop before hitting a trap in less breakneck runmodes).
The dark_room option determines whether remembered but unseen waslit
corridor spaces are displayed with S_litcorr or not. When it is
disabled, a remembered permanently-lit corridor spot will be shown
as "lit corridor" when out of sight. When it is enabled,
corridors are only shown as lit if they are currently in view.
Toggling this option was not immediately refreshing how corridors on the
map were displayed: an unseen spot shown as a lit corridor because
dark_room was disabled would continue to be shown as a lit corridor
when it was toggled on, until the hero's memory was refreshed by
visiting the spot and then leaving.
Slightly extend the existing function for updating how room spaces are
displayed when dark_room is toggled so that it will update the glyph
used for unseen lit corridors in a similar way.
Because back_to_glyph assumes the hero can directly see the spot, when
used for #terrain (e.g. when a spot was covered by a remembered object)
it would display corridors as lit if lit_corridor was enabled. Instead
of trying to suppress back_to_glyph's S_litcorr result only under
circumstances where it would be unusual, just show all corridor spots
with S_corr, so that none of them appear as "lit corridor". This
is consistent with what is already done for room spots for #terrain
(S_darkroom is forced to the basic S_room across the board).
You can create steam clouds that are gray and deal 0 damage when zapping
fire at or over water sources. If you happen to be in the cloud, it
produced the "You are enveloped in a cloud of noxious gas!" line, and
steam isn't noxious.
Other uses of "gas cloud" could have potentially been changed, but I
left them alone.
Members of the watch can never be bribed, no matter how much gold is
thrown at them, but when a bribe was attempted they would say "that's
not enough" (implying incorrectly some higher amount would be enough to
pacify them). Also, an already-peaceful mercenary would take on an
unusually aggressive tone when given any amount of gold, giving the
player the same message to "beat it" as when a bribe succeeds in
pacifying them.
Adjust the mercenary bribery code a bit so that a more friendly message
is given if the monster is already peaceful, and so that unbribeable
monsters don't imply they are just not being given enough gold. I think
the actual effects of bribery shouldn't be affected by this commit, just
the messages/feedback.
Suggested by aosdict: instead of describing all gulp attacks as
"engulfing you", say "The <monster> swallows you whole" for purple worms
(or any other animal engulfer) to visibly differentiate between
engulfing and swallowing.
Using #loot with the 'm' prefix would claim there was nothing to loot
even if the hero was standing on a box, as long as there was no adjacent
monster. 'm' prefix is an explicit request to select a direction so
make it work regardless of whether a monster is there. Once I did that
I noticed that it was providing no feedback for using '.' or '>' as the
direction if no container was available, so adjust that to give the
"there is nothing here to loot" feedback.
The monster knockback could mess with the monster linked list while
the code was going through it for monster movements. (For example,
a monster knocked back another into a level teleport trap)
Add iter_mons_safe, which first grabs all the monster pointers in
the list into an array, and goes over that array instead of relying
on the "next monster" pointer. This is possible because dead monsters
are not removed from the linked list until after all the monsters
have moved.
Testing is very minimal, and I'm not sure the vault guard check
for migration is correct - it should probably check for more states?
Also the iterator could be improved by not continually allocating
and freeing the monster pointer array.
Reported by copperwater: if an engulfer swallowed a mounted hero,
odd things could happen if the hero dismounted. The steed would be
silently expelled and float-down flooreffects were attempted.
It turns out that if the engulfer is classified as an animal (so
purple worm, lurker above, trapper), the hero got "plucked from
<steed>'s saddle" and was forcibly dismounted prior to completing
the engulf operation, but non-animals (vortices, air elemental,
ocher jelly, Juiblex) swallowed the hero+steed intact. The most
straightforward fix to dismounting-while-engulfed issues is to change
engulfing to always pluck the hero from the saddle even when the
engulfer isn't an animal.
If there's no room on the level to place the former steed, it gets
killed off. I looked at changing that to put the steed into limbo,
waiting to migrate back to the current level if hero leaves and
subsequently returns, but that breaks movemon()'s assumption that
when monsters are in the process of moving, only the currently moving
one can be taken off the fmon list to be placed on migrating_mons.
[The recently added monster knockback code violates that assumption
too when knocking the victim into a level changer trap. It needs to
be fixed in one fashion or another.]
This replaces the old pushq/saveq arrays (which were used to save
the keys pressed by the user for repeating a previous command)
with a new command queue. This means there's no hard-coded limit
to the saved keys, and it can repeat extended commands which are
not bound to any key.
Using #loot while in a pit allows looting containers in that pit.
Using open and specifying the hero's spot when not in a pit allows
looting containers at hero's spot. But using open while in a pit
complained about not being able to reach out of the pit before player
had a chance to give hero's spot at the place of interest, so did not
allow looting any container there.
Get a target spot before rejecting use of 'open' while in a pit.
The alternate prompt might be tty-centric.
Make monsters with magic and gaze attacks avoid hero,
just like spitters and breathers already did.
Some small code cleanup related to the ranged attacks.
Entering a count to repeat an action stopped working for counts greater
than 2 after 93db2a8: the unconditional call to reset_cmd_vars at the
top of rhack was resetting many more variables than had previously been
cleared at that point, including g.multi (which in this context tracks
how many more times the requested action should be repeated). As a
result any count would perform the requested action twice at most.
Reduce the list of variables zeroed out at the start of rhack back to
what it was before 93db2a8.
M-<key> shortcuts with altmeta enabled weren't working when preceded by
a count (e.g. 2 M-j for "jump twice"): g.program_state.getting_a_command
determined whether <esc> should be read as staring a potential meta key
combination, and was being reset by readchar on the first digit entered
without being reactivated for subsequent input. As a result, by the
time the player entered the actual command to be modified by the count,
readchar wasn't bothering to look for M-<key> sequences.
Hitting a monster with a wielded potion of paralysis or sleep
was practically useless, because it almost always also hit you.
Negate the chance and make it depend on your dex.
The earlier commit just removed monsters from migrating_mons and left
them orphaned. Also it ignored migrating objects.
Actually release the monsters that can no longer arrive at their
migration destinations. Release their inventories too.
Release objects that can no longer arrive at migration destinations.
The earlier attempt to prevent the Wizard from immediately teleporting
(and giving a vanishes and reappears message before the player has had
a chance to see the level) when you arrive on the Plane of Earth ended
up being worse. He just stayed put, so no vanish and reappear but no
other activity either.
When the hero enters the planes branch, all the rest of the dungeon
gets discarded since it can no longer be reached. At the time that
that takes place, throw away any migrating monsters waiting to arrive
on any of those levels.
When entering the Plane of Earth (or level teleporting directly to
another endgame level in wizard mode), if the Wizard came off the
migrating_mons list instead being re-created from scratch, he would
be placed randomly on the level instead of next to the arrival point.
If his mstrategy field still had the STRAT_WAITFORU bit set and you
didn't move to where he could see you, he might never come after you,
at least until some future harassment event chose 'resurrect'.
