Make the experimental perm_invent control via TTYINV in player's
environment work for any interface that supports persisntent inventory
(only tested with curses), not just for tty+TTY_PERM_INVENT. The
value is a bitmap but the only combination value that makes any sense
is 3 for tty.
0 - normal
1 - show gold
2 - 'sparse' (list all 52 letters; ones not is use show blank item)
4 - only items in use (approximation of '*' command)
Note that the bits were set up for tty use, and 'normal' for tty is
to hide gold instead of show it. When there's no value for TTYINV in
the environment, the default value is 0 for tty and 1 for others to
retain existing behavior.
Sparse has no effect for non-tty. In-use will display gold even if
the show-gold bit is clear if gold happens to be quivered or wielded.
(That fixes current tty misbehavior.)
Update the menu for the help command to change
"i - using the 'O' command to set options"
to
"i - using the '#optionsfull' or 'm O' command to set options"
(examples assume default key bindings but the actual help menu shows
currently bound keys; the "or 'foo'" part is omitted if #optionsfull
is bound to a key).
dat/opthelp should probably be updated to describe how doset_simple
works since that is different from normal menus and explicitly
contradicts the existing description for boolean settings being
deferred until the menu gets dismissed. Any changes need to make
sense if displayed in the context of picking '?' in #optionsfull.
Maybe a separate help file and separate entry for it in '?' menu?
Pull request from entrez: when the hero breaks a non-empty wand of
sleep and gets hit by the resulting explosion, don't describe it as
"the sleep /ray/ hits you."
Closes#856
When breaking a wand of sleep, don't print the message "the sleep ray
hits you!" since it produces an area effect/explosion rather than a ray.
For a couple other wands, !ordinary (wand breakage) effects don't
produce a message (I assume because the do_break_wand feedback is
considered sufficient), but I put in an alternative message for the
explosion since I think it's important to inform the player the hero has
fallen asleep.
Apply the patch from entrez that makes pet gelatinous cubes who eat
containers engulf rather than digest the contents, like non-tame
g.cubes. Unlike the latter, tame ones will immediately drop the
stuff they just engulfed and might subsequently eat it all anyway.
Inspired by the diff from entrez. I didn't care for 'time'. I don't
like 'novelty' much either, but it is a little more accurate since
there is no time factor involved with just-picked-up.
Show and allow changing the debugging flags in options:
debug_fuzzer: turn on the fuzzer
debug_hunger: prevent hunger
debug_mongen: prevent monster generation
debug_overwrite_stairs: allow level generation overwrite stairs
These are wizard-mode only, cannot be set via config file,
and the fuzzer cannot change these either.
Enabling perm_invent with 'O' ('m O' these days) with curses used to
work but stopped at some point. Analysis by entrez has attributed
the change to the g.program_state.in_docrt flag in docrt(). When
curses creates the perm_invent window for update_inventory(), it
calls docrt() to have nethack redraw the screen.
docrt() -> update_inventory() -> curses_update_inventory() -> ...
-> curs_reset_windows() -> doredraw() -> docrt() [early return]
resulted in room for the persistent inventory window but it was
blank.
This also replaces a couple of doredraw() calls with direct calls to
docrt() (one in code that isn't used). doredraw() implements a user
command; docrt() does the actual redrawing.
Previously monsters used wands of teleportation at hero, if hero was
standing on top of stairs, or on a scary thing (eg. Elbereth or
scroll of scare monster).
Allow monsters to recognize when hero is behind a chokepoint and
monster has friends with them, hopefully teleporting the hero
out of the chokepoint.
Fix the reported problem of a crash when using the curses interface
when examining inventory while carrying only gold, and a blank menu
for tty in the same circumstance. Triggered by changes made for
TTY_PERM_INVENT but doesn't require that to be enabled.
Not fixed: with curses, starting with perm_invent Off and toggling it
On (with sufficient screen real estate to show it) doesn't display it.
Doing something to update it like pickup or drop causes it to appear.
(^R isn't enough.)
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.
