Extend PR #1240 by giving the three brides names.
It looks a bit odd when they're in bat/fog/wolf form rather than in
base vampire lady form but I think that we can live with that.
In the original Bram Stoker novel, Dracula has three brides,
colloquially referred to as the [Brides of Dracula]
(https://en.wikipedia.org/wiki/Brides_of_Dracula). I thought it would
be a nice touch for NetHack to quietly reflect this by ensuring three
of the vampires of his court are vampire ladies. While this
technically increases the difficulty of Vlad's Tower, the vampires in
Vlad's court are not necessary to fight, and the experience level of
a hero at this point in the game is likely to cause them to spawn as
vampire lords or ladies in any case.
No established names exist for these characters, so I have left them
unnamed.
[Cherry picked rather than merged into order to reformat the commit's
log message. PatR]
Closes#1240
Pull request from argrath: replace 'goto nothing_special' with calls
to new routine nothing_special().
Needed some conflict resolution from 'git rebase' after sitting for
such long time.
Closes#1168
This makes it easier to understand what is happening in each of those
places, and also much easier to find the places that conversion between
hero and monster resistances happens (since you can now just grep for
"res_to_mr"). I think I got all the instances where the macro should be
used but I'm not 100% sure since there wasn't a single unique term to
search for to find them all.
I replaced the modifications to give_u_to_m_resistances made in the
previous commit, so that it now uses the same macro as other
conversions, since otherwise it would be much harder to find the
complete list of places where conversions between hero and monster
properties happen.
I think that using two arrays in tandem like give_u_to_m_resistances
originally did is frequently considered a bad idea, because one can
easily be added to or subtracted from without modifying the other --
that could obviously cause problems. Combining the arrays like this
avoids that potential problem.
Landmine blew up, scatter exploded a potion of oil, which melted
the ice on which the landmine was, resulting in the landmine trap
being deleted. The code then tried to access it to make a pit.
Issue reported by Umbire: if hero dies by drowning on the Plane
of Water, cause of death was reported as "drowning in a limitless
water".
Reported for livelogging but applied to tombstone and logfile too.
Omit the article "a" in this situation.
For 3.6.7, it would have started as "drowning in a water" and been
updated on the fly to be "drowning in deep water". 3.7 changed
terrain type WATER to be "wall of water", where "a" is expected,
and also added "limitless water" for Plane of Water, but it was
neglecting to include a similar fixup for the latter. The "deep
water" fixup is still present but doesn't get triggered anymore.
Fixes#1248
A monster swallowed hero, hero teleported the monster away, but the level
was full of monsters, so the swallower ended up not moving anywhere,
so it was in the same location as hero, but hero wasn't swallowed by it.
Move the monster into limbo instead.
A pet titan dropped a boulder over a pool, and the code killed
the titan, because the code was considering the titan to be in
the water.
If a flyer or a floater is over the pool, don't kill them off
if a boulder is dropped in there. Also make the pet movement
code handle the case where the pet might've died while dropping
items.
The revised code returned an uninitialized variable if the new test
failed.
The cloneu() case was ok but this changes it to keep parallel to the
clone_mon() case.
Noticed while doing rudimentary testing of the mnearto() fix for
mimics. #migratemons wouldn't add monsters to migrating_mons if
getlin() was compiled with EDIT_GETLIN defined unless you manually
deleted the invisible default value that wiz_migrate_mons() was
passing. It took a while to puzzle that one out.
The command list has conditional description of what #migratemons
does and it was using the wrong spelling of the macro used to
control that. So '# ?' described the behavior of #migratemons as
it operates without DEBUG_MIGRATING_MONS enabled even when that is
enabled, adding to the getlin() confusion.
When mnearto() places a monster, it might remove another one to make
room, then try to put that second one back. If it can't do that, it
puts that other monster onto the migrating monsters list. But having
it already be off the map interferred with regular take-mon-off-map
handling that happens when setting up a migration.
If the other monster was a hider or concealed mimic, it wouldn't be
brought out of hiding. With 'sanity_check' enabled, that triggers
a warning when the occupants of migrating_mons get checked.
Testing this requires more effort than I'm willing to expend so there
might be unexpected consequences.
Issue reported by chadministratorwastaken: persistent inventory
window didn't update if reading a spellbook caused that book to fade
to blank paper.
Issue was reported for 'curses' but it was general. The core made
the possibly-revised book type become discovered but that wouldn't
update perm_invent unless the type of book hadn't been discovered.
So if plain spellbook wasn't known yet, the persistent inventory
window did update as intended, but if spellbook of blank paper was
already discovered, the window continued to show the old book type
instead of changing to reflect the revised type (until subsequent
activity triggered another perm_invent update).
Fixes#1246
|w - wield this item in your hands
is "suboptimal" when poly'd into some form which lacks hands. Don't
offer 'w' as a choice if in a form what can't wield anything, and
substitute "claws" for "hands" when in forms that warrant it.
Include iron ball as a type of item leading to 'w - wield as weapon'
instead of falling through to 'w - wield in hands'.
Since inventory actions can be used as teaching aids for regular
command usage, change picking a potion in inventory from
|q - Quaff this potion
to
|q - Quaff (drink) this potion
When picking the uquiver item in inventory, add
|f - {Shoot|Throw} this item
and for the shoot case, tack on "with wielded <launcher>".
That makes 't - {Shoot|Throw} this item' nearly redundant (but only
for an item in uquiver slot) so tack on "(same as 'f')".
For the 'Q' choice (only offered for weapons or rocks/gems), have it
mention what the quiver is for rather than just that choosing that
menu entry would put the stack in the quiver slot.
For 'E - Write on the floor with this object', change the verb to
"Engrave" when the object is a bladed weapon, hard gem, hard gem
ring, or wand. It also changes 'floor' to surface() which might
need some refinement.
For non-weapons, change 'w - Hold this tin opener...' and 'w - Hold
this item in your hands' to 'w - Wield this...'. The concept of
holding an item in hero's hands isn't applicable in general, and in
particular any "held" item replaces wielded weapon.
For a bunch of instances of "this item", when the quantity of the
selected inventory entry is more than 1, change to "one of these
items" or "this stack" depending on how the specified action deals
with stacks.
Coming up to medusa-3 from the level below revealed that Perseus's
statue was not there. It was placed randomly in one of the three
chambers where Medusa might be rather than in the one where she
actually was. Medusa-4 behaved similarly.
Initially I was forcing the statue to be adjacent to Medusa rather
than on her spot, but medusa-1 and medusa-2 don't do that so I've
gone with a simplified revision.
Wake up a sleeping target that gets hit by chain lightning. Also,
bring mimics and hiders out of hiding.
Don't let chain lightning pass into the water on Plane of Water (or
water-wall elsewhere); not sure whether that makes sense physics-wise
but it would have feedback problems due to visibility issues. Do let
it pass over lava.
For curses, behave like tty by keeping a count of messages issued via
raw_print, then if that is non-zero issue a prompt and require the
player to acknowledge them before it erases the screen. Mainly so
that complaints during RC file processing will be seen.
For tty, force getret() to be an unconditional routine instead of
sometimes a routine, sometimes a macro which calls another routine.
Give alternate shop type names for most of the shop types that didn't
already have such. "General store" is the last remaining exception.
Only matters for automatically generated annotations for #overview.
Using #invoke on wielded or carried Sunsword and picking direction
'>' or '<' lights the hero's spot. But setting levl[u.ux][u.uy].lit
was too simplistic. Lighting on the Rogue Level operates on full
rooms when done inside a room and doesn't to anything with done in a
corridor.
litroom() gave inappropriate messages in a couple of special cases.
Reason: The following concern was raised:
"The trademark indicators were not out of sync. The Guidebook
uses footnotes for that, 'history' uses "(tm)" in the text which
works better when nethack displays the text."
@Umbire wrote:
Very simple change code-wise - if he's gonna use a yumi a hunter of his expertise should presumably have the projectiles match.
Closes#1213.
This may be useful for some build environments to avoid parallel make
issues, and artificially-concocted order dependencies, leaving the ordering
up to that specified in the Makefile.
The related makedefs options are now:
‐s Generate the bogusmon , engrave and epitaph files.
‐1 Generate the epitaph file.
‐2 Generate the engrave file.
‐3 Generate the bogusmon file.
Also resolves an existing issue encountered in doc/makedefs.6 where "and epitaphfiles"
was being produced in the result.
Have magic mapping add special rooms to known overview data. Only
affects shops and temples because they're the only rooms tracked.
Most other special rooms revert to normal rooms as soon as they're
entered so there wasn't any point in tracking them. That might no
longer be the case.
Wand of probing zapped at or through a shop door or even at a shop
wall will add the shop annotation to the overview data. That works
differently for normal shops than for subrooms in the twin business
theme rooms. I'm not sure whether any fixing is needed there since
the shop type information gets suppressed as soon as more than one
shop becomes known on a level.
Add the shop type variations used for automatically generated
annotations to the shop structure and get rid of the switch that
has been being used to pick them.
