In the code that checks for attacking the edge of the map, the m_at()
that was just introduced isn't at risk of using <0,0> because of the
way 'glyph' is initialized. But guard against future changes.
And I omitted this when checking the PR #914 commit in:
Closes#914
When fighting an unseen displacer beast mapped as an 'I' glyph on the
map, its typical ability to swap places with you was disabled and
replaced by it being treated like "thin air". This was because
execution reaches domove_fight_empty when the target swaps places with
you. Other than the displacement passive, this function is typically
only reached if there's no monster on the target square, so it prints
the "thin air" message and wastes a turn if you'd "expect" to attack
something (either because the player used an 'F' prefix, or because
there is an 'I' mapped on the destination square being moved into).
Hitting "thin air" seems like OK behavior for force-fighting a displacer
beast, since you are explicitly not trying to move into its spot (though
you could probably make an argument that the displacement should happen
even then, since it's the displacer beast initiating it), but the mon
being mapped as an 'I' doesn't seem like a good reason to disallow the
actual displacement from happening.
Don't treat an 'I' as "thin air" in domove_fight_empty if there's
actually a monster there, since it means there's a displacer beast
trying to swap places with you.
A couple other related changes: put an 'I' down on the map when an
unseen displacer beast swaps places with you, and use 'something' in the
'it swaps places with you' message when you didn't even realize there
was a monster there to begin with, so there's no context for the 'it' (I
used Some_Monnam at first, but the 'something' felt a little weird when
you were intentionally attacking an 'I' or warning glyph; this limits
the usage of 'something' further than Some_Monnam does).
Instead of using index() macro defined to strchr, use C99 strchr.
Instead of using rindex() macro defined to strrchr, use C99 strrchr.
If you want to try building on a platform that doesn't offer those
two functions, these are available:
define NOT_C99 /* to make some non-C99 code available */
define NEED_INDEX /* to define a macro for index() */
define NEED_RINDX /* to define a macro for rindex() */
Two years ago I modified the parsing for [section] labels for the
config file's CHOOSE directive to allow end-of-line comments, but
the code used had a logic error (don't think I can blame it on
copy+paste). It looked for '#' after ']' but allowed anything--
rather than just spaces--in between.
"[section-name]abc#comment" would become "section-name" as if the
trailing junk hadn't been present. Parsing that should produce
"section-name]abc" and get rejected as invalid.
Reported by entrez: disclosing inventory at end of game did not show
gold. Not mentioned: only for tty.
It was using the same window as gets used for perm_invent (although
not shown _as_ perm_invent because end of game turns that off) and the
default for whether to show gold is different for tty than for other
interfaces due use of experimental TTYINV from player's environment.
Force the end of game inventory disclosure to work the same as the
dumplog inventory listing and use a different window, by falsely
telling display_inventory() that a response is requested. Works but
the whole inventory mechanism has become quite convoluted.
When looking at the previous commit, I realized that my comment about
radius 1 was wrong. The original code prefers dismounting to spots
that are orthogonal to the steed's position over diagonal ones. It
doesn't say why.
I've implemented targetted dismount such that being knocked out of
the saddle will place the hero opposite the attacker in preference
to a random spot adjacent to the steed. If that opposite spot
isn't appropriate, the two spots next to it get tried.
In these map fragments, H is knocking mounted hero off of u. The
digits indicate priority of potential destinations.
|..... |..21.
|...2. |..u2.
|.Hu1. |.H...
|...2. |.....
If spot 1 isn't acceptable, both of spots 2 (in random order) will
be tried next. If those aren't acceptable either, it will try the
other 5 spots adjacent to the steed (the one of those with the
attacker will always be unacceptable). And as before, it none of
those work, it uses enexto() to pick a random spot as close to the
steed as feasible.
Not knockback: when dismounting due to polymorph, avoid diagonal
adjacent spots if hero's new form can't move diagonally. (The hero
can't already be in no-diagonal form because riding requires that
the rider be humanoid. I keep thinking the restriction is "can't
be polymorphed" but that isn't correct.)
The #showgold command now does mention known contained gold in your
inventory, so the various lines in the Guidebook which explicitly state
that it doesn't needed to be updated. Wish I had noticed this in time
to put it into the previous Guidebook patch I submitted, but what can
you do.
Reverts 690e072, which changed the various is_foo macros from this:
| #define is_elf(ptr) ((((ptr)->mflags2 & M2_ELF) != 0L)
to this:
| #define is_elf(ptr) ((((ptr)->mflags2 & M2_ELF) != 0L) \
| || ((ptr) == g.youmonst.data && \
| !Upolyd && Race_if(PM_ELF)))
This is a problem because g.youmonst.data is not unique to the hero:
the '(ptr) == g.youmonst.data' test will also be true of all player
monsters of the same role. For this reason, any of those player
monsters will be treated as sharing the hero's race, producing strange
results. For example, if the player is an elven ranger, any ranger
player monster generated will be considered 'elven' too (so will get a
to-hit bonus when attacking orcs, etc) -- but only while the hero is
unpolymorphed.
There are already other ways of checking the hero's race in addition to
her current polyform, most notably the maybe_polyd() macro. maybe_polyd
or something similar is already used in nearly all the cases where the
hero's race is being evaluated, meaning Race_if gets used instead when
the hero is in her natural form. So I think the check of the hero's
race in is_foo had very little effect except for the unintended
side-effects on player monsters.
In reviewing all the uses of is_{elf,dwarf,gnome,orc,human}, I noticed
only one case that relied on the hero-race-checking behavior. That has
been changed in this commit to use maybe_polyd (there's another 'raw'
is_human(g.youmonst.data) a few lines down, but it doesn't need
maybe_polyd since it already distinguishes between 'hero in nonhuman
polyform' vs 'nonpolyd or human polyform'). same_race(mondata.c) is
another case where &g.youmonst.data can be passed to is_foo, but
everywhere that calls it for the hero also calls your_race() or
same_race(&mons[Race_switch]) to handle the racial case.
Make changes similar to the suggested patch from entrez: support
for 'youmonst' as the monster passed to m_carrying(). This doesn't
change carrying(otyp) to call m_carrying(&g.youmonst,otyp) though.
Also, treat being on the Plane of Air or in an air bubble on the
Plane of Water similar to flying or levitating: wielded Giantslayer
(or carried loadstone) doesn't prevent knockback there.
Pull request from chasonr: remove NUL characters from constructed
prompt for Qt_yn_function(). I couldn't see any with Qt 5.11 on
OSX 10.11.6, but with some font(s) or Qt newer versions they were
visible as reported in issue #566 about 15 months ago.
Closes#909
The #wizborn command shows 'E' for an extinct species and 'G' for a
genocided one, but if a species first becomes extinct and then later
gets genocided, instead of showing both flags it stopped showing
either. I was going to add a second flag column and show 'E' and 'G'
separately but decided to stick with one column and display 'X' for
the unlikely 'both extinct and genocided' case.
More PR #882; give a different message for empty input than "such
creatures do not exist".
The new message mentions 'none' (with single quotes) as a potential
choice so recognize "'none'" as well as "none" to decline.
Reissuing getlin() with a different prompt wasn't reliably resizing the
X11 prompt widget. After a lot of hacking away at win/X11/dialogs.c I
eventually tried setting the response portion of the widget first and
got much better results, enough to throw away the tentative changes to
dialogs.c.
There's still a lot of room from improvement but I think it would need
to replace the ghostview prompting instead of trying to massage that.
