Issue reported by youkan700: for shopkeepers, taming via magic harp
behaved differently than taming via scroll or spell.
Make magic harp's taming be the same as [non-cursed] scroll of taming
and spell of charm monster: angry shopkeepers will be pacified (even
though they can't be tamed).
Also, add something I've been sitting on for ages: when taming magic
hits an already tame monster, give that monster a chance to become
tamer. Not significant for monsters that eat (unless being starved
for some reason) but matters for ones who don't eat. For tameness N
(which has a maximum of 20), if N is less than 10, have any taming
yield a 10-N out of 10 chance to increase the tameness by 1. So the
closer a pet is to becoming feral, the more likely for it to improve
tameness a little.
Check for the possibility of dead monsters on fmon when removing
everything from fmon. Mustn't pass a pending dead monster to
mongone() and get rid of it twice.
Michael Meyer [Sat, 16 Jul 2022 04:15:29 +0000 (00:15 -0400)]
Silence some -Wunused-but-set-variable warnings
If NH_DEVEL_STATUS was set to NH_STATUS_RELEASED or NetHack was compiled
without DEBUG defined, the 'vlen' variable in a couple pline.c functions
wasn't used. This could trigger compiler warnings.
Issue from youkan700: a previously undiscovered pit was being made
known before hero poly'd into clinging monster checked whether it was
already known. So it always gave "you see a pit below you" instead
of "a pit opens up under you!" combined with "you don't fall in!".
(I think those exclamations are excessive but haven't touched them.)
The bookkeeping for number of dead or removed monsters got out of sync
if a shopkeeper, temple priest, or vault guard on the migrating_mons
list who was scheduled to return to the current level got passed to
mongone() when #wizmakemap destroyed the current level in order to
replace it.
When getting rid of such monsters, first put them on fmon. Once 'gone'
they'll still be on that list and dmonsfree() will include them in the
tally of dead or removed monsters and hopefully the count will match
the number it thinks were pending.
This works for a vault guard; I didn't try for shopkeeper or priest.
Ditch pet(s) so that they won't kill stuff and open up map spots while
you're waiting for guard activity; enter vault away from the wall
nearest to 'civilization'; fill the level with lichens or other junk;
wait for guard to arrive; don't drop gold. After a short while the
guard will try to teleport next to you but with the level full will
end up in limbo instead (migrating, scheduled to come back to current
level). Then perform #wizmakemap. Prior to this patch, there will be
an impossible about N removed not matching N+1 pending; after it, no
such impossible.
viz_array[][] is indexed by coordinates but the data it contains has
nothing to do with them so it shouldn't have been changed to coordxy.
'char' was sufficient; 'uchar' would have been better; this invents
'seenV' instead. This led to a cascade of required changes. The
result is warning free and seems to be working but my fingers are
crosssed....
When a vault guard was created it was producing a "guard appears"
message, then the vault code immediately produced a "vault's guard
enters" message. Suppress the creation message.
While testing that, I noticed that if the hero was blind and lacked
telepathy, "someone enters" started the guard interrogation sequence
but if hero answered and dropped gold, the way out wasn't discernable.
Put a "remembered, unseen monster" glyph at the guard's spot in the
breeched vault wall. The player will need to do <search><move> over
and over to actually follow the guard but at least will know where to
start doing that.
The 'wizmgender' option is flagged as 'wizonly' in optlist.h but that
doesn't prevent it from being set in NETHACKOPTIONS or .nethackrc.
Apply the fix from entrez to only honor it when running in wizard
mode.
Reported direclty to devteam by a hardfought player:
|placing tame fire vortex <56,18> over itself at <56,18>, [...]
An old map fixup when an engulfer and its victim temporarily share
the same map location got impacted by changes made a month or two
back for removing dead or migrated monsters from the map. The old
fixup (for putting the engulfer back after removing the victim also
removed it) was no longer needed and using it resulted in a warning
from place_monster() about putting a monster on top of itself.
Apply the diff from entrez to deal with out of array bounds access by
wand or spell zap when deciding whether to bounce if that zap reached
the extreme edge of the map (not just the edge of the portion of the
map in use by current level).
I captured preprocessor output while debugging vault guard changes
and noticed that glyhp_is_cmap() was expanding to an excessive amount
of code. Simplify it.
Also, a bunch of the cmap macro definitions were using old
(foo && \
bar)
instead of current
(foo \
&& bar)
so this changes those.
Fix wizard mode issues pointed out by the #wizmakemap fix. If a
shopkeeper or temple priest is on a different level and its home
level gets flipped, monst eshk or epri data became invalid and would
cause trouble if the shk or priest ever made it back to home level.
If a vault guard is maintaining a temporary corridor and the level
gets flipped, the data became invalid. If you used #wizfliplevel
while the guard was leading you out, the corridor spots would be
flipped along with the rest of the map but the guards's temporary
corridor data didn't match. Breaches in the vault walls would be
sealed, then the guard would just mill around, never finishing
leading the hero out.
fix #K3633 - vault guard parked at <0,0> brought \
back into play with bad data
I don't have a test case to verify the fix, and I'm not absolutely
certain that the cause has been correctly diagnosed, but I think the
problem was caused by a guard being sent into limbo because the map
was too full to place it, then while it was on the migrating monsters
list waiting for a chance to come back the fuzzer executed #wizmakemap.
If the hero left the level and subsequently returned, the guard would
arrive back but monst->mextra->egd contained data for the previous
incarnation of the level that's invalid for wizmakemap's replacement.
Treat any shopkeeper, temple priest, or vault guard who is not on his
'home' level like the Wizard has been treated since 3.6.0. When
leaving the level they're on, put them on the migrating monsters list
scheduled to return to present position instead of stashing them in
the level's data file. That way they can be accessed from any dungeon
level, so wizmakemap can pull ones for the level it's replacing off
the migrating monsters list when removing the old level's monsters,
handling both migration-pending and already-arrived-on-another-level.
Bonus fix: put monsters who are on the migrating_mons list solely in
order to be accessible from other levels back first when returning to
the level they're on so that pets and the hero can't hijack their spot
when those arrive. The Wizard has been vulnerable to that.
Not fixed: #wizfliplevel command needs to flip parts of shk->mextra->
eshk and priest->mextra->epri for shk or priest on migrating_mons.
Vault guards don't contain anything flippable when migrating, but do
have coordinates that need fixing up while they're maintaining a
temporary corridor to/from the vault.
Pasi Kallinen [Tue, 12 Jul 2022 19:56:30 +0000 (22:56 +0300)]
Valkyries start with a spear instead of a long sword
Long swords are overused, and Knights already start with a long sword.
No other roles start with a spear. Lawful Valks shouldn't have an easy
way to get Excalibur.
There's also historical precedence for valkyries with spears, see eg.
Wagner's Ring Cycle.
This makes Valks early game damage slightly lower, although dwarven spear
does the same damage to small monsters as long sword, and there should be
plenty of chances to get one from the mines. Spears can also be thrown.
This change has been done in several variants, eg. xNetHack and Fourk.
Pasi Kallinen [Tue, 12 Jul 2022 17:24:27 +0000 (20:24 +0300)]
Rejigger anti-magic traps
My changes were too drastic, so reduce the drain and damage so it
matches all the other traps. Now the anti-magic trap will always
ding your max energy a bit, in addition to the physical damage done
if wearing magic resistance.
The most recent "simulated mouse" commit included changes to 'struct u'
that should have been accompanied by an increment in EDITLEVEL. Do the
missing increment now.
Change u.{dx,dy,dz} from schar to int and get rid of unused u.di.
Remove just added getdir_ok2click; it was declared as int but being
assigned booleans. Rename getloc_click to getdir_click and have
getdir() use it for both input and output.
A simulated mouse is becoming quite a nuisance for something which
will probably never be used by anyone in actual play.
When getdir is given '_' as a direction, it calls getpos to get a
map location rather than just a direction. Have getdir()'s caller
explicitly enable that so using '_' for other than #therecmdmenu
doesn't produce a delta that's farther than one step away.
place_monster() sanity check complained that a long worm was being
put at the same location as another monster. The long worm wasn't
on the map prior to that place attempt. This probably fixes it but
I don't a test case so am not sure.
Have the config error reporting routine check whether the message
it's delivering already has end-of-sentence punctuation instead of
adding that unconditionally.
refine PR #814 - included weapon in first hit mesg
When naming the weapon in the livelog message for breaking "never
hit with wielded weapon" conduct, avoid xname() because it includes
"<item> named <something or other>". That's partly censorship and
partly keeping the message from being longer than necessary. Long
messages on tty cause '#chronicle' output to become ugly.
Pasi Kallinen [Sun, 29 May 2022 06:42:25 +0000 (09:42 +0300)]
Fire trap on ice can indirectly kill a monster via drowning
Make the trap routine claim the trap killed the monster even
though it was drowning that did it, otherwise callers cannot
rely on the trap routine return value.
Pasi Kallinen [Sat, 28 May 2022 14:25:29 +0000 (17:25 +0300)]
Fix segfault with fire trap on ice and monster triggering it
When a monster with innate teleporting stepped on a fire trap on ice,
the ice melted and the monster teleported away before falling
into the pool. If the monster's new location had a trap, the code
tried to access the deleted fire trap.
Too many negations for my brain to cope with. I've tested travel
properly this time, but not re-tested running (which shouldn't be
affected by this code).
Pull request from entrez: context-sensitive help. During the
quick farlook command (aka #glance), if the player types "?" to
ask for help don't show "prompt for 'more info'" among the actions
performed for response ".". (":" still mentions that because it
does show 'more info', if some is available, when using ";".)
Michael Meyer [Thu, 30 Jun 2022 00:13:45 +0000 (20:13 -0400)]
Don't describe 'more info' prompt in #glance help
When using #glance, the player is never prompted about whether she wants
'more info' about something on the map, even if flags.help is true and
she has pressed '.' -- the 'more info' prompt is exclusive to #whatis.
getpos_help already changed its description of '.' based on whether
'help' was on or off; adjust those criteria so that the description of
the 'more info' prompt is only included for #whatis, where it is
actually relevant.
I recently looked at the help while using #glance and got confused
about why the 'more info' prompt was never appearing, so hopefully this
should help forestall that sort of thing. #glance also prompts only
once, so there's some other information about "moving to another spot"
in the help text which is not relevant -- that could definitely be
addressed as well but I think it's less likely to be confusing, so I
didn't bother with it in this commit.
Michael Meyer [Wed, 29 Jun 2022 21:19:59 +0000 (17:19 -0400)]
Fix: non-swimming pets eating underwater food
Commit 32234b1d in 2003 mentioned in its commit message that pet dragons
shouldn't be able to eat underwater food items. This was mostly true:
non-swimming pets wouldn't select underwater food as a goal, and
wouldn't spend an action eating something unreachable on their current
position. But the "combined eat and move" case in dog_move didn't check
could_reach_item, so if a non-swimming pet happened to move to a spot
with underwater food for some reason, they could eat it on that turn
anyway. This commit should close this loophole and prevent non-swimming
monsters from eating underwater food (or other unreachable food) even if
they happen to fly over its position.
Michael Meyer [Mon, 27 Jun 2022 20:17:52 +0000 (16:17 -0400)]
allow_category: honor 'goldX' more consistently
A comment in allow_category states that if gold is explicitly selected
as a category, it should be included in the results regardless of what
other BUCX filters may have also been applied. That makes sense to me:
there's only one thing in the gold category, and it always has the same
BUCX status, so it's pointless to try to "filter" the gold category with
a BUCX filter. Considering it a "also add gold, on top of the filtered
results" category adds utility.
However, other categories which may include gold (specifically
justpicked; unpaid is in the code too, but that can't actually happen
in-game) were treated the same way: if the category included gold, no
filter could exclude it. As a result, if the hero had just picked up
gold, 'P'+'C', 'P'+'U', 'P'+'X', and 'P'+'B' all showed the just-picked
gold pieces -- there was no way to filter justpicked to exclude gold
the BUCX categories. This approach made less sense to me: justpicked as
a category may include gold, but filtering by BUCX actually has utility
there, and selecting it doesn't carry a "show me gold in addition to the
other filtered items" implication.
Maintain the same special treatment of selecting the coins category, but
drop it for justpicked and unpaid. In those cases whether gold is
listed in the justpicked result will depend on it not being filtered out
by the selected BUCX categories (and which one it belongs to, in turn,
depends on the 'goldX' option).
Michael Meyer [Mon, 27 Jun 2022 14:10:17 +0000 (10:10 -0400)]
Permit gold to be included in justpicked typeinv
Just-picked-up gold was included in the list of items in the just-picked
category for most category-based menus like 'D' or #loot, but special
handling of gold for 'I'/#inventtype (to accomodate the 'goldX' option)
caused it to be excluded from consideration as a just-picked item.
Include recently picked up gold in 'P'/justpicked when doing type
inventory, consist with other category-menu-based actions.
Pull request from entrez: changes in symbol handling rendered the
'wizmgender' debugging option non-functional. Get it working again,
and when it's enabled have doname() list the corpse or statue gender
formatting those types of items for inventory or other display.
Michael Meyer [Thu, 23 Jun 2022 16:10:03 +0000 (12:10 -0400)]
wizmgender: include corpstat gender in object name
Add another use to wizmgender: when it is enabled, include the gender
specified in corpstat flags in the name of a statue, corpse, or
figurine, since it can influence various things but otherwise remains
invisible (for monsters without gendered names). A little while ago
lichen corpses weren't stacking because, despite being a neuter monster,
the corpses they produced were being flagged as female or male; this
could be useful for debugging issues along those lines.
Michael Meyer [Thu, 23 Jun 2022 15:19:28 +0000 (11:19 -0400)]
Get wizmgender working again
The wizard-mode option to highlight female monsters stopped having any
in-game effect after cb0c21e. Formerly it caused female monsters to be
highlighted with a red background (red color + inverse); this commit
uses inverse video only without overriding their color. Ensuring the
color override works consistently with the ENHANCED_SYMBOLS 24-bit color
doesn't seem worth it for what is a very niche debugging option, and I
think inverse video should probably suffice.
It also used to be a TTY-only option, but this enables it in curses as
well.
From entrez, then modified possibly beyond recognition: don't run
or travel onto lava even with known safe lava-walking because that
isn't 100% safe. But if already on/over lava, allow moving onto
adjacent lava in that situation.
rework TTY_PERM_INVENT; update window port interface
Change the inner workings of the experimental TTY_PERM_INVENT.
Switch to delivering the content to tty for the experimental perm_invent
via the existing window port interface (start_menu(), add_menu(), end_menu).
This also adds a new window port interface call ctrl_nhwindow() for
delivering information to the window port, and/or obtaining specific
information from the window port. The information and requests can
be extended as required. To be documented later once the changes settle
down.
Due to the intrusive nature of these changes and the possibility of
some bugs in the new code, I'm going to leave TTY_PERM_INVENT commented
out in the repository for a day or two. Anyone wishing to test it out
can do so by uncommenting TTY_PERM_INVENT in config.h.
Michael Meyer [Fri, 17 Jun 2022 14:42:14 +0000 (10:42 -0400)]
Don't prompt to continue eating with one bite left
There was already handling in place to prevent showing the "continue
eating?" prompt for one-gulp food (like a wraith corpse), since the hero
would finish eating the food on that turn regardless of what the player
answered to the prompt. Resuming an interrupted multi-bite meal with
only a single bite remaining had the same problem, but wasn't accounted
for in the special "one gulp" handling. Modify the condition so it
checks for the number of bites remaining in the food, not the number of
bites total, and show the prompt only when there's more than one bite
left.
Pull request from entrez: allow rush/run to move over water if
wearing discovered water walking boots. (Having walked over water
while wearing them but without them being discovered isn't sufficient.
Hypothetically there could some other method of acquiring water
walking ability.) #802 supersedes #454.
Michael Meyer [Thu, 30 Jun 2022 18:09:16 +0000 (14:09 -0400)]
Allow travel on water with IDed water walking
If you have a known source of water walking (i.e. are wearing formally
IDed water walking boots), allow travel to path you over water and allow
running over water. A transition from land to water will still cause
the hero to stop in modes other than the shift+dir "move until you hit
something" running mode, so that you don't careen across the entire
level unless you really want to.
Also, fix running over water when levitation or flying is equipped.
This stopped working after f88dce6970, only allowing the hero to move
one square at a time. And prevent travel from pathing the hero into a
wall of water even if flying or levitation is equipped, since they don't
allow you to bypass that terrain.
Michael Meyer [Wed, 15 Jun 2022 21:40:56 +0000 (17:40 -0400)]
Make monsters trigger landmines based on weight
The 1/3 likelihood of a monster setting off a landmine seemed a little
arbitrary to me, especially in that it applied equally to all monsters,
from giants to insects. Change the flat 33% chance to one based on the
monster's body weight, so that lightweight monsters have little to no
chance of setting off a mine, with the likelihood increasing from there
with the monster's weight.
With a trigger weight of 400, as it is in this commit, a dingo has a 0%
chance of setting off a landmine, a gelatinous cube the same 33% chance
as before, an elf a 50% chance, a human a 72% chance, and something the
size of a dragon (ignoring the reduced likelihood for flying monsters) a
91% chance.
From entrez, pushing a boulder into the water on Plane of Water
resulted in a sanity check warning about a boulder at water location
(every turn until bubble movement eventually pushed it back out of
the water). Make boulders in that situation always fail to plug the
water and vanish rather not attempt to plug and remain intact.
This also changes the chance to plugging water from 90% to 50% when
dealing with a wall of water somewhere other than Plane of Water.
Reported by entrez: if a monster with the STRAT_APPEARMSG flag is
seen to teleport away from its current position, an arrival message
would always be given too. If you couldn't see that arrival, you'd
get nonsensical "It suddenly appears!".
Minor fix: when a monster is seen to vanish at one spot and appear
at another, if it was not close you'd get either "appears closer to
you" or "appears farther from you" even if the new spot was the same
distance as the old spot.
Change the regex_error_desc() interface. Have the caller pass in
a pointer to a buffer of at least BUFSZ characters and have
regex_error_desc() populate that. No need for static buffers or
extra dynamic alloction.
Also, change it to never return Null. None of its callers were
checking for that and could have passed Null to config_error_add()
or raw_print(). printf("%s", NULL) produces "null" on OSX but other
systems would probably crash if a Null result ever actually occurred.
The error explanation returned by cppregex included a trailing period.
config_error_add() adds one, so the message ended up with two. Have
regex_error_desc() check for final period and strip it off if found.
(My test case used a menucolor pattern of "[" which triggers an error
about mismatched brackets.)
Reformat cppregex.cpp; treat 'extern "C" {' as if it isn't introducing
a nested block. Fix the '#include <hack.h>' that 'make depend' was
ignoring.
One of the drivers of this change was that screen coordinates require a
type that can hold values greater than 127. Parameters to the window
port routines require a large type in order to be able to have values
a fair bit larger than COLNO and ROWNO passed to them, particularly for
their use to the right of the map window.
This splits the uses of xchar into 3 different situations, and adjusts
their type and size:
coordxy: Actual x or y coordinates for various things (moved to 16-bits).
xint16: Same data size as coordxy, but for non-coordinate use (16-bits).
xint8: There are only a few use cases initially, where it was very
plain to see that the variable could remain as 8-bits, rather
than be bumped to 16-bits. There are probably more such cases
that could be changed after additional review.
Note: This first changed all xchar variables to coordxy. Some were
reviewed and got changed to xint16 or xint8 when it became apparent that
their usage was not for coordinates.
nhmall [Thu, 30 Jun 2022 16:58:19 +0000 (12:58 -0400)]
cppregex regex_error_desc()
Address sanitizer caught a use after free.
cppregex.cpp regex_error_desc() was not returning a pointer
to a static buffer, yet the posixregex was. Follow suit.
nhmall [Thu, 30 Jun 2022 03:21:19 +0000 (23:21 -0400)]
updated window_procs
Add a non-string identifier to window_procs for use in runtime
identification of the current window port being used.
Use a macro WPID to add the identification at the top of the
various existing window_procs declarations. It expands to the
existing text string, as well as the newly added field wp_id
with a wp_ identifier.
For example, WPID(tty) expands to: "tty", wp_tty
The generated wp_tty must be present in the wp_ids enum at
the top of include/winprocs.h.
The WINDOWPORT(x) macro has been updated to expand to a simple
value comparison (port.wp_id == wp_x), instead of a
string comparison.
PatR [Thu, 30 Jun 2022 01:28:01 +0000 (18:28 -0700)]
pull request #797 - running past quest leader \
and not stopping if tossed out of the quest
Pull request from entrez: a running or travelling hero who passes
next to the quest leader and gets tossed back through the portal for
some reason would keep on running on the far side.
Michael Meyer [Fri, 10 Jun 2022 14:51:15 +0000 (10:51 -0400)]
Fix: running through quest expulsion
If a player was in the process of running past the quest leader when she
got expelled from the quest, she would continue running out of the quest
portal on the portal level. Interrupt any running (or other multi-turn
action) when expelling the hero from the quest level.
Michael Meyer [Mon, 6 Jun 2022 20:03:51 +0000 (16:03 -0400)]
Allow intrinsic gain from pet's digestion attack
Add possible pet intrinsic gain from swallowing a monster in one gulp
(in situations where a corpse is created and eaten by the engulfer),
making it equivalent in this regard to eating the corpse off the floor.
One possible extension or modification would be to reduce the chance of
receiving an intrinsic when the corpse is consumed via digestion attack,
similar to how the corpse nutrition is 50% of its normal value. I
didn't incorporate that into this commit since the chance of receiving
an intrinsic is tied to monster level rather than nutrition, so I wasn't
sure if it made sense.
PatR [Wed, 29 Jun 2022 18:46:31 +0000 (11:46 -0700)]
fix 'D' vs obj->bypass
Reported by entrez: dropping items with the 'D' command sets
obj->bypass which prevents an otherwise compatible item from merging
with non-bypass floor stack.
'D' sets the bypass bit to avoid trouble if a dropped item triggers
an explosion that destroys some of inventory (making straightforward
invent traversal be unreliable). Having bypass set prevented merging
with a floor stack that had that flag bit clear. That was very
noticeable if a subset of a stack was picked up and then 'D' used to
drop it again, resulting in two stacks instead of recombining into
the original.
Change the test for mergability to ignore bypass so items will merge
when one has it set and other doesn't. And when successfully merging
set bypass on the combined stack if either part had that set.
PatR [Tue, 28 Jun 2022 19:53:16 +0000 (12:53 -0700)]
pull request #806 - remove unnecessary variable
Pull request from argrath: in destroy_one_item(), 'physical_damage'
is set to False with no provision for changing that it True, so the
'if (physical_damage) xxx' is never executed. Remove it.
PatR [Tue, 28 Jun 2022 19:37:06 +0000 (12:37 -0700)]
avoid becoming stunned due to level teleporting
Reported by entrez: the code to have a hero become stunned for 1..3
turns when going though a level teleporter trap effectively negated
teleport control (except in wizard mode which is probably why this
slipped through). Make the effect happen after level_tele instead of
before, change it from being stunned to being confused, and only
happen if hero lacks teleport control.
The association between confusion and level teleportation already
exists and this might be just enough of a hint for someone who isn't
aware of that yet to figure it out. (Probably just wishing thinking.)
Magic portal traversal hasn't changed; it still causes brief stun.
projects / nethack / log