Have the config error reporting routine check whether the message
it's delivering already has end-of-sentence punctuation instead of
adding that unconditionally.
When naming the weapon in the livelog message for breaking "never
hit with wielded weapon" conduct, avoid xname() because it includes
"<item> named <something or other>". That's partly censorship and
partly keeping the message from being longer than necessary. Long
messages on tty cause '#chronicle' output to become ugly.
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
...because I think it would be interesting to see how many monks break
it with a pick-axe.
Also fix a bug related to logging the conduct:
* If the first hit was a joust that didn't kill the monster, the
conduct would be double-logged.
I lifted the call to first_weapon_hit() out of mhurtle_to_doom() in
order to log the weapon before it broke.
Make the trap routine claim the trap killed the monster even
though it was drowning that did it, otherwise callers cannot
rely on the trap routine return value.
When a monster with innate teleporting stepped on a fire trap on ice,
the ice melted and the monster teleported away before falling
into the pool. If the monster's new location had a trap, the code
tried to access the deleted fire trap.
Too many negations for my brain to cope with. I've tested travel
properly this time, but not re-tested running (which shouldn't be
affected by this code).
Pull request from entrez: context-sensitive help. During the
quick farlook command (aka #glance), if the player types "?" to
ask for help don't show "prompt for 'more info'" among the actions
performed for response ".". (":" still mentions that because it
does show 'more info', if some is available, when using ";".)
Closes#811
When using #glance, the player is never prompted about whether she wants
'more info' about something on the map, even if flags.help is true and
she has pressed '.' -- the 'more info' prompt is exclusive to #whatis.
getpos_help already changed its description of '.' based on whether
'help' was on or off; adjust those criteria so that the description of
the 'more info' prompt is only included for #whatis, where it is
actually relevant.
I recently looked at the help while using #glance and got confused
about why the 'more info' prompt was never appearing, so hopefully this
should help forestall that sort of thing. #glance also prompts only
once, so there's some other information about "moving to another spot"
in the help text which is not relevant -- that could definitely be
addressed as well but I think it's less likely to be confusing, so I
didn't bother with it in this commit.
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
Commit 32234b1d in 2003 mentioned in its commit message that pet dragons
shouldn't be able to eat underwater food items. This was mostly true:
non-swimming pets wouldn't select underwater food as a goal, and
wouldn't spend an action eating something unreachable on their current
position. But the "combined eat and move" case in dog_move didn't check
could_reach_item, so if a non-swimming pet happened to move to a spot
with underwater food for some reason, they could eat it on that turn
anyway. This commit should close this loophole and prevent non-swimming
monsters from eating underwater food (or other unreachable food) even if
they happen to fly over its position.
A comment in allow_category states that if gold is explicitly selected
as a category, it should be included in the results regardless of what
other BUCX filters may have also been applied. That makes sense to me:
there's only one thing in the gold category, and it always has the same
BUCX status, so it's pointless to try to "filter" the gold category with
a BUCX filter. Considering it a "also add gold, on top of the filtered
results" category adds utility.
However, other categories which may include gold (specifically
justpicked; unpaid is in the code too, but that can't actually happen
in-game) were treated the same way: if the category included gold, no
filter could exclude it. As a result, if the hero had just picked up
gold, 'P'+'C', 'P'+'U', 'P'+'X', and 'P'+'B' all showed the just-picked
gold pieces -- there was no way to filter justpicked to exclude gold
the BUCX categories. This approach made less sense to me: justpicked as
a category may include gold, but filtering by BUCX actually has utility
there, and selecting it doesn't carry a "show me gold in addition to the
other filtered items" implication.
Maintain the same special treatment of selecting the coins category, but
drop it for justpicked and unpaid. In those cases whether gold is
listed in the justpicked result will depend on it not being filtered out
by the selected BUCX categories (and which one it belongs to, in turn,
depends on the 'goldX' option).
Just-picked-up gold was included in the list of items in the just-picked
category for most category-based menus like 'D' or #loot, but special
handling of gold for 'I'/#inventtype (to accomodate the 'goldX' option)
caused it to be excluded from consideration as a just-picked item.
Include recently picked up gold in 'P'/justpicked when doing type
inventory, consist with other category-menu-based actions.
Pull request from entrez: changes in symbol handling rendered the
'wizmgender' debugging option non-functional. Get it working again,
and when it's enabled have doname() list the corpse or statue gender
formatting those types of items for inventory or other display.
Closes#807
Add another use to wizmgender: when it is enabled, include the gender
specified in corpstat flags in the name of a statue, corpse, or
figurine, since it can influence various things but otherwise remains
invisible (for monsters without gendered names). A little while ago
lichen corpses weren't stacking because, despite being a neuter monster,
the corpses they produced were being flagged as female or male; this
could be useful for debugging issues along those lines.
The wizard-mode option to highlight female monsters stopped having any
in-game effect after cb0c21e. Formerly it caused female monsters to be
highlighted with a red background (red color + inverse); this commit
uses inverse video only without overriding their color. Ensuring the
color override works consistently with the ENHANCED_SYMBOLS 24-bit color
doesn't seem worth it for what is a very niche debugging option, and I
think inverse video should probably suffice.
It also used to be a TTY-only option, but this enables it in curses as
well.
From entrez, then modified possibly beyond recognition: don't run
or travel onto lava even with known safe lava-walking because that
isn't 100% safe. But if already on/over lava, allow moving onto
adjacent lava in that situation.
Change the inner workings of the experimental TTY_PERM_INVENT.
Switch to delivering the content to tty for the experimental perm_invent
via the existing window port interface (start_menu(), add_menu(), end_menu).
This also adds a new window port interface call ctrl_nhwindow() for
delivering information to the window port, and/or obtaining specific
information from the window port. The information and requests can
be extended as required. To be documented later once the changes settle
down.
Due to the intrusive nature of these changes and the possibility of
some bugs in the new code, I'm going to leave TTY_PERM_INVENT commented
out in the repository for a day or two. Anyone wishing to test it out
can do so by uncommenting TTY_PERM_INVENT in config.h.
should be skipped when current bite finishes meal
Pull request from entrez. Treat resuming an interrupted meal with one
bite left similarly to starting a meal that only takes one bite.
Closes#804
There was already handling in place to prevent showing the "continue
eating?" prompt for one-gulp food (like a wraith corpse), since the hero
would finish eating the food on that turn regardless of what the player
answered to the prompt. Resuming an interrupted multi-bite meal with
only a single bite remaining had the same problem, but wasn't accounted
for in the special "one gulp" handling. Modify the condition so it
checks for the number of bites remaining in the food, not the number of
bites total, and show the prompt only when there's more than one bite
left.
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
If you have a known source of water walking (i.e. are wearing formally
IDed water walking boots), allow travel to path you over water and allow
running over water. A transition from land to water will still cause
the hero to stop in modes other than the shift+dir "move until you hit
something" running mode, so that you don't careen across the entire
level unless you really want to.
Also, fix running over water when levitation or flying is equipped.
This stopped working after f88dce6970, only allowing the hero to move
one square at a time. And prevent travel from pathing the hero into a
wall of water even if flying or levitation is equipped, since they don't
allow you to bypass that terrain.
by monsters is based on their weight
Pull request from entrez: instead of straight 2/3 chance for a monster
to trigger a landmine, base the chance on monster's weight.
Closes#801
The 1/3 likelihood of a monster setting off a landmine seemed a little
arbitrary to me, especially in that it applied equally to all monsters,
from giants to insects. Change the flat 33% chance to one based on the
monster's body weight, so that lightweight monsters have little to no
chance of setting off a mine, with the likelihood increasing from there
with the monster's weight.
With a trigger weight of 400, as it is in this commit, a dingo has a 0%
chance of setting off a landmine, a gelatinous cube the same 33% chance
as before, an elf a 50% chance, a human a 72% chance, and something the
size of a dragon (ignoring the reduced likelihood for flying monsters) a
91% chance.
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.
Change the regex_error_desc() interface. Have the caller pass in
a pointer to a buffer of at least BUFSZ characters and have
regex_error_desc() populate that. No need for static buffers or
extra dynamic alloction.
Also, change it to never return Null. None of its callers were
checking for that and could have passed Null to config_error_add()
or raw_print(). printf("%s", NULL) produces "null" on OSX but other
systems would probably crash if a Null result ever actually occurred.
The error explanation returned by cppregex included a trailing period.
config_error_add() adds one, so the message ended up with two. Have
regex_error_desc() check for final period and strip it off if found.
(My test case used a menucolor pattern of "[" which triggers an error
about mismatched brackets.)
Reformat cppregex.cpp; treat 'extern "C" {' as if it isn't introducing
a nested block. Fix the '#include <hack.h>' that 'make depend' was
ignoring.
One of the drivers of this change was that screen coordinates require a
type that can hold values greater than 127. Parameters to the window
port routines require a large type in order to be able to have values
a fair bit larger than COLNO and ROWNO passed to them, particularly for
their use to the right of the map window.
This splits the uses of xchar into 3 different situations, and adjusts
their type and size:
xchar
|
-----------------------
| | |
coordxy xint16 xint8
coordxy: Actual x or y coordinates for various things (moved to 16-bits).
xint16: Same data size as coordxy, but for non-coordinate use (16-bits).
xint8: There are only a few use cases initially, where it was very
plain to see that the variable could remain as 8-bits, rather
than be bumped to 16-bits. There are probably more such cases
that could be changed after additional review.
Note: This first changed all xchar variables to coordxy. Some were
reviewed and got changed to xint16 or xint8 when it became apparent that
their usage was not for coordinates.
This increments EDITLEVEL in patchlevel.h
