The only effect of a new moon was to make hearing a cockatrice's
hissing (whichs happens with 1 in 3 chance) always start the turn to
stone sequence instead just having a 1 in 10 chance to do so, but
that was negated by carrying a lizard corpse.
Keep the hiss-always-starts-petficiation part and remove the
carrying-a-lizard-corpse-negates-that part. So the effect of a new
moon no longer gets controlled by the contents of hero's inventory.
When you see a dwarf wield a pick-axe,
|The dwarf wields a pick-axe!
avoid the exclamation point if that dwarf just intends to dig.
|The dwarf wields a pick-axe.
Pull request from entrez: nothing happened--except spending a wand
charge--if a monster zapped a wand of digging down at a spot where
holes can't be dug. If a pit can be dug there, dig one and then trap
the monster in it. No-op if a pit or other trap is already present.
Michael Meyer [Thu, 9 Jun 2022 16:48:41 +0000 (12:48 -0400)]
Let fleeing monsters dig pits in undiggable floor
When the hero zaps a wand of digging down in an undiggable level, it
creates a pit. When a fleeing monster did the same thing, it had no
effect. Bring this closer to the behavior experienced by the hero: if a
monster tries to use a wand of digging to create a hole in an undiggable
floor, a pit will be made (and the monster will fall into it, if not a
flyer).
hero is invisible without being able to see invisible
Issue reported by EndHack: you could see your hands glow red when
reading a scroll of confuse monster or casting the spell of confuse
monster even if you were unable to see yourself.
Switch to the blind feedback (tingling instead of glowing red) if
invisible without see invisible.
Also, have uncursed scroll or low skilled spell confer 1..2 turns
of glowing hands instead of always just 1. (Blessed/highly skilled
stays at 2..9 turns.)
If the first monster on the migrating_mons list couldn't arrive and
was put back on the list to try again later, 'later' would happen
immediately and the program looped forever trying and failing to
bring that monster to the level.
Defer repeat attempts at migration until losedogs() has been through
the whole migrating_mons list. mon_arrive() now populates a new
list called failed_arrivals and losedog() moves its contents, if any,
to migrating_mons prior to returning.
Extend the wizard mode #migratemons command. Instead of just asking
for how many random new monsters to be sent to the next level, first
describe how many migrating monsters there already are, then if that's
non-zero ask whether to show them. Choices are 'c' for ones scheduled
to arrive at the current level if hero leaves and returns, 'n' for
ones aimed at the next level, 'o' for ones that aren't in either of
those two categories, 'a' for all migrating monsters, and 'q' to skip.
After that, ask how many to make for the next level. The default for
that is still zero.
For the 'o' and 'a' cases, they're displayed in the reverse order of
when they went onto migrating_mons, not sorted by destination level.
Pasi Kallinen [Tue, 26 Jul 2022 20:17:54 +0000 (23:17 +0300)]
Fix knockbacked monster migrating or killed
Fix a case where a monster knocked back another monster into a trap,
and the trap either killed or migrated the monster, then the actual
damage dealing later could try to detach the already detached monster.
If the monster migrated, the monster is gone before the damage from
the hit is dealt to the monster.
Pull request from Kufat: combine a pair of single item skills into
one skill by changing scimitar to use saber skill and removing no
longer used scimitar skill.
I don't think skill values end up in save files but decided to
increment EDITLEVEL to be safe.
Deleted scimitar skill, changed scimitar to use saber skill.
Adjusted Barbarian's max saber mastery basic->skilled for consistency
with former scimitar skill.
Pull request from entrez: typing map symbols during a getpos
operation was using incorrect values and might end up moving the
cursor to walls or other terrain that it classifies as uninteresting
and intends to ignore.
Michael Meyer [Sat, 16 Jul 2022 16:21:40 +0000 (12:21 -0400)]
getpos cmap vs glyph followup
This is a bit more efficient, since everything up to S_hcdoor is
skipped anyway, but it's a little harder to understand so needs more
comments. Not sure if it's worth it or not...
Michael Meyer [Fri, 15 Jul 2022 23:53:47 +0000 (19:53 -0400)]
Fix: getpos cmap vs typ/glyph confusion
When some parts of getpos were rearranged in 7404597, tests of terrain
types and glyphs were moved to a loop which iterated through the defsyms
array without being updated to handle cmap values instead. Consequently
they weren't excluding certain terrain types from being 'jumped to' as
intended. (Though it seems as though they actually worked by chance to
some extent, just because there's some overlap between terrain types and
defsyms in terms of where the 'walls/doors' blocks start and end.)
I also noticed that cmap_to_type was missing S_darkroom (it fell through
to the default case so that the function returned STONE), so I added it.
Pull request from entrez: don't allow an amorphous engulfer who
has swallowed the hero to move to a closed door location. If some
hypothetical amorphous holder existed, it could move to such a spot
while holding the hero adjacent.
Michael Meyer [Fri, 15 Jul 2022 02:40:41 +0000 (22:40 -0400)]
Prevent amorphous mon from carrying hero into door
An amorphous engulfer like a fog cloud could engulf the hero, then carry
him into a closed door. If it was killed or decided to spit out the
hero, he would be left occupying the same spot as a closed/locked door.
Make an amorphous monster unable to move into a door if currently
engulfing the hero.
Something more complicated could be done along the lines of allowing the
move if the hero is himself in an amorphous polyform, but that verges on
being a little too silly, maybe.
I also included fixes to a couple miscellaneous, unrelated formatting
issues that I noticed recently.
Extend findgd() to bring a migrating guard back 'early' if there is
one and an active guard is wanted but none is present on the level.
It the level is full then the found guard is likely to be sent into
limbo (scheduled to migrate back), so one can end up moving back and
forth. Unlikely to occur during normal play.
Also, when a guard is needed and there's a dead one parked at <0,0>,
revive it. The dead guard has temporary corridor info in its
mon->mextra->egd that a new one won't have. (This might introduce
unexpected changes in vault behavior but if so, the old behavior was
probably buggy.)
When the hero is in a vault, don't find a guard unless u.uinvault is
ready to bring it into play. It was finding one every turn and then
ignoring the result for 29 turns out of 30.
Change guard appearance timing: the first appearance is still after
30 turns, but if it goes away, bring it back after 15 more turns
rather than another 30 and repeat as needed.
Add a couple of non-timer, non-(property & TIMEOUT) timeout values
for the wizard-mode #timeout command: uswldtim and uinvault. The
swallowed counter goes down and explusion or total digestion occurs
when it hits zero. The in-vault counter goes up when you're in a
vault or the temporary corridor. If you make it out of the vault-
and-corridor it gets reset to zero.
Pasi Kallinen [Wed, 20 Jul 2022 06:42:24 +0000 (09:42 +0300)]
Adjust Demonbane invoke ability
Demon lords and princes have a chance to resist the effect.
Demons in quest when nemesis is alive have a very high chance
of resisting.
When invoked in Gehennom, teleports the demons within the same
level.
Pasi Kallinen [Tue, 19 Jul 2022 12:14:40 +0000 (15:14 +0300)]
Buzz macros and related stuff
Add macros to convert AD_foo, WAN_foo, and SPE_foo to relative values
for passing to BZ_U_foo and BZ_M_foo macros.
Change some return values in monster spellcasting function from
magic numbers to MM_MISS or MM_HIT.
Make buzzmu consider hero resistances - previously the
monster with innate zapping ray (Angels and Asmodeus) would
just keep doing that attack, but they will now just curse if
it saw the hero resist the attack.
The log message for commit 231bd75b7f5ddc3ef0f745a75ea3566cc4055d99
said that magic harp was changed to behave the same as scroll/spell
of taming, but the scroll and spell pacify an angry shopkeeper even
if the shk resists. Change magic harp to do likewise.
Save and restore or recovery or both could mess up the stair data
about where stairs went. I'm not entirely sure what is going on here
but the steps to reproduce by Meklon2007 worked and the suggested fix
by entrez solved the problem.
Michael Meyer [Fri, 1 Jul 2022 16:29:47 +0000 (12:29 -0400)]
Fix #812: recovered stair dlevel
Stair dlevels weren't being restored with the correct values when
recovered after the game crashed, apparently because they weren't being
reset back to their 'absolute' level from a 'relative' level. I'm not
totally sure of why this affected only recovered games (maybe that's the
only time when the 'relative' stair values are used?) but this fix seems
to work.
I tried to reproduce #812 so that I could check whether the suggested
fix worked but I discovered that external 'recover' was broken by the
coordxy changes.
The fix is trivial but I haven't gone back to #812.
Change some more
(first_line <op> \
second_line)
to
(first_line \
<op> second_line)
for various values of <op> besides '&&' and '||'. Also clean up some
indentation and backslash+newline alignment.
For object_is_piletop() don't bother to validate that an object which
is classified as being on the floor is actually on the floor at its
specified map coordinates. That check was propagating to expansions
of multiple macros and if it ever failed it would just be hiding a
very serious bug without helping to fix that.
The new test in m_detach(mon) to check whether mon was already detached
is being tripped for trolls who died, revived, and died again. Clear
out the MON_DETACH bit when saving montraits.
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.
projects / nethack / log