The command name is expected to be short and the menu description is
expected to be short, but use a bigger buffer for the combination of
the two just in case.
In the paranoid_confirm submenu for 'm O', dynamically substitute the
correct key into the description of the 'swim' choice if #reqmenu is
bound to something other than 'm'.
Issue reported by ostrosablin (and mentioned previously but I still
I haven't remembered where): loading a roguesymset removes any utf8
data that has been set up for primary symset. The curses interface
explicitly initializes roguesymset to the default set and if config
file has specified OPTIONS=symset:Enhanced1 (or some other uft8 set
if someone adds such), that stays the active set but no longer gets
rendered with the intended symbols.
I have no idea whether having symset and roguesymset both use uft8
with different symbols and/or colors works at all and if so whether
it will still work after this revision, but this prevents loading one
set with non-utf8 while the other still uses utf8 from clearing out
the cached utf8 data.
Closes#1026
This should pacify the analyzer. get_artifact(obj) expands to code
which checks whether obj is Null. untouchable() knows that it will
always be non-Null so didn't perform any comparable test and the
analyzer complained.
Using get_artifact() before the 'beingworn' assignment instead of
after would just have shifted the complaint to the assignment's use
of obj->owornmask. Adding a test for Null to that expression should
eliminate the complaint but I haven't verified that.
Player reported that a cat which was asleep in a treasure zoo would
catch and eat thrown food, becoming tamed in the process, without
waking up.
Temporary sleep was handled (via checking for !mon->mcanmove) but
indefinite sleep wasn't. Make a monster hit by taming effect (either
magic or thrown food) wake up from indefinite sleep. For temporary
sleep, the remaining duration is cut in half. The timeout isn't
dropped all the way to 0 because a monster with mon->mfrozen set
isn't necessarily asleep. That timeout is shared by timed sleep,
timed paralysis, and busy time when donning armor.
Introduce
OPTIONS=paranoid_confirm:+foo bar
to add the 'foo' and 'bar' bits to any confirmation bits already set and
OPTIONS=paranoid_confirm:-foo bar
to clear the 'foo' and 'bar' bits without changing any others that are
already set. Values '+foo +bar' or '+foo -bar' or '!foo bar' aren't
accepted.
OPTIONS=paranoid_confirm:foo bar
still replaces existing settings with just the specified bits.
OPTIONS=!paranoid_confirm:foo bar
is treated like 'paranoid_confirm:-foo bar', although I'm wondering
whether that was good idea. Negation combined with plus or minus is
rejected.
Replace the handling for 'prayconfirm' to use 'paranoid_confirm:+pray'
and '!prayconfirm' with 'paranoid_confirm:-pray'. Issue a warning
(which is described as "error" but it still works) about it being
deprecated when that out of date boolean is used.
Reorder swim and AutoAll in the paranoid_confirm menu so that the ones
that add a new 'y' question (pray and AutoAll) are together and the
two that change game play (swim and Remove) without asking questions
are together. (The description of swim in its menu entry now mentions
the 'm' prefix and should probably plug in the value instead since it
might be bound to some other key.)
Undefine the macros defined for option.c's use prior to end of file.
An issue from nearly three years ago, reported by Anerag: asking
player whether to really pray isn't paranoid enough because it
accepts 'y' rather than requring "yes".
This changes it to require "yes" followed by <return> or <enter> if
paranoid_confirm:Confirm is also set. (A side-effect of that is
explicit "no<return|enter>" is required instead of just 'n' to
decline--for all the paranoid confirmations, not just for prayer.)
This extension of paranoid:Confirm applies to paranoid:AutoAll too.
A comment asks why paranoid_confirm:pray is different from the other
paranoid questions in the first place. The answer is that when it
isn't set, no confirmation prompt is issued at all. The others all
have y/n confirmation prompts when the corresponding paranoid option
isn't set.
Once upon a time there was a boolean option called 'prayconfirm' that
issued "really pray?" prompt when True. It was added after players
whinged about typing Alt+p when they meant to type Alt+o. When the
more advanced 'paranoid_confirmation' was introduced, paranoid:pray
superseded prayconfirm, but it still only issues a confirmation
prompt where there normally wouldn't be one rather than change an
existing one to require "yes<return|enter>" instead of 'y'.
Closes#303
If confirmation for menustyle:Full 'A' choice is on and player
chooses 'A' but answers no at the "Really autoselect All?" prompt,
just remove 'A' from the list of choices and act on the rest. If it
was the only choice, the menu operation will behave as if no choices
had been made. (That was the previous behavior even when other
choices were also present.) But when other choices have been made
along with 'A', use them without 'A': the normal second menu will
be put up, listing objects matching the specified classes and not
autoselecting anything.
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.
Use of select-all, select-page, toggle-all, and toggle-page in the
object class selection menu for menustyle:full excluded A (auto-
select all), a (all classes), B, C, U, X (bless/curse states), and
P (recently picked up) but allowed u and x (unpaid and used-up shop
goods) to be set. Treat u and x like the other pseudo-classes;
they have to be chosen explicitly rather than be set with . and ~.
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.
'Fix' fountain.c:598:18: warning: check of 'otmp' for NULL after
already dereferencing it [-Wanalyzer-deref-before-check]
The original code was ok. Either the analyzer has a bug or NONNULL
in extern.h's 'extern struct obj *mkobj(int, boolean) NONNULL;' is
not expanding to the expected value.
This replacement code should be easier to comprehend and with any
luck be simpler to analyze.
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.
If the priest quest artifact Mitre of Holiness (a helm of brilliance,
so crystal helmet) is acquired via the quest (rather than by wishing)
make it start out tempered (aka crackproof|erodeproof).
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).
Noticed while considering the pull request about loosening
restrictions on trap creation at furniture locations. If you wish
for a terrain feature while on a fountain or sink, the counters
used to control whether sounds for those should be given will be
off by one.
It was incrementing the appropriate counter if you wished for a
fountain or sink, but it shouldn't do that if recreating the same
feature (perhaps to reset a magic fountain or looted sink) and it
needed to decrement when replacing either of those with some other
feature. After the count became wrong, if all fountains or sinks
on the level were destroyed, those splashing, gurgling, &c sounds
would continue to be generated periodically.
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.
bhit() updates the value of bhitpos as a zap or missile progresses
and it also maintains a copy in local x,y. But it was using the
latter inconsistently and also used x,y to fetch drawbridge location,
which might retain the same value or might change one of the two
values by +1 or -1. Use different local variables for drawbridege
handling and use x,y instead of bhitpos throughout bhit().
Also, zapping the spot in front of a closed bridge with striking or
force bolt would destroy the bridge even though the zap was just
passing over moat. Don't destroy the bridge in that situation.
Zapping striking/force bolt across the span of an open bridege still
destroys the bridge.
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
Reported by copperwater "on behalf of Maud": when hero hears an
unseen monster read a not-yet-discovered scroll of create monster
and doesn't see any new monster appear, the player is given a chance
to call the scroll something. When hearing an unseen monster read
a not-yet-discovered scroll of teleportation, the label is revealed
but no such 'call it' opportunity is offered, so the player could
deduce which of the two scroll types it was for either case.
Provide an opportunity to supply a 'called' name for scrolls of
teleportation when heard being read, same as with create monster.
Surprisingly complicated to achieve.
Eliminated a couple of goto's in the process.
Fixes#1046
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
files.c: In function 'do_write_config_file':
files.c:2146:66: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
2146 | pline("An error occurred, wrote only partial data (%lu/%lu).",
| ~~^
| |
| long unsigned int
| %u
2147 | wrote, len);
| ~~~~~
| |
| size_t {aka unsigned int}
files.c:2146:70: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Wformat=]
2146 | pline("An error occurred, wrote only partial data (%lu/%lu).",
| ~~^
| |
| long unsigned int
| %u
2147 | wrote, len);
| ~~~
| |
| size_t {aka unsigned int}
author Ray Chason <ray.chason@protonmail.com> 1684372172 -0400
committer nhmall <nhmall@nethack.org> 1685414340 -0400
Add configuration to support Curses on WinGUI
and enable support for Unicode on Curses.
Allow NetHackW to select the Curses interface
Reorder drawing of extended command prompt
Curses on WinGUI needs this change. This may be a bug in PDCursesMod,
but it seems to be harmless to the other ports.
Avoid calling Curses after the windows are closed
Provide erase_char and kill_char for WinGUI Curses
Set Lua version to 5.4.6
Reported by vultur-cadens: if Vlad made it to a level which allowed
bones and was in wolf or bat or cloud form when the hero died, he
would not be excluded from the bones file as intended. When those
bones got loaded in another game, Vlad would become flagged as
extinct. If that happened before his own level was reached, he
wouldn't be created when hero arrived thus there would be no way to
acquire the Candelabrum of Invocation. (Even if his vampshifted
form had been carrying it, it wouldn't be present in the bones data
because it would have been converted into candles.)
Fixes#1038
One recent 'reformatting' change which was more than just source
formatting introduced an unintentional change, turning locomotion
strings from local to mondata.c into global. Make them be local
again.
If an monster hides under and object or under water while in view,
say so.
Also, the sanity check for a hidden eel wasn't consistent with the
hiding criteria for it. An eel can't hide on the Plane of Water even
when it's in the water rather than in an air bubble.
When a hidden pet was relocated via magic whistle, a message was given
about "your <pet> appears" but it didn't show up on the map.
It was being marked as no longer undetected, but that was after rloc()
had moved it and redrawn its location. use_magic_whistle() needed to
redraw its location again after clearing monst->mundetected.
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
Revise the menu that asks whether to run the tutorial so that it will
accept ESC for "no".
Also, in its hint about how to suppress the menu, change vague "the
config file" to the actual configuration file name. (This might need
a new 'sysconf' directive to control what's shown on servers where
the player doesn't have access to the file system, but the vague
description wasn't adequate for single player systems.)
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.
