Add options 'showvers' (boolean) and 'versinfo' (numeric mask) to
show nethack's version on the status lines during play. It won't be
particularly interesting to ordinary players but should be useful
when making screenshots or video to be streamed, or for someone who
switches between git branches or between nethack and variants.
I worked on this several months back but it was combined with
unfinished changes to 'hitpointbar'. I've separated it out so that
it can be put into use. When enabled, one or more components of
"<name> <branch> <version>" will be shown right justified after
status conditions. At present the default is "<branch>" if that is
available and overall status isn't 'released', or "<version>" if
'released' or if branch isn't available. That might need some
refinement.
It works as intended for tty and curses, although some abbreviation
mechanism would be useful if/when the program resorts to abbreviating
status conditions to make things narrow enough to fit.
For X11, it works ok for fancy_status:True (the default, controlled
via NetHack.ad settings) but is messed up for tty-style status. The
text is positioned correctly but there are gaps in it, making it
appear garbled, similar to what I saw when I tried and failed to
implement statuslines:3 for X11. [It might be due to having empty
condition widgets be 1 pixel wide instead of being totally removed
but I don't think the situation is that simple.]
For Qt, if the text needs to be truncated in order to fit, the center
portion of the string will be shown, discarding parts from the left
and right. That ought to discard from left and retain rightmost
portion instead.
For win32|mswin|Win GUI, no attempt to support it has been included.
Things should be ok when 'showvers' is left as False (the default)
but I don't know what will happen if that gets toggled to True. At a
minimum, the version info won't be right justified. The information,
or at least some of it, is displayed in the game window's title bar
so there isn't any pressing need to add it to status, but toggling
the option will need to behave sensibly if it doesn't already.
Adds a new extended command #lookaround, which will describe
the map around the hero they can see or remember.
Adds a new boolean option mention_map, which will give a message
when an interesting map location in sight changes.
When makemon was called with all-zero arguments (e.g. for random
monster generation over time), ptr==NULL means "a random monster".
This was being forwarded to mon==NULL in makemon_rnd_goodpos, and
then mtmp==NULL in goodpos, which means "an object, not a monster".
Because objects can be generated under monsters, this meant that an
attempt to create a random monster could end up choosing a location
that already had a monster, which would then cause the monster
generation to fail.
This mostly wasn't noticeable in normal play: it effectively
reduced the monster generation rate depending on how many locations
outside LOS happened to contain a monster. Normally that's a very
small proportion, so the bug had no obvious effects: but when there
are very few locations outside LOS (i.e. the player can see almost
every location on the level), the bug effectively caused monster
generation to stop once those locations became occupied by
non-moving (e.g. hiding) monsters, something that became observable
in games where the player decided to dig out and light almost an
entire level.
This commit fixes the problem by adding a new flag to goodpos that
requests that it not choose a position that already has a monster.
This bug was diagnosed, and this fix committed, by ais523; but
nhmall wrote almost all of the code implementing the fix.
Add a new boolean option showdamage, if on, outputs a message
like "[HP -2, 14 left]" - several variants have something similar,
but I chose the message based on how eSpeak said it, while keeping
it short.
The menus in nethackw.exe were being spaced according to the vertical
tile size of custom tiles, but the tiles were being rendered in menus
at the default size anyway, resulting in unnecessary gaps between menu
rows.
Use the default size of 16 for the vertical spacing calculation.
Note: Original change is from xNetHack by copperwater <aosdict@gmail.com>,
but this commit comes from HACKEM-MUCHE by Erik Lunna, with
some minor code formatting.
From xNetHack commit a0a6103bea:
'The original goal: nerf item destruction using a method I initially
proposed for SpliceHack, in which the number of items subject to
damage from any single source is limited by the amount of damage the
effect caused. The intent was to be more fair all around and prevent
aggravating situations where, for instance, a chest shock trap zaps
you for 4 damage and immediately ten of your rings and wands blow up.
Problem 1: no easy way to limit the items destroyed without biasing
heavily towards the start of the invent chain. The old code was able
to get away without bias by just indiscriminately destroying
everything eligible with a 1/3 chance. Here, I had to introduce
reservoir sampling in a somewhat more complex form than I've applied
it elsewhere, since there are a pool of potential items.
Problem 2: destroy_item no longer worked remotely like destroy_mitem,
which still destroyed 1/3 of items indiscriminately. Commence the
process of squishing them into one function that handles both the
player and monsters. (Which required making a lot of adjustments to
destroy_one_item, now named maybe_destroy_item, on nits such as
messaging and when to negate damage. An annoying consequence of the
merge is that in the player case, their HP is deducted and they can
be killed directly, but for monsters they need to add up the
destruction damage and return it.)
Unifying destroy_item and destroy_mitem has some advantages: in
addition to the obvious code duplication removal, it ensures monsters
now take the same damage as players for destruction (previously they
took a piddly 1 damage per destroyed item). Now when you hit
something with Mjollnir and their coveted wand of death breaks apart
and explodes, you at least get the satisfaction of knowing they took
the standard amount of damage from it. Monsters also now get
symmetry with players in having extrinsic elemental resistance
protect them from item destruction, and damage negation from item
destruction if they were appropriately resistant.
Problem 3: a lot of callers didn't preserve the "amount of incoming
damage" that this refactor relies on. E.g. if the defender resisted
that element, the local dmg variable would be set to 0. So I had to
do some wrangling with callers to save that original damage
value. The rule of thumb is: all *incoming* damage counts. So that
includes the player's spellcasting bonus if applicable, but not
things like half damage, negation due to resistance, or extra damage
due to being vulnerable to cold/fire.
Then I figured, while I'm here let's get rid of all those silly cases
where destroy_items is called multiple times for various different
object classes, and cut the object class parameter out of it. This
has a few minor effects:
- Places where different object classes previously rolled
independently for destruction to happen at all now roll
once. (Which, by my calculation, generally means less incidences of
destruction - a fire attack now won't have three separate chances
to hit your scrolls, potions, and spellbooks. On the flip side, a
lucky roll will no longer save an entire object class in your
inventory.)
- Callers can no longer specify different probabilities for
destroying different object classes. The only place this was really
used was to call destroy_item with a slightly lower probability on
SPBOOK_CLASS. With the nerf in this commit, less of them ought to
be destroyed anyway.
- A very edge case of where explosion-vs-monster damage was totted up
differently for golems, which could result in differences of a hit
point here or there.
- All object classes being processed in one go means that less items
are destroyed than would be if they were still processed
independently. This is not really visible compared to the old
baseline of just destroying 33% of everything, but would be a
marked difference versus a copy of the game that still called
destroy_items separately for different object classes. To
compensate, I adjusted my planned damage-to-destruction-limit
scaling factor down from 8 to 5.
Not done: merging in ignite_items(), though that would probably be
really easy now.'
Notes from porting from xNetHack:
- It might be necessary to reexamine at all the conditional checks for
calling destroy_items. Because item destruction is much more
restrained and uses the actual damage from an effect, we might now
need to check 'if (!rn2(3))' and similar in all the places item
destruction occurs.
If a termcap entry for ending attributes and color also contains
the code to switch from secondary font back to primary (HE_resets_AS
hack), maybe strip the AS code out of HE (and clear the HE_resets_AS
flag) when setting up DECgraphics. Affects whether nethack sends
extra AS sequences while rendering a run of VT line-drawing chars.
My HE doesn't reset AS so that aspect hasn't been exercized.
When switching back and forth between normal and line-drawing,
defer the switch away from line-drawing if the character will be
rendered the same in both character sets (uppercase letter, digit,
most punctuation). That might just defer the AE, but could skip it
and next AS depending on what characters are written. The cycle
might repeat an arbitrary number of times, avoiding sending many
AS+AE combinations rather than just one.
Both of these optimizations are pretty small but reducing the number
of characters sent from a server to a remote user is worthwhile.
If a punished hero's inventory is empty, have a nymph usually take
off the attached chain and indirectly fix punishment. If hero is
trapped by being chained to a buried iron ball, sometimes take off
the implicit chain and indirectly release hero from the trap.
Monkeys won't do this and nymphs will only do so if there is no
inventory (aside from gold and/or embedded dragon scales which they
aren't allowed to target).
It's a lot simpler than I was expecting when I wrote the TODO about
it recently.
Add the 'dump' argument to the existing '--version' command-line
option to display the magic numbers used when validating save and
bones files for compatibility.
Nothing exciting, just a line of 5 hex values. I was going to also
list the values for however many save and bones files are specified
on the command line but it seems to need more effort than I care to
expend. And I hadn't made up my mind whether that should be done by
nethack, recover, or some new standalone program. [Single line of
relatively raw output is so that they could be compared more easily.]
nethack --version:bad-argument was writing a message to stdout and
then starting play--which immediately overwrites stdout. Have it
quit instead. Player wasn't trying to start a game and quitting is
what it does with --version:good-argument.
Noticed while testing confused #loot: when using 'Q' to populate
quiver, or 'f' when quiver is empty, don't bother asking what to
ready/fire if inventory is empty.
And when inventory isn't empty, don't list '-' as a likely candidate
if quiver is already empty.
'w' behaves differently. '-' is treated as a likely candidate when
already not wielding anything, and even when inventory is completely
empty.
If gold is moved into throne's coffer chest (or added to exchequer
monster's minvent) while quivered by the hero, it wasn't being unworn
to remove it from quiver slot. That could lead to a crash. Example
was segfault during 'f' command.
freeinv() expects caller to unwear item being removed from inventory;
reverse_loot() wasn't doing so.
Reported yesterday as issue #1207 by elunna and over four years ago
in #H9430: monsters in gas clouds that should be shown by Warning
aren't. And in some discussion of #H9430 back then: monsters
adjacent to the hero while in gas clouds aren't shown on the map,
but combat and other interaction describes them as if they were.
There have been changes since then--to prevent seeing things on the
far side of gas clouds as if there were no clouds in the way--but
the basic problems with warning and adjacency weren't addressed.
This is a band-aid (tm) that probably makes things livable. Don't
allow gas region display to override monsters that are sensed via
warning or when the hero is next to them. That part doesn't work
correctly if the hero isn't blind and is inside the cloud while the
monster is adjacent but outside. I think it will take more than a
band-aid to deal with that sensibly.
Closes#1207
Compile-time option SELF_RECOVER was implemented for Windows;
add it to unix systems too, with it being on by default when
compiling with the linux hints file.
Reported by elunna: a poison gas breath attack that was reflected
by the target still left that target enveloped in a poison gas cloud.
This makes the gas trail not extend to the target if the attack hits
and is reflected. But if the attack misses then the cloud does reach
the target, which seems weird to me. However, being in the cloud is
a separate event that isn't deterred by reflection.
Closes#1204
add CRASHREPORT for Windows
add ^P info to report (via DUMPLOG)
new options: crash_email, crash_name, crash_urlmax
new game command: #bugreport
new config option: CRASHREPORT_EXEC_NOSTDERR
new command line option: --bidshow
deleted helper scripts:
NetHackCrashReport.Javascript
nhcrashreport.lua
misc:
update CRASHREPORTURL (will need to be updated before release)
update bitrot in winchain
winchain for Windows
add missing synch_wait for NetHackW --showpaths
add PANICTRACE (and CRASHREPORT) in mdlib.c:build_opts
missing:
packaging (Windows needs the pdb file)
no testing with MSVC command line build
port status:
linux: working, but glibc's backtrace doesn't show static functions
Windows VS: working. pdb file is large - looking into options
MacOS: working
msdos: not supported
VMS: not supported
MSVC: planned, but not attempted
MSYS2: working, but libbacktrace not showing symbols (yet?)
Three months ago to prevent an "object lost" panic situation when
stealing an item that let hero survive water (several candidates)
would result in drowning, remove_worn_item() was changed to flag the
item being removed as in_use and emergency_disrobe() was changed to
avoid dropping in_use items while drowning. That seemed to work ok.
But for lava instead of water, in_use is a flag to destroy the item
(set in advance, before issuing messages that can give the player a
chance to trigger a hangup save). So instead of keeping the item
around for theft to finish, it was deallocating it. steal() would
format the freed object and then access some of its fields, leading
to havoc.
This adds a hack to allow one item already flagged as in_use to be
treated differently by lava_effects() from the ones it flags for
destruction. This also seems to work ok, but we may need to start
putting freed items on a deferred deallocation list similar to how
dead monsters are kept around for the rest of the current move.
The fix/hack has revealed two more bugs that this doesn't address.
An item being stolen is removed without any message, then if that
removal doesn't kill the hero a theft message is given. The message
sequencing is wrong. Flying hero who loses amulet of flying just
gets affected by lava; player is only told why after life saving.
The other issue is that life-saving from lava can teleport the hero
to where the thief can no longer be seen, yielding "It steals <item>"
even though "It" was visible when the theft started.
For tty, if ^C interrupt occurred while the terminal was displaying
VT line drawing characters, it wouldn't finish updating the map and
switch back to regular characters, so the "Really quit?" prompt was
illegible.
Rather than muck about with the signal handler, just add a fixup to
tty_putstr() since prompting ultimately uses putstr(WIN_MESSAGE).
Reproducing the situation isn't straightforward; I didn't even try.
Reported directly to dev-team: vapor cloud dissipation didn't always
update vision properly.
Region removal affecting visibility needs to make two passes, the
first unblocking all no longer blocked spots, then the second deciding
whether spots are visible.
Attempting to do that in one pass was doing
| unblock <x1,y1>
| if cansee <x1,y1> whatever
| unblock <x2,y2>
| if cansee <x2,y2> whatever
and the cansee <x1,y1> test wasn't accurate if <x2,y2> blocked it and
hadn't been unblocked yet.
Testing with steam didn't seem to trigger the problem but with poison
vapor trail from green dragon breath did. The order of evaporation
mattered too; sometimes the single pass unblocking plus vision-testing
worked ok by coincidence.
The recent acurr() changes introduced a bug that caused Str less
than 25 to be limited to 18/07. 25 was treated correctly as a
special case but 18/01 through 18/100 and 19 through 24 were not.
The cap of 25 imposed on the other characteristics is the same as
encoded Str 18/07.
Previously reported via github pull request #1188 as an out of bounds
access to u.uhpinc[], followed by issue #1189 when it was closed, the
backtrace accompanying new assertion failure provided more information
that led to figuring out the problem.
Only mattered for the debug fuzzer; wouldn't happen in regular play.
When the hero dies during fuzzing, the fuzzer sometimes restores lost
levels via blessed potion of restore ability. If that happened to a
hero who died by being life-drained while at level 1 then losexp()'s
assumption that life-saved hero was still level 1 got violated. If
levels had been lost all the way down from a peak of 30, restoration
to u.ulevel==30 resulted in invalid array indexing into u.uhpinc[],
then failure of 'assert(u.ulevel >= 0 && u.ulevel < MAXULEV)' which
was added to avoid that.
Pull request #1188 and issue #1189 are already closed, but they hadn't
actually been solved yet.
Fixes#1188Fixes#1189
+/-N for charged rings with known enchantment was clobbering the
BUC formatting that had occurred earlier. #K4088 thought it was a
problem with the implicit_cursed option; followup #K4089 from same
user correctly pointed out that the problem was present for any BUC
state.
This is the same line of code that inadvertently omitted the space
between +/-N and "ring of <type>". That was fixed by commit
1a2b2a8cae a couple of days ago.
While in doname(), fix a potential issue calling corpse_xname().
That assigns a new value to gx.xnamep, clobbering the value that
doname() relied on when it was first called (but doesn't look at
again, so doesn't matter now but could conceivably in the future).
Changing the quantity to 2 (50:50 chance) when creating a potion of
healing (also 50:50 chance for each attempt) to place inside a supply
chest wasn't updating the potion stack's weight, resulting in the odd
encumbrance behavior that was reported last December.
Taking the stack out of the container doesn't fix the weight but
drinking one of the potions splits the stack of 2 into two stacks
of 1 and does update the weight for both. That gives the hero higher
encumbrance when the formerly weightless one has its proper weight.
Finishing drinking the potion uses it up, removing second potion's
weight again. When below an encumbrance threshold by the weight of
one potion or less, player will see encumbrance increase and then
decrease, with healing message given before both due to sequencing.
Supply chests weren't having their own weight updated when they were
populated, so would behave as if empty if hero carried them around.
Removing something, breaking something by kicking the chest, or adding
something would update its weight to match its contents.
I also noticed a refutation (or should that be rebuttable?) to my own
remarks in this:
| commit cd91d0630b
| Author: PatR <rankin@nethack.org>
| Date: Sat Dec 30 17:10:39 2023 -0800
|
| github issue #1180 - humans and murder
|
| Issue reported by Umbire: reviving a human corpse into a human
| monster and then killing it entails murder penalty even when it is
| hostile.
|
| This is probably a non-issue. Human monsters tend to not leave
| human corpses, they leave shopkeeper corpses or sergeant corpses
[...]
Dead fake hero corpses placed at trap locations on early levels are
leaving plain human|dwarf|elf|gnome|orc corpses rather than fake
player monster ones (which are always human but resurrect as player
monsters rather than as plain humans), so there are more plain human
corpses now than there were in 3.6.x or early to-be-3.7. I've added
a comment about the situation.
If your inventory is full and you aren't already carrying a loadstone,
you can pick one up into the overflow slot. But if you are already
carrying one and the one you're trying to pick up won't merge with it
(only criterium that matters would be BUC state, I think), you can't
pick it up and get a message saying so. If loadstone isn't known
yet, the message always referred to it as "gray stone" rather than
"stone called <whatever-you-called-it>".
PR #1140 added checking the thrown, stolen, and dropped flags of an
item when testing whether it would merge (at my suggestion...) with
a stack in the target list (hero's invent). That interferred with
picking it back up--whether via autopickup or explicit pickup--while
inventory was full even when the item would otherwise be mergable.
There was some trial and error involved when trying to figure where
to put the fix but things seem to be working.
This replaces a static analyzer workaround and could possibly bring
its unwarranted complaint back.
"blue potion" wasn't a very good example for an item in a container;
plain "blue" isn't a potion description.
Add an extra sentence to make the association between a container's
"item count" that's really a stack count and the fact that inventory
slots are for stacks rather than for individual items too.
Style/usage bit: avoid using "another" twice in the same sentence.
Fix a typo in the spelling of "contents".
If a covetous monster tried to teleport adjacent to the hero but the
level was too full to move it from its current spot, it would be
sent off level to wait for the hero to leave and return instead just
staying put.
Issue reported by chappg: if a monster or object covered an engraving,
examining that monster or object with farlook would include the text
of the engraving even though it wasn't the thing being examined.
The report was for a bones level but that only mattered because it was
a ghost on top of a grave (and the engraving on its headstone) that was
being examined; bones data itself wasn't pertinent. It would happen
with any engraving once the spot was mapped as an engraving or a grave
provided that something else was currently displayed at the location.
Bug was introduced by commit 389f03e90e
two months ago. Mea culpa.
Closes#1200
