Issue most recently reported by Xdminsy (previously reported by
others): it is too easy to accidentally pick choice 'A' in object
class selection menus for menustyle:Full. Previous change relevant
to this was to exclude choices 'A' and 'a' from being set by '.'
(choose all entries) and '~' (toggle all entries). That was an
improvement but doesn't help with pressing shift when meaning to
type 'a' by those who type faster than they cogitate.
This implements a suggestion by janne-hmp: add new choice for the
paranoid_confirmation option, 'Autoall' (synonym 'Autoselect-all').
If the player sets this and includes 'A' among the choices for
class selection, prompt to confirm whether to honor it. Like
confirmation for praying, it adds an extra y/n prompt rather than
change an existing y/n prompt into a yes/n or yes/no one. If the
player declines, then nothing is selected and the operation is
cancelled rather than putting the menu back up to choose again.
OPTIONS=paranoid_confirm:autoall requires at least two letters
('au') even if the 'a' is capitalized. paranoid_confirm:a means
confirm attacking peaceful monsters. And it should be
OPTIONS=paranoid_confirm:autoall pray swim
if someone just wants to add autoall to the default paranoid bits.
The Guidebook hasn't been updated to describe the new choice since
it seems likely that it might undergo adjustments.
Closes#1065
While running the tutorial, the Save command is disabled. When the
tutorial was extended to two levels, stashing and restoring the
hero's equipment stopped working as intended if player entered the
second level. The attempted fix for that broke re-enabling Save
even if the player left the tutorial without entering its second
level.
This seems to fix things, but I'm flailing around with barely a clue
here. A couple of simpler attempts didn't work and I haven't figured
out why, so this is a bit more complex than what I wanted.
Reorganizing nhl_callback() isn't part of the fix, just avoids use
of some redundant code.
gcc-13.1 static analyzer complains that alloc() returns long *
without guaranteeing to allocate an integral number of longs. Fix
by rounding the requested amount up to the next long when dividing
the amount by 'sizeof (long)' yields a remainder. Surprisingly--to
me, at least--the analyzer recognizes that this extra argument
manipulation will always produce a viable amount no matter what
alloc()'s caller passes in.
Also, the declarations for alloc() and re_alloc() in alloc.c didn't
match the ones in global.h for the MONITOR_HEAP config. I guess
nobody has tested that since NONNULL got introduced.
A year ago the two FITSxxx routines were moved from hacklib.c to
alloc.c so that they could easily be linked into various programs
instead of being replicated in each, but the declarations for them
weren't moved from hacklib.c section in extern.h to alloc.c one.
Noticed when testing erodeproof Mitre of Holiness: the cloud of
stinking gas released by Nalzok when he died ending up killing my pet
and my hero got blamed for that. Don't blame--or credit--the hero for
monsters affected by the gas cloud when a dying nemesis produces such.
Reported by Umbire: if a statue of a hider-under was activated by
a statue trap, it would hide underneath its own statue. Also, the
hero saw a snake hide under unseen submerged kelp.
Both of those things were exposed by new "you see <monster> hide"
message rather than caused by it. It also led to the [re-]discovery
that an existing monster hiding under a statue that was a not-yet-
triggered trap prevented the trap from producing a monster.
This redoes yesterday's can't-hide-under-statue change: hiders can
hide under statues again, but they can't hide under anything at trap
locations. [Pits containing one or more objects are an exception,
although it seems silly that a hero is prevented from falling into
one by the presence of a tiny creepy-crawly hiding under a ring or
dart in there.] So, hider-underers won't be able to interfere with
statue traps by being present at the trap location. [Trappers and
lurkers-above probably need a similar restriction; I didn't look.
They avoid trap spots rather than get lured to such by objects.]
It also prevents newly created hider-underers from becoming hidden
as part of the their creation (except when that creation is part
of level creation) whether their creation uses up an object (statue
activation, egg hatching) or there are simply other items present.
That will prevent statue of a hider producing a monster that hides
under the activated statue (which was happening due to the sequence
create monster, transfer any statue contents to monster inventory,
destroy statue).
The can't-hide-under-statues code has been repurposed to prevent
hiding under gold pieces unless there are at least 10 (arbitrary
threshold) of those or they're in a pile with some other object(s).
Sea monsters hide in water regardless of the presence of objects.
Prevent other swimmers from hiding under objects at water locations.
Such creatures don't have gills and shouldn't be able to stay
submerged in hiding for an arbitrary length of time. [No exception
is made for non-breathers. The overlap between swimmers and hider-
underers is limited to small snakes, even though it is feasible for
a creature wearing an amulet of magical breathing to polymorph into
one. Heros don't spend enough time underwater to worry about snakes
hiding under kelp or thrown junk.]
Lastly, alter the "suddenly, you notice a <monster>" message if
monster-vs-monster activity causes one you've just seen going into
hiding comes back out again without any intervening messages. [I'm
not sure whether something similar is needed for the "Wait. There's
something there" message in the you-vs-monster case.]
Fixes#1062
Unlike ground clutter, statues are typically in pretty tight contact
with the ground; statue traps are sometimes proclaimed as "monsters
posing as statues".
Issue reported by loggersviii: dipping a container into an uncursed
potion of water mentions water getting into the container. That
happens even when that type of potion hasn't been discovered yet.
Make POT_WATER become discovered if this occurs. Doesn't apply when
hallucinating where a random liquid is mentioned instead of water.
Fixes#1061
Instead of a 5% chance for crystal plate mail or crystal helmet to
break each time it's subjected to breakage, switch to a 10% chance
but the damage is treated as erosion rather than break/don't-break.
'crystal foo' will need to go through four stages of damage before
breaking: cracked crystal foo, very cracked crystal foo, thoroughly
cracked crystal foo, then gone. Crackproof handling is included,
described as tempered crystal foo.
It mostly still applies to throwing and kicking the item. Having
some hits trigger damage might be worthwhile but isn't implemented.
Object creation within lua code probably needs to be updated, and
when the Mitre of Holiness is created in the priest/priestess quest
it should start out as tempered (erodeproof). Perhaps it ought to
be erodeproof regardless of where/how it's created.
Issue reported by vultur-cadens: changing helm of brilliance to
crystal made it stop being classified as "hard helmet" so it gave
less protection against things falling onto the hero's head.
Change the is_metallic() tests used on helmets to new hard_helmet().
Unlike when thrown, crystal helmets don't break when objects fall
on them.
Fixes#1060
Reported five months ago, a save was performed while a mounted hero
was engulfed. Restore issued a warning about the engulfer being
placed on top of the steed (who shouldn't have been on the map).
The report arrived at about the same time as engulfing a riding
hero was changed to force a dismount instead of engulfing both hero
and steed so nothing further was done about it. This changes
restore to not put a steed on the map and then take it off again.
It also attempts to simplify usteed and ustuck handling during save
and restore.
Testing so far indicates that things are still working correctly.
Keep makeplural(body_part(FINGER)) crossed.
Existing save and bones files are invalidated.
This replaces most of commit 0ca2af4d8b
from a couple of days ago with something more robust. That change
actually introduced redundant code that caused fountain and/or sink
count to be off instead of preventing it.
Revise set_levltyp() to update level.flags.nfountains and
level.flags.nsinks if setting the type to or from fountain or sink.
A bunch of places that were setting levl[x][y].typ directly needed
to be revised to use set_levltyp() instead. set_levltyp() itself
hadn't been updated to handle LAVAWALL (to force such to be lit).
We received a report from someone whose build was failing because
of the use of cchar_t and setcchar(). They were getting errors
even though they were using an up-to-date curses library.
Apparently, ncurses requires that _XOPEN_SOURCE_EXTENDED must be
defined before the curses header files in order for those features
to be available.
We had already updated our .370 series of hints and hints/include
files with
-D_XOPEN_SOURCE_EXTENDED=1
but this person must have been building in some other way.
Instead of failing to build in that situation, allow the
fallback to the older, less-functional genl_putmixed() function,
but also try not to do so silently and display a message that
functionality is reduced.
The difference between the use of genl_putmixed() and
curses_putmixed() or tty_putmixed(), is that when doing
'/' farlook operations, curses_putmixed() and tty_putmixed() try to
display a character in the message window that looks exactly the same
as the one on the map, even if a symbol from a symset is being used
on the map, or when using ENHANCED_SYMBOLS.
Related note: curses_putmixed() matches the symbol and the color,
whereas tty_putmixed() (at present) does not attempt to match the
color.
In file included from ../win/curses/cursmisc.c:6:
../win/curses/cursmisc.c: In function 'curses_convert_attr':
../lib/pdcursesmod/curses.h:562:32: warning: overflow in conversion from 'long long unsigned int' to 'int' changes value from '2147483648' to '-2147483648' [-Woverflow]
562 | #define PDC_ATTRIBUTE_BIT( N) ((chtype)1 << (N))
| ^
../lib/pdcursesmod/curses.h:574:27: note: in expansion of macro 'PDC_ATTRIBUTE_BIT'
574 | # define A_DIM PDC_ATTRIBUTE_BIT( PDC_CHARTEXT_BITS + 10)
| ^~~~~~~~~~~~~~~~~
../win/curses/cursmisc.c:752:23: note: in expansion of macro 'A_DIM'
752 | curses_attr = A_DIM;
| ^~~~~
Redo the check for whether a monster is Vlad when deciding whether to
keep it out of a bones file. Use the new check in find_defensive()
where Vlad won't waste a turn attempting to use a wand of digging when
in his undiggable own tower. (Failing to check for vampshifted Vlad
in the latter case wasn't actually a bug because if/when shifted,
he's unable to use items so couldn't attempt to use wand of digging.
Switch to the new check anyway.)
Add a new debugging option, 'montelecontrol', that allows a wizard-
mode player to choose a teleporting monster's destination. If player
picks a bad spot, confirmation will be requested. If accepted, the
spot will be used even though the consequences could be bad; that's
on the player. If rejected, the destination will be assigned as if
no control had been attempted rather than try again.
The fuzzer isn't allowed to override a bad spot if it tries to pick
one. That would probably trigger a sanity_check warning; the fuzzer
causes impossible warnings to behave as if panic, so accepting a bad
spot would just be fuzzer suicide. It is allowed to randomly set the
option and maybe--though extremely unlikely--randomly pick a valid
controlled destination.
The curses interface was using genl_putmixed() which doesn't
preserve the symbol actually used for a glyph on the display.
This is a first-attempt at implementing curses_putmixed().
On Linux you'll need to distribute the Makefiles again
sh sys/unix/setup.sh sys/unix/hints/linux.370
On macOS, you'll need to distribute the Makefiles again
sh sys/unix/setup.sh sys/unix/hints/macOS.370
Replace tests against tutorial_dnum with 'In_tutorial()' predicate.
Give a message when entering the tutorial (via level change mechanism).
Likewise, give a message when resuming regular play.
If player uses #quit or ^C in the tutorial, ask whether to cut the
tutorial short and resume regular play; skip "Really quit?" if the
answer is yes. Behavior is a bit odd for ^C + yes; it just sits there
until player types something.
Reported by Noisytoot: going from level tut-1 to tut-2 returned the
hero's starting equipment too soon, and exiting the tutorial from
tut-2 let the hero keep any equipment acquired within the tutorial.
Entering and leaving the tutorial was being handled by lua code in
the level description of tut-1 and adding a second level messed that
up. I didn't see any way of handing that with level-specific lua
code so I made it become the core's responsibility. gotolevel()
knows when the hero is moving from one dungeon branch to another so
it can recognize entry to or exit from the tutorial easily.
While fixing this, prevent #invoke of the Eye of the Aethiopica from
offering the tutorial as a candidate destination (was feasible if it
had been entered at start of game).
Not fixed: levels visited in the tutorial become part of #overview.
Show location as "Tutorial:1" instead of "Dlvl:1" on status lines.
Only tested with tty; some interfaces handle location themselves and
may need their own fixup for this.
Fixes#1046
The pull request from argrath would have moved the definition of
VDECL from tradstdc.h to vmsconf.h because some out of date references
to it in sys/vms/*.c were the only place it still appeared to be used.
Instead of applying that, remove those old references.
NetHack 3.7.x requires C99 so just remove VDECL since it was present
in order to support pre-ANSI compilers. (There is at least one
comment that still mentions it though.)
This also gets rid of another chunk of tradstdc.h that was allowing
either pre-ANSI or nearly-ANSI compilers to deal with nethack's old
code. I left the USE_STDARG/USE_VARARGS/USE_OLDARGS stuff in place
even though anything supporting C99 shouldn't need that. Some or
all of the [UN]WIDENED_PROTOTYPES stuff is still there too.
Closes#1030
Issue #1042 states the following:
> Steps to reproduce:
> *name pet so that first (or only) character is non-ascii: example Ä or emoji.
> Most of the time the name is correctly shown.
> If new row starts with pet's name then character is not printed correctly.
The kludge for handling mixed glyphs and text shouldn't have been engaging
the special handling of the first character for anything outside of putmixed().
This should resolve that.
Reported by copperwater: entering the tutorial sets 'u.nofollowers',
changing to the tutorial level saves a copy of 'u', post-level change
from entering the tutorial level resets u.followers, but subsequently
changing levels to return to the original level 1 restores 'u' from
the saved copy with has 'u.nofollowers==True', overriding the reset.
Move the nofollowers flag from 'u' to 'iflags'. Invalides save and
bones files.
Fixes#1027
The code to lookup a value in DEBUGFILES usually operates on a file
name, but there are few non-file uses. The latter wouldn't work on
VMS because of the way it was manipulating the name: first stripping
away path, suffix, and version, then adding hardcoded ".c" suffix on.
I thought we already had a routine to get the base part of a name
from a full path, but if so, I haven't been able to find it. This
adds new nh_basename() to do that, with the option of either keeping
or discarding the suffix or type portion.
The VMS usage that prompted this hasn't actually been tested.
Pull request from saltwaterterrapin: record current move's pending
movement points in save file. They were being thrown away during
save and hero given 12 at time of restore. Hero had to have had at
least 12 in order for player to issue the S command, but might have
had more than that if able to move faster than normal speed.
This implements it differently from the suggested commit. Add new
field umovement to 'struct u' instead of using youmonst.movement and
needing to save and restore that separately.
Invalidates existing save and bones files.
Closes#1024
The safe_teleds() change that restored picking random destination
attempts prior to making an exhaustive search contained a typo tjat
accidentally only accepted invalid positions instead of valid ones.
So unless it randomly picked 40 good spots, erroneously rejecting
all of them and then falling back to the try-everywhere situation
(which has its own testing without any typo), it would yield strange
results by placing the hero in walls or solid rock via choosing the
first inappropriate spot it tried.
Not part of that bug but related, sort of: for rloc(), use
rloc_pos_ok() instead of goodpos() during the exhaustive search as
well as during the random tries, but hang on to the first (after
randomization) position that passes goodpos() for a last resort.
The collect_coords() flag for 'skip-inaccessible' intended to be a
quick way to filter out walls and solid rock was using !ACCESSIBLE()
which also rejects water and lava locations. So such spots wouldn't
be picked by either safe_teleds() or rloc() when they were finding
a spot for aquatic or lava-tolerant forms. Instead of duplicating
a bunch of code to decide whether the hero's current form or the
teleporting monster should avoid !ACCESSIBLE() for a reason other
than having Passes_walls, make collect_coords(CC_SKIP_INACCS) use
!ZAP_POS() which rejects walls and rock but allows pools.
Make recently added collect_coords() global even though it is still
only being used in teleport.c.
Add CC_SKIP_INACCS flag to only collect accessible locations so that
there's no need for a custom filter callback or of collecting spots
that will always be rejected when put to use. Caller needs to check
Passes_walls/passes_walls() to decide whether that is suitable.
Merge some of the old safe_teleds() with the new, making it try
randomly 40 times before collecting coordinates for an exhaustive
selection. Prior to the recent change which added collect_coords()
it was trying 400 times and giving up if that didn't find a good spot.
Start using collect_coords() for rloc() as well as for safe_teleds().
Only try to pick a spot randomly 50 times now instead of 1000. If
those all fail, it does an exhaustive search of a randomized list of
candidates instead of old left-to-right, top-to-bottom map traversal.
Has not had nearly as much testing as safe_teleds() underwent.
rloc() was explicilty ignoring map column 1 for some reason. Unlike
reserved column 0, column 1 is part of every level and should be
considered for monster teleport destination even though most levels
don't utilize it.
Replace a couple of hardcoded "back on solid ground" messages with
something more versatile.
Also, make life-saving handling for failed rescue from drowning
similar to that of failed rescue immolation by lava. If there are
any cases where more than two tries is needed, they elude me. The
new code doesn't confer temporary water walking if emergency teleport
fails; perhaps it should.
Get rid of some unnecessary code when ignoring unimplemented buried
monsters. A smart compiler probably optimizes away the useless bits
even when not explicitly optimizing but a dumb one isn't likely to.
m_at(x,y) was
| (levl.monsters[x][y] != 0
| && (levl.monsters[x][y] ? levl.monsters[x][y] : 0))
when
| levl.monsters[x][y]
accomplishes the same thing.
In file included from /opt/X11/include/X11/Xos.h:146:
/opt/X11/include/X11/Xarch.h:44:13: fatal error: 'sys/byteorder.h' file not found
^~~~~~~~~~~~~~~~~
1 error generated.
make[1]: *** [winX.o] Error 1
Xarch.h has an #ifdef SVR4 block.
Make sure CLR_MAX is defined when winprocs.h uses it.
sys/vms/vmsmail.c uses wintypes.h and winprocs.h without hack.h;
a change in 3.6.3 broke that but wasn't noticed until now.
I haven't added a fixes entry since we don't know whether 3.7.x
will eventually be buildable on VMS.
Change dying in lava to attempt life-saving at most twice. The first
time might be via amulet or via declining to die. The second time
can only be via declining to die after failing to teleport to safety
the first time, but could happen in explore mode as well as in wizard
mode, either interactive or fuzzer.
If the hero dies twice without ending the game, confer temporary fire
resistance and water walking so that other actions can be attempted.
After 5 turns without getting away from the lava or doing something
to acquire those capabilities, the hero will be subject to falling in
again.
Then the whole cycle might repeat, even many times, but the fuzzer
will eventually choose ^V or #wizmakemap and escape. Players in
explore mode will either figure out a way to get out of it or
eventually have to give up but can try as many times as they like,
not that much different than being cornered by a deadly monster.
When a monster being attacked was knocked back into a level
teleport trap, the attacker could still hit the defender.
If the second hit then killed the defender, this could result
in dmonsfree warning.
Life-saving from being burned up in lava attempts to teleport the
hero to safely. If that fails, hero immediately burns up again.
For fuzz testing, that results in an infinite loop.
While implementing a fix (in done(), not just lava-specific), I
noticed that hangup while running interactively in explore or
wizard mode could be subject to similar effect.
For the fuzzer, if hero dies 15 times without advancing the move
count (not 'moves', the turn count), don't life-save again. With
hangup, don't prompt for "Die?" more than once.
Normal interactive declining to die still works. The more exotic
situations aren't tested.
Delete engravings made in a breach of a shop's wall or of a vault's
wall or in the guard's temporary corridor when the wall is repaired
or the corridor removed. If 'sanity_check' was On, those would
trigger impossible warning "engraving sanity: illegal surface (x)"
where x was the terrain type code for solid rock or relevant walls.
Adding del_engr_at() calls to the shop code was straightforward.
The vault code is very complicated and I'm not sure that all the
calls I added were actually necessary.
Engraving in an empty doorway and then using locking magic to create
a door there resulted in an impossible warning: "engraving sanity:
illegal surface (23)" if the 'sanity_check' option was On (wizard
mode only). Engraving in an open doorway and then simply closing
the existing door produced the same effect.
Accept engravings at closed doors. Presumably hero will be using
Passes_walls to attempt that so treat closed doors same as open ones.
Update the engraving sanity check to deal with that.
Bonus fix: engraving sanity checking stopped after the first problem
instead of checking every engraving. Have it continue instead.
Not fixed: vault wall repair and temporary corridor removal does
not delete engravings and can trigger the illegal surface warning if
player engraves before the repairs. I didn't test shop wall repair
but it doesn't have any engr references so probably has the same bug.
The #genocided command was revealing extinct monster species when used
during normal play. That was not intended, so stop. Change to only
reveal them in wizard or explore modes and also during end-of-game
disclosure but suppress them during normal play.
The full description of #genocided is now dynamically updated for '# ?'
during normal play to remove its reference to extinctions. Also, check
for skipping wizard mode commands before doing description searching.
\#genocided was out of alphabetical order in the full commands list.
Both it and #vanquished should have had the GENERALCMD flag; they
don't affect game state.
Change #genocided to use the sort order currently set for #vanquished,
and allow 'm #genocided' to put up the same menu as 'm #vanquished'.
(Not quite the same. Sorting by count of monster deaths isn't
appropriate for listing genocides where an arbitrary number may have
been killed before the genocide occurred. If the preferred order for
vanquished is set that way, alphabetical will be used for genocided.)
Setting the order via menu for either command sets the order for both,
but doing so via #genocided doesn't offer the count-high-to-low and
count-low-to-high choices. During disclosure, you can answer 'a' when
asked whether to disclose genocided and extinct monster types and like
for vanquished monsters, that lets you choose an order at end-of-game.
Doing so won't affect disclosing of vanquished monsters--it'll be too
late for them.
A chunk of this diff is due to moving the #wizborn code out of the
middle of #vanquished handling.
Guidebook.ms has been updated but Guidebook.tex is lagging.
Discussed a long time ago, change helm of brilliance from iron to
crystal so that it doesn't need to be a special case for metallic
armor's affect on spell casting. It now has a fixed description of
"crystal helmet" but is not pre-discovered.
Add new helm of caution to retain the "etched helmet" description
among the shuffled helms. Wearing it confers the Warning attribute.
That's fairly lame but not necessarily useless. It's iron and gets
half the former probability for a random piece of armor being helm
of brilliance so is not likely to be popular.
Helm of caution keeps the old helm of brilliance tile and new helm
of brilliance is basically the same image with different color and
pointed on the top.
Not changed: the etched helmet was marked as green and is drawn
that way for text but the tile doesn't actually use green for it.
Crystal helmet started as hi_glass (rendered as 'bright cyan') but
has been changed to clr_white to match crystal plate mail.
Old save and bones files are invalidated.
I was working on this at the time 3.6.0 was released and set it aside
until later. Later has finally arrived. Redo the Blind, Blinded,
Blindfolded,&c macros to make more complete use of intrinsic property
handling. Blinded was being treated as a number which could be added
to or subtracted from; now that has to be done via TIMEOUT mask
because it has FROMOUTSIDE (OPTIONS:blind) and FROMFORM (poly'd into
!haseyes() form) bits included. Object definitions for blindfold and
towel now specify the BLINDED property; overriding blindness via the
Eyes of the Overworld is accomplished via props[BLINDED].blocked.
Code generated for the scores of Blind and !Blind tests throughout
the program should be smaller.
One bug that has been fixed is that putting on the Eyes of the
Overworld cured permanent blindness (from OPTIONS:blind). The
u.uroleplay.blind flag was cleared and stayed so after taking them
off. Putting the Eyes on still breaks blind-from-birth conduct but
now blindness will resume when they are removed.
This was untested at the time it was set aside and is only lightly
tested now. A large number of the changes here are just to switch
from Blinded to BlindedTimeout for current timed value and to call
set_itimeout() for setting a new value.
