Recent(ish) change to split unexplored glyphs from solid wall glyphs
resulted in getloc commands to choose unexplored and interesting
locations not work correctly.
Fixes#323
This was already allowed for the other montype-compatible objects like
statues, corpses, eggs and tins. I don't see a reason why figurines
shouldn't be part of this group; perhaps it was an oversight.
Move demon summoning and were creature summoning out of mattacku()
to a separate routine. Should be no change in behavior.
Also, redo several comments that came after what they applied to
rather than before, and reorder the file-scope prototypes to be in
the same order as the corresponding functions.
When rest and search refuse to operate because a hostile monster is
adjacent, include a reminder of how to force them to operate. Every
time if 'cmdassist' is On, or just once until after some subsequent
try actually does something.
This new rest and search behavior probably needs to be optional and
default to the old behavior. It isn't uncommon to deliberately rest
while adjacent to a hostile monster if also adjacent to a peaceful
one and trying to wait for Stun or Confusion to time out, or maybe
search while next to such a monster hoping to find a secret door to
run away through. A count prefix won't work and needing an extra
keystroke each time is going to be an annoyance.
When polymorphed into a nymph and melee hit steals items from the
target, the same-gender charm message vs opposite-gender seduce
message is being chosen by hero's base gender rather than nymphs
always being female. The seduce message used dynamic pronouns for
the target monster but the charm message used hardcoded She and her
for female nymph attacking female target. I'm not sure why hero's
base gender is used so left that alone; this changes charm message
to use dynamic pronouns that correctly match the target monster.
Losing all of your items in one go is really frustrating.
If you blow up your bag of holding, make the contents scatter around
instead of outright deleting them. This will destroy fragile objects.
When matching a terrain, allow using a "w" placeholder that matches
any solid wall:
For example:
local s = selection.match([[w.w]]);
would match all floor locations with a wall to the left and right of it.
The walls can be solid stone, horizontal, vertical, etc.
This applies to selection.match(), selection.filter_mapchar(), and
des.replace_terrain()
Generally speaking there's no reason to wait or search next to
a hostile monster, so let's just prevent those actions. You can
still do those commands by prefixing them with the 'm' prefix.
Instead of just picking up wands of undead turning when one or more
corpses are in hero's inventory, have monsters also pick those up if
hero has a cockatrice corpse in a carried container. And instead of
only zapping such wands (as defensive measure) when hero is wielding
a cockatrice corpse, also zap them (as offensive measure) if hero is
carrying any corpse in open inventory.
Testing a forthcoming extension of monsters using wands of undead
turning revealed a couple of pre-existing bugs. Previously only
noticeable if hero zaps self or breaks a wand of undead turning so
unlikely to have happened much.
"Your <mon> corpse comes alive" was given even if it was revived
as an undead. Also, it was "your <mon> corpse" instead of "one of
your <mon> corpses" even when one from a stack was involved. If
done by hero to self that message follows "one of your <mon>
corpses glows iridescently" so the comes alive message was ok but
verbose. Change that to "it comes alive" or "it reanimates" when
following the glow message.
when hero is wielding a cockatrice corpse. Wands of undead turning
aren't generated as starting equipment but they will now be picked
up if come across while the hero is carrying any corpse, and used
in preference to any other item when carried and non-empty and hero
is wielding a petrifier's corpse.
m_lined_up() was declared 'boolean' but returned 0, 1, or 2.
The 1 case isn't actually used any more. I changed it to 'int'
rather than 2 to TRUE; it could just as easily be the other way
'round.
Fixes#320
Avoid giving "you are back on the bottom" nearly every step when
moving around underwater.
Avoid "you are back on floor" followed by "you trip over <object>"
when fumbling in case that fumbling was due to being on ice when
taking the step to floor. Done for all fumbling rather than just
one-turn fumbling instigated by ice.
When moving from ice or water to ground, show "you are back on floor"
before listing objects at that spot instead of after.
I think there was at least one more thing but have lost track. At
any rate, 'mention_rate' potentially has a new set of bugs.
"You materialize at another location," was delivered while the
previous location still controlled line of sight. Very noticeable
if you started from underwater and landed on the surface in an area
which hadn't been mapped yet.
The fix to try to avoid messages about out-of-view objects taking
erosion damage made water_damage_chain() vulnerable to dereferencing
a null pointer, leading to a crash if you create a pool via wizard
mode wishing.
Eating a tin of one of the Riders and being life-saved or declining
to die would crash when trying to revive a non-existent corpse. An
old comment stated that since such tins were impossible it could
assume that it was dealing with a corpse, but wishing for tins of
the Riders is possible in wizard mode.
They can't be passed along to normal mode via bones because they're
changed to empty tins as bones are saved. So there doesn't seem to
be much point in allowing wizard mode wishing to create them, but
I've left that as is.
I got "The chain mail rusts." seemingly out of the blue, then when
moving around the corner of the building on Valk home level I saw a
spot of remembered ice be redrawn as water. Before that I checked
for any mapped objects (via ';' 'o' 'o' ... so I didn't overlook
anything; there were only a couple of objects shown on the map and
none of them were piles) and didn't see any remembered chail mail or
anything at all on that ice spot, so I'm assuming that it was carried
by a monster. I may be leaving out some steps in the call chain here:
melt_ice -> minliquid -> mondead -> m_detach -> relobj -> mdrop_obj
-> flooreffects -> water_damage -> erode_obj
erode_obj() uses bhitpos for visibility check of eroding objects not
carried by the hero or by a monster, with a comment expressing doubt
about doing that. It wouldn't have yielded the right answer for the
possible call chain here unless it got set by some monster activity.
I had been zapping a wand just before and bhitpos would have been set
to a coordinate I could see at the time, fooling erode_obj()'s check
if the value was stale.
Anyway, this only addresses objects eroded from flooreffects(),
water_damage_chain(), and fire_damage_chain(). There are lots of
other indirect calls to erode_obj().
Adds a new level init type which directly creates a maze,
optionally setting corridor width and wall thickness,
and removing dead ends.
des.level_init({ style = "maze", corrwid = 3, wallthick = 1, deadends = false });
When dual-wielding and you wield a different weapon, two weapon combat
was silently toggled off even when the new weapon was eligible to be
dual-wielded. If the verbose flag is On, explicitly tell the player
when wielding something toggles off two-weapon mode. Wielding '-' is
an exception because you already get told that you're empty handed.
There's a chance that a tactics-using monster (eg. arch-lich)
teleporting next to you on a full level would get booted off
into limbo. After that, if the monster tried using an item
in the same action you'd get panic "relmon: mon not in list"
Fix this particular case by checking monster mstate.
Other cases may lurk in other places that eventually call mnexto.
When dual-wielding and both weapons use the same skill, the weapon
feedback by ^X was inadvertently skipping the part where it would
tell the player whether either the weapons' skill or two-weapon
skill or both had already been trained enough to to be advanced.
Most of the diff is change in indentation.
Uncomments and makes available selection.gradient in Lua. (The backend C
code for this still existed, it just wasn't used.)
The only valid way to specify a gradient is with a table. I considered
adding non-table versions, but decided that there are too many
independent variables that can be optional. A non-table version, without
named parameters, would be confusing to read, especially since most of
the arguments are ints.
Also adds an impossible in the (possibly unreachable) case that
selection_do_gradient gets called with a bad gradient type.
Rather than spitting out an error code number that is not particularly
useful. The string contains the line number and the nature of the error,
which is much more useful for debugging or reporting an issue.
Report weapon skill in the ^X status section when dual-wielding,
The effective skill level is the lower of the weapon's skill and
two-weapon skill, separately for primary and secondary. It's a
much bigger chunk of code than most enlightenment/^X features so
I put it in its own routine.
Reject arrows and darts as candidates for wielding two weapons at
once.
Make the check for being able to two-weapon when polymorphed be more
robust. Instead of just testing whether the monster form's second
atttack is a weapon attack and then assuming that the first one is
too, test the first three to validate that at least two of those are
AT_WEAP. The existing code works but seemed fragile.
Get rid of a couple of unnecessary calls to set_twoweap() to clear
u.twoweap when using 'A' to 'take off' either weapon. setuwep() and
setuswapwep() don't do that, but they call setworn() which does.
Make the feedback when disarming with 'A' be more specific when you
are two-weaponing at the time either weapon is unwielded.
A couple of the new prototypes used 'char' where 'CHAR_P' is needed.
Also, move them out of middle of long block of command declarations.
I started to reorder the prototypes into the order in which those
functions appear in the file but gave that up pretty quickly.
The impetus for this was to avoid ugly constructions such as the one
below (none of which currently appear in vanilla NetHack):
mongets(mtmp, LONG_SWORD);
struct obj* sword = m_carrying(mtmp, LONG_SWORD);
if (sword)
/* do thing to sword */
Most cases where mongets is used discard the returned value (which used
to be the created object's spe); the only places that do use it are the
series of statements that give various human monsters armor and prevent
them from getting too much armor. These statements included hardcoded
constants representing the base AC of the armor, which would have caused
discrepancies if armor's base AC were ever changed.
With mongets now returning a pointer to the created object, it can just
be passed into ARM_BONUS instead, which covers both the base AC and the
enchantment. (It will also cover erosion, if anyone ever decides that
armor should rarely generate as pre-eroded).
The overall algorithm is not changed by this; human monsters should
receive armor with the same probabilities as before.
Another SliceHack feature. It's possible for you to eat the chameleon
tin and turn into a fiery monster that burns off the slime in its
natural form, either extremely luckily at random or if you have
polymorph control.
This buffs the blessed effect of the teleport scroll by providing the
reader control over their destination even if they lack teleport
control. This seems like it makes the blessed/uncursed distinction
actually meaningful, rather than mostly pointless.
Ported from SpliceHack, and generalized to all shapeshifters (Splice
only implemented it for chameleons). It's very aggravating when your
powerful but hungry pet chows down on a shapeshifter before you can stop
them and then turns into something much more useless, so this aims to
prevent that.
The extreme circumstances under which a pet will eat a shapeshifter are:
1. The pet is starving, and prefers polymorph to starvation
2. The pet's tameness is 1
The reasoning behind the second condition is that if you mistreat your
pet almost to the point of untaming it, it might want to take a chance
on turning into something that might get some more respect from you.
Practically, whenever this happens, this will result in the player now
owning a newly polymorphed and *still* nearly feral pet.
