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.
Fixes#812
The new routine to find an adjacent spot expects to be passed a pair
of 'coordxy *' but the code to crawl out of water was passing 'int *'.
While in there, the removal of inline code to pick a spot to crawl to
made in easy to eliminate 'goto crawl'.
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.
Closes#819
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.
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).
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.
... unless there's some other form that would override the choice,
such as a worn dragon armor, lycanthropy, or vampirism.
The polymorph will be in effect for 10-24 turns.
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.
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.
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.
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.
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.
...because I think it would be interesting to see how many monks break
it with a pick-axe.
Also fix a bug related to logging the conduct:
* If the first hit was a joust that didn't kill the monster, the
conduct would be double-logged.
I lifted the call to first_weapon_hit() out of mhurtle_to_doom() in
order to log the weapon before it broke.
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.
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).
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.
