The #genocided command was revealing extinct monster species when used
during normal play. That was not intended, so stop. Change to only
reveal them in wizard or explore modes and also during end-of-game
disclosure but suppress them during normal play.
The full description of #genocided is now dynamically updated for '# ?'
during normal play to remove its reference to extinctions. Also, check
for skipping wizard mode commands before doing description searching.
\#genocided was out of alphabetical order in the full commands list.
Both it and #vanquished should have had the GENERALCMD flag; they
don't affect game state.
Change #genocided to use the sort order currently set for #vanquished,
and allow 'm #genocided' to put up the same menu as 'm #vanquished'.
(Not quite the same. Sorting by count of monster deaths isn't
appropriate for listing genocides where an arbitrary number may have
been killed before the genocide occurred. If the preferred order for
vanquished is set that way, alphabetical will be used for genocided.)
Setting the order via menu for either command sets the order for both,
but doing so via #genocided doesn't offer the count-high-to-low and
count-low-to-high choices. During disclosure, you can answer 'a' when
asked whether to disclose genocided and extinct monster types and like
for vanquished monsters, that lets you choose an order at end-of-game.
Doing so won't affect disclosing of vanquished monsters--it'll be too
late for them.
A chunk of this diff is due to moving the #wizborn code out of the
middle of #vanquished handling.
Guidebook.ms has been updated but Guidebook.tex is lagging.
Burying an olog-hai corpse with a boulder resulted in a panic when
its time to revive occurred. I was able to reproduce this once but
failed with "you feel less hassled" several times (using same save
file for multiple tests) so I'm not quite sure what was happening.
A buried corpse was allowed to revive if it was for a zombie. This
fix extends that to auto-revivers (trolls and Riders). The corpse
keeps its revive_mon timer rather than changing that to zombify_mon.
If/when revival of a buried troll or Rider happens while in view, it
will "claw itself out of the ground" like zombies do.
The exploding magical trap did not cause problems before just by
being a magical explosion by accident; adding an object caused
the cancellation wand ID to change, and the explosion now had
an impossible explosion type.
Hardcode trap explosions to generic magical blasts.
Reported by copperwater, it was possible for a web to be created
at a water or lava location. It would not be displayed even after
being discovered; showing the terrain superseded showing the trap.
But it functioned normally and could trap the hero. Webs pull the
victim to the floor so hero would drown or burn up on next move
even if the spot had been reached while floating or flying.
A monster spider couldn't survive at a water or lava location, but
a poly'd hero could. Creating a web via #monster or wizard mode
wish could result in it affecting some unsuspecting player via bones.
Disallow creation of webs at water, lava, and air or cloud spots.
(They're already disallowed at furniture spots.)
Fixes#1017
While looking for something in dogmove.c I did some source cleanup.
Undefine its macros by the end of the file, and redo some pet vs
guardian angel handling that dated from when the monst extensions for
those two were overlaid.
When lastseentyp[x][y] is different from levl[x][y].typ and #terrain
tries to show <x,y>, the value of levl[x][y].flags might not have an
approrpriate value for the remembered terrain type. The reported
problem was an impossible() about wall mode.
rm.wall_info == 4 corresponds to rm.doormask == D_OPEN and both of
them are overloaded on rm.flags. A spot remembered as a wall but
actually a secret door might cause this if it has become discovered
('wall' changed to closed door) and then opened (with door intact)
while out of view. [I'm not sure how that could happen though.]
I was unable to reproduce it so haven't verified that the fix works.
Reported directly to devteam: a fake player monster was petrified
and when creating its statue yielded "Calculating weight of 0 gold
pieces?".
Fake player monsters on the Astral Plane level were being created
with rn2(1000) gold pieces so had a 1 in 1000 chance of that being 0.
Gold gets created with a non-zero amount but the routine that gives
it to a monster sets the amount to the requested value. That didn't
update the weight so didn't notice the 0. Putting it into a container
(the statue) did recalculate the weight and did notice.
There was a choice between forcing a non-zero amount or allowing 0
and bypassing its creation and placement in monster's inventory.
I went with the latter.
Discussed a long time ago, change helm of brilliance from iron to
crystal so that it doesn't need to be a special case for metallic
armor's affect on spell casting. It now has a fixed description of
"crystal helmet" but is not pre-discovered.
Add new helm of caution to retain the "etched helmet" description
among the shuffled helms. Wearing it confers the Warning attribute.
That's fairly lame but not necessarily useless. It's iron and gets
half the former probability for a random piece of armor being helm
of brilliance so is not likely to be popular.
Helm of caution keeps the old helm of brilliance tile and new helm
of brilliance is basically the same image with different color and
pointed on the top.
Not changed: the etched helmet was marked as green and is drawn
that way for text but the tile doesn't actually use green for it.
Crystal helmet started as hi_glass (rendered as 'bright cyan') but
has been changed to clr_white to match crystal plate mail.
Old save and bones files are invalidated.
I was working on this at the time 3.6.0 was released and set it aside
until later. Later has finally arrived. Redo the Blind, Blinded,
Blindfolded,&c macros to make more complete use of intrinsic property
handling. Blinded was being treated as a number which could be added
to or subtracted from; now that has to be done via TIMEOUT mask
because it has FROMOUTSIDE (OPTIONS:blind) and FROMFORM (poly'd into
!haseyes() form) bits included. Object definitions for blindfold and
towel now specify the BLINDED property; overriding blindness via the
Eyes of the Overworld is accomplished via props[BLINDED].blocked.
Code generated for the scores of Blind and !Blind tests throughout
the program should be smaller.
One bug that has been fixed is that putting on the Eyes of the
Overworld cured permanent blindness (from OPTIONS:blind). The
u.uroleplay.blind flag was cleared and stayed so after taking them
off. Putting the Eyes on still breaks blind-from-birth conduct but
now blindness will resume when they are removed.
This was untested at the time it was set aside and is only lightly
tested now. A large number of the changes here are just to switch
from Blinded to BlindedTimeout for current timed value and to call
set_itimeout() for setting a new value.
pline() already skips sprintf/vsnprintf if the format doesn't contain
any percent signs. Do the same if the entire format is "%s".
Also, if ESC is used to suppress messages for the rest of the current
move, the text for any impossible warnings issued during that time
would be suppressed too so not be seen.
My change to make items thrown by monsters landing on altar
caused doaltarobj being called twice when hero dropped an item
on it. Call the newer instance only when monsters are moving.
A recently added #undef WT_ELF caused a onefile build to break.
trap.c: In function 'trapeffect_landmine':
trap.c:2346:41: error: 'WT_ELF' undeclared (first use in this function); did you mean 'PM_ELF'?
trap.c:2346:41: note: each undeclared identifier is reported only once for each function it appears in
Heroes recognized unseen same-race monsters by voice, but it yielded
an unexpected result if the monster was unique. Change it so that
hero will recognize any type of monster by its voice if that monster
has been seen and limit unseen same-race ones to non-unique monsters.
Treats shopkeepers as unique since they have distinct names.
This adds a new flag to struct monst in order to track whether each
specific monster has ever been seen or sensed.
Undefine some macros when the file that uses them is done so that
they won't be seen by any other source files if combined into one
huge source file. I only looked at the few files where an #undef was
needed, not all the files, but in those few files I used #undef for
[almost] all their local macros instead of just the troublesome one.
display.c is the exception; it still has lots of macros which persist
through end of file. nhlobj.c is another exception; I misremembered
the fixup for lua's lobject.c at the time and decided to include the
one #undef for nhlobj.c anyway even though 'onefile' isn't affected.
monst.c includes some reformatting. display.c's sign() macro was
redone; it's intended for efficiency compared to calling hacklib.c's
sgn() function so streamline it.
[Keni, most of the file-specific #undef fixups in genonefile.pl can
now be removed. It'll still need one for lua source file lobject.c;
addstr() there conflicts with curses.h, not with nethack's own code.]
The revised #overview (displaying info in a menu instead of text
window), works as intended for tty and curses, during play and also
during end of game disclosure.
For X11 it worked during play but during disclosure it issued a
call to impossible() for every line of overview output and there
was no overview shown. ("add_menu: called before start_menu",
sent to stdout where the player may not have a chance to see it.)
For Qt things were worse, working during play but with indentation
that isn't what is intended, and during disclosure it crashed in
add_menu().
This avoids the impossible and the crash, by changing how the core
treats the menu rather than by updating how FOO_add_menu() deals
with the offending previous usage.
I suspect that to fix the Qt indentation, #overview might need to
be changed to behave like #attributes: use a menu during play but
a text window during disclosure. It has a hack for text windows
to switch from the default font to a fixed-width one if any line
in the text contains four consecutive spaces. Either menu windows
aren't doing the same thing, or the two-column layout they use to
render their text is messing that up. (I haven't looked.)
... if the boulder is in a position they want to move to.
Shopkeepers, priests, and the quest leader can break one boulder
and then need to take several turns before being able to break
another. Riders can break a boulder every turn.
Require the 'm' prefix to treat #overview as a menu with selectable
entries. During end-of-game disclosure it shows every level that was
visited, but during play it only shows levels which have annotations
(typically automatically generated ones). The menu wasn't offering
any chance to add an annotation to levels without such, so force
'm #overview' to show every visited level. Continue to avoid that
(and also avoid the clutter introduced by menu entry selector letters)
for normal #overview.
... unless explicitly specified to generate at a specific point or
within a specific area. But if they are permitted to generate anywhere
on the level, and it contains water, they always end up in the water. I
noticed this when trying to explicitly specify ghouls to generate
anywhere on a level with a minimal amount of water.
This was due to the definition of "amphibious" being conflated with
"breathless", such that all breathless monsters counted as amphibious.
There are plenty of breathless monsters in the game that decidedly don't
normally inhabit water, such as undead, but they would pass the
amphibious() check in pm_to_humidity and thus the game decides that they
must generate in wet terrain if there is any available.
This fix takes the approach of changing amphibious() so that it no
longer checks the M1_BREATHLESS flag and only considers M1_AMPHIBIOUS,
then updating the places where amphibious() and Amphibious are used
accordingly. I also added a new macro cant_drown() which wraps up
swimming, amphibiousness, and breathlessness because these three things
are frequently checked together in the context of whether something
should drown.
Places where amphibious() or Amphibious did NOT have an extra
breathless() or Breathless check added on, and thus where behavior has
been changed:
- The pm_to_humidity function (to fix the bug).
- Player vs water in goodpos; it didn't seem like being polymorphed into
a breathless non-amphibious monster should make it fair game to
randomly teleport into water even though it's technically safe.
- Awarding extra experience when killing an eel. (So the hero will get
the extra experience if they are polymorphed into a breathless
non-amphibious monster and don't have magical breathing. Very much an
edge case.)
Aklyses uniquely have a tether attached to one's wrist, which would stay
secure even when one's fingers are slippery. Therefore, it doesn't make
for the weapon to be dropped completely, tether and all, when Glib.
However, the game doesn't have a way to model a weapon that's on the
floor at your feet but still attached to your arm. (Technically the
uball and uchain code does do this sort of thing already, but it can't
be used here - what if you have an aklys slipping out of your grasp and
are punished at the same time?) So the next best thing is to give
aklyses immunity to slipping from one's hand.
This aims to fix the issue in which there are way more wands of speed
monster in the game than the player has any use for. Usually, one is
enough for the whole game (unless a player has a lot of pets they want
to speed up) but since they're an item monsters can generate with, it's
typical to see eight to twelve of them, useless for anything besides
polypiling into other wands since they just grant an intrinsic that's
usually obtained early in the game.
By making the wand effect (on the player) temporary very fast speed, it
becomes desirable to keep the wand around again. By adding a lightweight
source of very fast speed, it also helps diversify character builds away
from always relying on speed boots. And importantly, it becomes an item
the player can use situationally early in the game to enhance their odds
in a fight or run away from danger.
Meanwhile, the speed-intrinsic-granting has been moved to the potion,
and the potion is still superior to the wand in the duration of very
fast speed it grants (100 + d10 turns for an uncursed potion or 160 +
d10 turns for a blessed one, versus 50 + d25 turns for the wand).
Since monsters don't have a concept of very fast speed, this doesn't
change the wand or potion effects on them. They will still gain
permanent intrinsic speed by either method.
Issue reported by AndrioCelos: if hero was killed by a wand zapped
by a monster, the cause of death was "killed by <wand damage>
imagined by <the monster>" instead of intended "killed by <wand
damage> zapped by <the monster>". Report mentioned that the monster
was unseen but that wasn't relevant.
This worked when monster wand zaps were briefly changed to use
-9..-0 but got broken when that was reverted to using -39..-30 (due
to -0 being the same as 0 so making zapper of wands of magic missile
ambiguous).
Fixes#1011
If for some reason a shop room has multiple doors, try all of them
to find a good shop door, instead of just the first one, and failing
if it wasn't a good one.
This only matters for wizard-mode with SHOPTYPE environment var.
Prevent hug attacks (owlbear, python, pit fiend, several others),
attacks for wrap damage (eel and kraken, trapper and lurker above),
attacks for stick-to damage (mimic, lichen), and attacks for digestion
damage (purple worm) from succeeding against unsolid monsters (ghosts,
lights, vortices, most elementals).
Polymorph of an engulf or hold target into unsolid form has been
addressed by a couple of previous updates.
More towards not being able to swallow or hold an non-solid creature.
When engulfed, expel hero if the new form is unsolid or too big.
Give a message if hero is being held (rather than engulfed) and has
to be released.
Adding a call to expels() required some code reordering because it
calls spoteffects().
Give the hint about using '#monster' at the very end of polymon().
Wizmode testing shop generation, I encountered impossible
"Where is shopdoor" - the room that was being turned into
a shop had a subroom sharing the outer south wall with
the parent room, with a random niche placed such that it was
actually in the subroom wall. The niche door was still added
to the parent room, and the shop generation was trying to use
that door as the shop entrance.
As random niches are only used in room-and-corridor style
levels, subrooms aren't that common, so I just opted to
skip the niche generation if it was going to be placed
without being directly attached to the room it wanted.
The niche generation could be changed at a later date to actually
add the niche door to the correct room instead, if we ever feel
it's necessary to have random niches in subrooms.
As an interesting side note, I had no idea random niches were
only placed in the south or north walls of rooms, never to
east or west.
Something I noticed while looking over the recent report about hug
attacks. If a monster carrying one or more boulders (picked up while
in giant form) polymorphs into a non-giant, it will drop them. If
that happens while it's trapped, it could be killed. newcham() would
use a stale pointer to continue traversing its inventory after it was
dead and its possessions had been dropped.
I managed to get a chameleon-as-giant carrying boulders and some other
stuff trapped in a bear trap and then transform, but the few attempts
I made never killed off its next form so I wasn't able to induce a
crash to verify that a problem would actually occur.
The fix in commit 14d003c4ba prevented
current energy from ending up 1 point above maximum energy but it
didn't preserve the intent of splitting the drain with up to half
coming out of maximum and the remainder out of current. This restores
that intent but now only does so when maximum is more than the full
drain amount rather than when it is more than the up-to-half portion,
becoming less harsh when hero's max energy is very low. If current
is also very low then max energy will be reduced anyway, but by less.
Some unrelated formatting of invent.c has gotten mixed in.
Revises #1003
Issue reported by vultur-cadens: when trap effect of an anti-magic
field reduced maximum energy, the result might end up with current
energy being one point higher than new maximum.
Fixes#1003
