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.
Closes#817
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.
Closes#821
When a monster at least two sizes larger hits another one,
there's a chance the smaller defender will be knocked back.
This applies also to hero, attacking when polymorphed to
a large monster, or defending from a large monster.
Most of the monsters that can knock back are giants and dragons.
Idea and some of the code from EvilHack.
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.
Closes#812
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
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.
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.
now includes what the weapon was
Pull request from vultur-cadens: show the weapon used when logging
the breaking of "never hit with a wielded weapon" conduct.
Also, if that first hit was a successful joust attack it was being
shown twice.
Closes#814
Pull request from entrez: non-swimming pets wouldn't target
underwater food but if a flying pet happened to move over such food
it would eat that.
Fixes#810
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.
Closes#802
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.
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.
Closes#797
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.
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.
When migrating, a long worm is removed from the map to take off the
tail, then its head is put back to be treated like other monsters.
If that occurred when being forced to re-migrate during failure to
arrive from a prior migration, it wouldn't have valid coordinates
and the place_monster attempt produced an impossible warning.
(Other types of monsters don't get removed and put back so didn't
trigger the problem.)
The routine to format a monster when the data is suspect mistakenly
thought it was dealing with a long worm tail because the monster
didn't match level.monsters[0][0], so the warning inaccurately
reported the problem as "placing long worm tail".
From a followup comment to a reddit post: a vampire who has gained
levels loses them when reverting to base form. This fixes the case
where it grows into a vampire lord; change the base form from plain
vampire to lord when that happens.
It does not fix the case where shapechanging to fog or bat or wolf
and then back to base form yields a new vampire or vampire lord
instead of the one that built itself up. Mainly affects pet vampires
since wild oees don't tend to grow very much.
(user-side decisions really, but as it stands right now
user-side decisions/options are made and processed by the core)
add a parameter to add_menu so color can be passed
release_hold() checked for (Upolyd && sticks(g.youmonst.data)) before
checking for (u.uswallow) and it could set u.ustuck to Null while
u.uswallow remained set to 1. dmove_core() was accessing u.ustuck->mx
and u.ustuck->my after that, resulting in a crash.
This fixes that particular case but there might be others that also
assume sticky poly'd hero should be handled before swallowed hero.
Being swallowed/engulfed needs to be handled first.
Reported by entrez: attempting to name certain undiscovered items
after an artifact could be used to tell whether the item being named
was the same type as the artifact, so trying to name a gray stone
the Heart of Ahriman would let you tell whether it was a luckstone.
That was fixed years ago to reject for any undiscovered gray stone
rather than only for luckstone; you'll get "your hand slips" and the
name would be smudged. But that fix allowed a loophole and could
still be exploited if the player used lowercase for the name: it
would get changed to mixed capitalization if the object was the
artifact's type or stay lowercase if it only matched by description.
This changes to the capitalized name even when the type isn't an
exact match, so attempting to name either a luckstone or a touchstone
"the heart of ahriman" will name it "The Aeart of Xhriman" with at
least one smudged letter to avoid the actual artifact name.
Unrelated change: when attempting to apply a new name to an existing
artifact, it now says "<Artifact> resists" rather than "The artifact
seems to resist" because there's no "seeming" about it.
Allow the hints file to apply a correct timestamp to
the Guidebooks prior to use.
Detect the NH_DATESUB in the Guidebook.mn or Guidebook.tex
files and replace the datestamping line that follows.
If git is available, it determines the hash of the last commit
applied to doc/Guidebook.mn, and then determines the date of
that commit. The interim Guidebook.dated.mn (or
Guidebook.dated.tex) gets the datestamp applied.
If git isn't available or doesn't correctly provide the hash
for doc/Guidebook.mn, it should just continue to use whatever
hard-coded date in the Guidebook.mn source file (it uses it
instead of the interim file).
Reported by entrez: if magic whistle summoned a pet onto a trap, the
messages produced could be in the wrong sequence or contradictory.
The code was collecting counts and name-of-first for shift (was seen
before whistling, seen at different spot after), for appear (wasn't
seen before, now is), and for disappear (was seen before, now isn't)
before dealing with a trap at arrival location. The trap could issue
a message (including pet killed, pet sent away--teleport trap, hole,
&c--or pet changed shape--which occurred after its name/old shape was
saved for use when it was the only one in its category), and finally
the summary message was issued.
Change the code to handle arriving in a trap before the collection
into the three categories that provide feedback, and skip the latter
if any message was given during mintrap(). That handles the most
glaring anomalies like killed followed by shifted location or takes
on new shape followed by old shape shifted or appeared. But it no
longer gives specific shift/appear/disappear feedback for those cases.
Pets that don't land on traps or who land on ones that don't issue
any feedback aren't affected.
The accessibility aspect of this--message feedback in order to avoid
tedious screen reading of the map--will need to be satisfied by the
trap feedback unless/until someone comes up with a better solution.
One possibility is an option to allow player to have rloc() always
issue its vanish and appear messages. Right now it does so when magic
whistle hasn't been discovered yet, then avoids that hyper-verbosity
(if hero has multiple pets) once it has. Or the whistle code could
count the number of pets first, then behave as if such an option is in
effect when the count is small and only resort to the current summary
method if the count is larger than some threshold.
Incorporate the diff from entrez describing the travel_debug wizard
mode option and removing obsolete M prefix from the Guidebook. That
missed a reference to it in the description of '_'.
I put M back in case someone who has used it with earlier versions
tries to use it and gets a no-such-command complaint so goes looking
for it.
Also, make the mention of ^X at the end of the discussion of status
stand out a bit. The indentation of its paragraph made it line up
with the preceding text instead of making it be distinct from that.
The TeX changes are untested and given the amount of punctuation
characters used, it will be surprising if they all have been quoted
properly.
The nomakedefs stuff for cross-compiling support broke the code to
treat enabling or disabling some optional features as not breaking
save and bones file compatibility. It was relying on a macro whose
definition was local to mdlib.c rather than propagated among files.
makedefs still constructs date.h with a value indicating the ignored
features but the actual compatability check doesn't use that anymore.
Toggling SCORE_ON_BOTL shouldn't have caused existing files to be
rejected but they were.
Reported by entrez: buying an unpaid item using itemized billing used
to result in the price information for unpaid items disappearing when
they get shown by perm_invent. (Their status as unpaid didn't change;
persistent inventory just got redrawn without cost information.) The
fix for that didn't handle buying a used-up item. There's no invent
update for the gone-item item but there is one for moving gold out of
hero's inventory to add to shopkeeper's inventory. The vanishing
price phenomenon applied to that situation too.
I can't think of any situation where persistent inventory would want
to hide unpaid status and/or cost, so always prevent those from being
excluded during perm_invent update.
The #therecmdmenu command calls getdir() which issues an "in what
direction?" prompt. This allows you to answer with "_" instead of a
regular direction, then it will call getpos() to allow you to move
the cursor and type "," (or ";") to behave as if a left-click had
been done or type "." (or ":") to behave as right-click.
Ordinarily I would think of the 'normal' getpos() response of "."
as suitable for left-click, then one of the other getpos finishers
for right-click, but comma is left of period on a standard keyboard
and that seems useful for remembering which is used for which click.
Left clicking on a spot farther than one step away offers travel,
throw iff lined up, and also click-look as choices. If you right
click farther than one step away, it will only offer click-look.
The look choice for either left or right click isn't inhibited by
having the clicklook option set to False. After all, player is
explicitly choosing the menu entry to look at something.
New getdir.mouse can be bound to some other key than "_" and the
getpos.pick* responses could already be re-bound, but there's no
separate getdir.left/right that could be used to bind different keys
from those used for the four getpos responses.
Refine the code added by pull request #763 to check the quest nemesis
death message for reference to noxious fumes rather than having the
three relevant roles be hardcoded.
Pull request from matteverett: for generating starting equipment,
mark a wizard as having received a level 1 spellbook when getting
guaranteed force bolt so that the random second spellbook can be
level 1, 2, or 3 as intended rather than unintentionally be forced
to be level 1.
Closes#770
Reported by entrez: fix memory being accessed after having been
freed by trying to keep ball&chain data up to date when they're
processed by the save code. This fix is a little more elaborate
than this suggested one. I'm crossing my fingers on this one....
Issue #769, reported by k2 and diagnosed by entrez: eating a troll
corpse that revives on the last turn of the meal was using up the
corpse while the revival was in progress (unless the hero couldn't
observe the resulting monster), leading to a panic when trying to
use it up at the end of revival. Brought on by a recent change to
interrupt an occupied hero who can observe a hostile monster being
created nearby.
The fix isn't perfect. If revival fails because there's no place
to put the revived troll, the meal will be interrupted with one bite
left instead of finishing. If that happens, the interruption will
include a "you stop eating" message, just with no explanation why.
The partly eaten--almost completely eaten--corpse will remain.
Closes#769
