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.
'uskin' isn't part of worn[] so wasn't being checked with the other
slot pointers. Add that, although it'll be excluded by default and
need to have EXTRA_SANITY_CHECKS defined to include it.
Default to INTERNET_AVAILABLE=Y. If the build computer is not
online with the internet available, an explicit
INTERNET_AVAILABLE=N
will be required for the build, if pdcurses and Lua are not already
staged in the lib folder. That can be done by editing the appropriate line
in the Makefile, or by altering the command line:
nmake INTERNET_AVAILABLE=N install
With Makefile.nmake:
Store pdcurses wingui and pdcurses wincon object files in separate
directories.
Rename the two pdcurses static libraries.
Because of the static library changes, the following will be required
prior to the next build:
nmake spotless
Check the various uarm, uwep, and so forth pointers to make sure that
they point to items in hero's inventory and that those items have the
corresponding W_ARM, W_WEP, &c bit set in their owornmask field.
Also check whether any other items in inventory have the same bit set.
[Some of this is already handled by sanity_check_worn() in mkobj.c.]
Also validate two-weapon combat mode. I don't recall ever seeing any
problems reported about it though.
Does not validate ball and chain. Those should have their own sanity
checks that validate a bunch of other stuff besides just worn slots.
They already get some checking by the normal object tests.
This works ok with 'sanity_check' set and items worn and wielded
normally. The only insane situation tested was by reverting the
confused-looting-with-quivered-gold fix from earlier today. I haven't
used a debugger to force other such problems so this isn't very
thoroughly tested.
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.
lava_effects() item destrunction had the logic for handling Book of
the Dead wrong. (However, that didn't matter since the obj_resists()
check earlier would prevent it from being burned up. Fix it anyway.)
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.
If any part of a long worm is within a posion gas cloud region,
include it just once no matter how many segments are inside. The
tail will take harm from poison gas, but only once rather than for
repeated for every segment inside the region.
Unlike with detection, show long worm tail if hero is adjacent to
it in a gas cloud region and would see that tail segment if the
region wasn't inhibiting visibility.
I've been building tty-only for a while in order to speed up
builds, so a recent change to the curses interface that broke
compile on older OSX went unnoticed. The <curses.h> on my
OSX 10.11.6 system does not define A_ITALIC.
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?)
The try count of 1000 is never going to be reached.
The obj result, if it were ever to be reached, would have
been unfiltered and potentially incorrect.
There is no harm in having the result, in that theoretical edge
case, not be one of the obj values that was intended to be
filtered out.
No practical change results from this, and pancake was used
because it is innocuous.
Teleporting due to loss of protection against water or lava isn't
the only way a visible thief might produce "It stole <item>" prior
to the fixup the comment explains.
The late comment about uball and uchain becoming Null was there to
explain why they weren't referenced when inserting the phrase
| (was_punished && !Punished) ? " removed your chain and" : "",
into "<Mon> stole a heavy iron ball." That isn't there anymore so
get rid of the comment.
curses_yn_function() was returning a value that wasn't in the
subset of legal return values. This fixes that.
The unexpected return value of 32 (or space) then brought to
light an indexing error in the core that's been there a while,
apparently since at least 3.2.0, and that caused a null pointer
dereference in a strlen() call, which is what actually caused
the crash in issue #1205. This fixes that too.
Close#1205
My recent change to petattr caused a crash in curses when no
petattr was used in config file - because curses was setting
petattr to curses-specific value. Init the setting in core
instead.
Yesterday's commit to add a "<Mon> takes off <item>" during theft
of a worn item used uchain instead of uball when the item was uball.
That works as intended when uball is just carried, but if it is also
wielded, alt-wielded, or quivered then the pointers for those weapon
slots weren't updated (because uchain doesn't have the corresponding
owornmask bits set when removal performs unpunish()). Check for that
and call remove_worn_item() again if necessary.
Also, the subsequent "<Mon|She> stole <item>" message was inserting
"removed the chain and" before "stole" when item is uball, but that
isn't needed anymore since the preface message "<Mon> takes off the
iron chain (attached to you)" will have just been given.
When a nymph or monkey successfully steals a worn item from hero,
first the item is unworn, side-effects of that take place (most
noticeably descending when losing levitation or flight) including
feedback about such side-effects, finally "<Mon> steals <item>" and
transfer from invent to thief's minvent. If the side-effects were
fatal (such as drowning or burning up in lava), the player wouldn't
see any explanation for why that happened.
When a thief removes a worn item, give a message to that effect:
"<Mon> takes off your <item>." That will usually be immediately
followed by "She stole <item>." When the thief isn't a nymph or if
any messages were delivered after the "takes off" one, the monster
will be described by name: "<Mon> stole <item>."
- fix stack imbalances
- call panic() instead of nhl_error() if L==0 to prevent immediate crash
- drop unused argument prep in get_nh_lua_variables
- change nhl_pcall_handle to clean up stack after calling impossible()
- don't force full garbage collection runs
- don't collect garbage to do memory usage checking
- remove unnecessary stack resets
Having an item that allowed being in/on water/lava be stolen could
result in the hero teleporting. If the thief wasn't visible from
hero's new location, the message given was "It stole <whatever>."
Save the thief's name/description before removing the item and
potentially dropping hero into trouble and triggering teleport, then
use that in the eventual message.
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.
Lembas wafers give more than normal nutrition for elves and less than
normal for orcs. Cram rations give more that nomral for dwarves. The
way that was implemented affected the weight of those items, at least
after they were partly eaten. Polymorphing to or from any of the
affected races resulted in inconsistent partly eaten food.
Change how the nutritional bonus or penalty is applied so that there
isn't any affect on item weight.
I haven't incremented EDITLEVEL, so any wafers/rations with incorrect
weight in existing save files will continue to have that wrong weight.
I suppose that it matters more for bones files but even they should be
ok living with this instead of being forced to be thrown away.
merge_choice() doesn't need the address of its list argument, just to
return Null if that list is Null. Could have been solved by having
its callers check for Null invent and skip the call if necessary but
this is simpler.
Finishes reverting commit 378648bd9c.
This reverts commit 378648bd9c.
The problem was triggered by marking the 'objlist' argument in
merge_choice() prototype with __attribute__((nonnull)) when it
shouldn't have been, then a followup which relied on that. The
'objlist' argument might be Null. Instead of passing its address to
force it to be non-Null, remove the attribute.
