New timed sanity checking trying to validate a timer's map location
can't locate a timed object (in this case, an egg with a hatch timer)
inside a container carried by a migrating monster.
The case of the object being carried directly by a migrating monster
was handled, but one inside a container wasn't.
and having temporary stoning resistance timeout before finishing.
Issue reported by Umbire: hero was able to finish eating Medusa's
corpse safely after getting the message about no longer being
protected against stoning that is given when temporary resistance
times out.
The eating code was extending temporary resistance--when eating
something protected by such--to avoid just that. I thought this
was probably a message sequencing situation but it turns out that
the code was using touch_petrifies() to test the meal. It should
use flesh_petrifies() instead; Medusa doesn't pass touch_petrifies().
I didn't figure that out until after rewriting how the duration is
extended. The old way probably would have worked as desired with
the revised petrify test but I'm checking in the new version anyway.
Fixes#1186
If you wished for "lit candle" you'd get an unused candle that
is pre-lit but the feedback as it's added to inventory would be
"partly used candle (lit)". If snuffed out immediately, it reverts
to "candle" (ie, not partly used).
This fixes the first aspect: you will get "candle (lit)" added to
inventory. On the next turn it changes to partly used as expected.
The second aspect, reverting to not-used-yet after being lit during
the wish is left as-is.
Four kinds of timers are defined but only two have ever been used.
Have sanity checking complain if the other two occur or if 'kind'
doesn't match any of the four.
Also, replacing a perfectly normal use of isok() with an inline test
just to pacify static analysis feels like a slippery slope, so handle
that a little differently.
I reordered the shrink_glob timer to put all object timers together.
Unfortunately that warrants incrementing EDITLEVEL which invalidates
existing save files.
Yesterday I said that I'd done all of pager.c and part of objnam.c,
but I was talking about the prototypes in extern.h. This does more
of the same, this time for the local prototypes in pager.c so "all of
pager.c" should be accurate now.
Update several places where lazy lastseentyp[] might be an issue.
I think it isn't updated in a timely fashion when newsym() shows
a spot covered by an object or trap, but didn't manage to find any
cases where that caused a problem. This is more in the nature of
a precaution.
If MAKEDEFS_FILTER_NONASCII is defined (which config.h now does by
default), it will check data.base, rumors.*, and {various}.txt for
characters outside the range of ' ' through '~'. If it finds any, it
will warn about them and change them to '#'.
Tab handling is incomplete; the files that use tabs for indentation
will allow tabs anywhere, even though that's not wanted. That could
be fixed but doesn't seem particularly urgent. This is more about
spotting and repairing the special 3-char punctuation characters that
crept into data.base fairly recently.
Replace one recenly added 'croom' test with assert(croom != NULL);
keep the other one. Mark fill_ordinary_room() as requiring that its
first argument be non-Null. Check for malformed subroom data before
calling it.
Plus miscellaneous reformatting.
Fix some of the extreme verbosity for null vs non-null triggered
by mklev.c. dungeon_branch() never returns Null.
'#include <assert.h>' should probably be moved out of multiple .c
files and into cstd.h or some such but this doesn't do that.
The static analyzer complained about use of 'obj' maybe being Null
when used in an impossible warning, but that warning will never
appear for the case where obj is actually Null. Add an assert()
that should let it figure that out, and move the impossible check
inside the 'else' clause where the check matters. (Either of those
by itself ought to be adequate to pacify the analyzer.)
If a monster picks up an item thrown by the hero, change its 'how_lost'
flag from LOST_THROWN to LOST_STOLEN and pickup_stolen will be used
instead of pickup_thrown to decide whether to override pickup_types
and autopickup exceptions when hero eventually steps on it. If a
monster picks up an item dropped by the hero, change its flag to
LOST_NONE and autopickup will work normally without being overridden
by dropped_nopick. If item is flagged as stolen, leave it that way.
Moving over at item that's resting on ice gives a message about there
being ice present and then about the item, whether mention_decor is On
or Off. With it On, you'll get a message about being back on solid
ground as soon as you leave the ice. With it Off you wouldn't get
that at all if not levitating; that's the basic no-mention_decor
behavior for ice. However, if you were levitating, you would get a
delayed "back on solid ground" message when moving over some other
object, which might occur quite a bit later. Autopickup handling is
calling describe_decor() when the hero is levitating and some of that
wasn't appropriate for no-mention_decor.
This issue has been present since I first implemented mention_decor,
not introduced by recent back_on_ground() changes.
Reverse part of commit 8b5e9eadb1.
Shouldn't use get_obj_location(obj,...) to try to figure out if obj
has been deleted. That routine uses obj->where rather than scanning
the various object lists and doing that when obj has been deleted
would access stale memory.
A zap from a wand of striking shouldn't hit a drawbridge if it is
just passing over the span's spot when the bridge is closed. This
change matches the 3.7 behavior when the zap is performed by the hero.
It does hit if passing over that same spot when the bridge is open or
if it hits the portcullis spot whether open or closed.
Also, simplify the handling for the wand's destruction. It still
ends the zap early if that happens even though logically the rest of
the zap range should still be targetted.
Report was for an impossible "What an interesting effect (%d)" which
the fuzzer turned into a panic. Monster on the drawbridge zapped
toward the open portcullis, destroying the bridge and killing itself.
Wand was made of wood and burned up in lava under the fallen span.
Freeing the object zeroed it rather than leaving stale data, and the
zap continued while referencing freed memory that looked like it had
type STRANGE_OBJECT, triggering the impossible.
This will make a monster-induced zap stop early if a drawbridge
incident destroys the wand. That isn't the best possible fix
because the zap should continue despite the wand's destruction, but
at least it will now avoid triggering "intestsing effect".
When trying to reproduce the wand of striking "interesting effect (0)"
report, I tried wishing for lava under the castle drawbridge. That
wasn't handling drawbridges properly. This fixes wishing for moat,
lava, ice, or floor at a drawbridge span location whether the bridge
is currently open of closed. It also allows wishing for room or floor
or ground at room spots; that hasn't had much testing.
Wishing for furniture, pool|moat|water, or lava at an ice location
wasn't cancelling any pending melt timer.
ice_descr() was declared as returning const but returns its non-const
output buffer argument. Change to 'char *' so that wizterrainwish()
can capitilize that output without jumping through any hoops.
After the drawbridge was destroyed, playing an instrument on the castle
level while knowing the tune continued to offer a chance to play it.
Then nothing interesting happened even if you were close enough to the
former bridge for it to have been useful prior to the destruction.
I think the hero could also be given the tune as a divine prayer boon
after bridge destruction but I didn't verify that. The player might
not know that the tune is no good anymore, but the hero's patron deity
should.
Hide some of the details about new Stealth.
Streamline mon_break_armor(). Move replicated bypass handling into
m_lose_armor(). Also, eliminate a 'goto'.
Donning elven boots while riding and not already stealthy, you'd get
the message "you walk quietly" when not walking at all. Instead of
just changing the message, make riding a non-flying steed block
stealth. Riding a flying steed (or one you take aloft with an amulet
of flying) does not. It would have been quite a bit simpler to have
made riding anything block stealth, but the hard part is done.
Issue reported by mkuoppal: drum of earthquake triggers a sanity
check warning which the fuzzer escalated to panic.
Analysis by entrez. If a pit gets created next to a pool or moat or
lava, liquid might flow there and replace the pit. But the drum of
earthquake code assumed that the pit was still there. If there was a
monster there and it wasn't levitating or flying and it wasn't killed
by the liquid, it got marked as trapped even though the pit was gone.
'sanity_check' noticed.
With difficulty I was able to reproduce the impossible warning before
the fix, but the are a bunch of random factors at play. After the
fix I can't reproduce it again, but that's not a guarantee that it's
actually fixed. The analysis seems correct though and the fix is
based on dealing with that.
Closes#1170
Allow 'm p' to pay via menu when menustyle is traditional and to pay
via the old sequence when it's combination, full, or partial. Also
revise the "Itemized billing?" prompt to accept 'm' as well as 'ynq'.
Answering 'm' will switch from the old sequence to the menu (whether
you got to that prompt via m-less 'p' for traditional or 'm p' for
other styles).
There is a slight change in behavior here when collecting build-time
option information. If MAXOPT is too small, collecting will now save
MAXOPT lines and then skip anything that should come after. It used
to always keep the very last line, each time replacing whatever the
previous last line was, but would leak memory if that ever happened.
And after yesterday's "fix" it would try to keep that very last line
beyond the array bounds.
Pull request from entrez: add 'nopick_dropped' option of not pick up
items dropped by hero via autopickup and 'pickup_stolen' to picup up
items stolen from hero via autopickup, bypassing pickup_types and
autopickup_exceptions like existing 'pickup_thrown'.
This fixes entry commit also fixes the description of pickup_stolen.
Closes#1140
When known discoveries was displayed on a window of type NHW_MENU,
header lines sent to it via menu_add_heading() disappeared into the
bit bucket. Switching back to putstr() made them show up. But I also
changed the type to NHW_TEXT. A menu_add_heading() in artifact.c was
overlooked, and after the window type change that started triggering
a panic when '\' or '`a' was used while any artifacts were discovered.
Not sure how other interfaces were dealing with this.
Thinko in the reformatting, not triggered during testing because I was
using !CRASHREPORT. With it enabled, setting a watchpoint in gdb on
something unrelated resulted in nethack going into crashreport_init()
and never caming out. (I imagine that it would have eventually but 10
or 15 minutes with nothing noticeable taking place was unbearable, and
the program hadn't even really started yet.)
Fixup some of the inconsistently formatted code that has been
introduced recently or been building up for a while. Done manually.
I wasn't systematic except for looking for lines ending in '&' or '|'
(which wouldn't find such things if they're followed by a comment)
so there might be lots more. I changed a bunch of C++-style //...
comments to old style C /*...*/ so that they'll match the rest of
the core's code rather than because they shouldn't be used.
A couple of things I noticed while running umpteen tests for tty
perm_invent. Remove the update_inventory() from unmul(), and limit
the one that deals with seeing inventory when recovering from blindness.
Just a drop in the bucket overall, and the screen updates nearly
instantly for update_inventory() except when debugging perm_invent so
players aren't likely to notice this.
As part of the tty resize handling revision, code dealing with the
perm_invent window was moved out of tty_destroy_nhwindow() was moved
into a separate routine. The new routine would have been called for
a window of NHW_PERMINVENT, but WIN_INVENT doesn't have that type,
just ordinary NHW_MENU, so the cleanup wasn't happening, resulting in
a memory leak.
Silence a bunch of complaints from heaputil about freeing Null
pointers. The C standard allows that but it makes the data collected
about mallocs and frees not match up when nethack has MONITOR_HEAP
enabled.
opttext[] was given 120 elements but the MAXOPT macro used to limit
populating it was only 40. There happen to be exactly 40 lines of
runtime info--at least for my config--and the last slot was going to
waste, so the final dupstr("") at the end of build_options() wasn't
being tracked and freed.
It's interesting the whatever other memory checker is being used
failed to find something caught by old heaputil. Maybe the configs
running whatever it is are generating smaller options text?
I think this fixes all problems with the boundary boz drawn around
perm_invent. Also, if you enabled perm_invent in inuse_only mode
while there are already more items in use than would fix in the
available number of lines, it wasn't switching to two columns until
the next update_inventory(). And the new color handling wasn't
incorporate into tty_refresh_inventory() so after a corner window
clobbered some of perm_invent, it got redrawn but without color,
again until the next update_inventory().
With any luck this fixes more bugs than it introduces....
Make term_start_color() more versatile. If it gets passed NO_COLOR
then it performs term_end_color(). Should be able to streamline
some of the color handling this way although this hasn't done so.
Revise the tty permanent inventory window's in-use mode to be able to
switch back and forth between one full width panel and two side-by-side
half width panels on the fly as needs dictate.
A lot of trial and error involved but I think it has reached a state
where it is reliable, and the smaller number of lines required at
present can probably be viable for actual usage. At the moment it
requires at least 10 extra lines below the standard tty mesg+map+stat
display, 34 lines total for statuslines:2 or 35 for statuslines:3.
The top and bottom of the 10 or more extra lines get drawn as boundary
lines using wall characters, leaving 8 lines for full width or 16 half
lines when 8 isn't enough. If more that 16 items are in use (maybe
lots of lit candles forced into separate inventory slots or a
menagerie on leashes), the excess get skipped. However, it will use
more lines if they are available. Prior to a few days ago it was
requiring 17 extra lines and able to show 15 items as full lines only,
unable to take advantage of more lines when available.
Allow perm_invent to be enabled with 1 less line when statuslines==2
by not reserving a line for statuslines==3. If the player changes
that from 2 to 3, the perm_invent window is torn down and repositioned
one line lower if that will fit. If it won't fit, it won't reenable.
Temporarily(?) allow perminv_mode==InUse to be enabled with room for
only 8 lines instead of requiring 15. It will use more than 8 if are
more rows.
8 happens to be the amount (via 1+21+3+(1+8+1)) that will fit within
35 lines which is the biggest I can make fit on may laptop without
switching to a smaller font. Switching is a nuisance, worse than that
for the font tiny enough to fit the full perm_invent.
ToDo: if in-use won't fit in the number of lines allotted, switch to
two columns before resorting to ignoring the excess.
Maybe: allow fewer lines for full perm_invent too and use the '|'
command to scroll them. Might be too clumsy to be worthwhile.
A few add_menu_heading() calls were added to the '\' and '`' commands
which use a text window rather than a menu. For some reason they were
using create_nhwindow(NHW_MENU) but only populating it with text so
the heading lines sent as menu entries were lost. (Might panic with
Qt; I didn't check.)
For the accessories section of '*' and perminv_mode=InUse, show the
ring on main hand first (after amulet) and the one on off hand after
(before blindfold). Main hand ring is more significant due to the
potential of a one-handed weapon becoming cursed, preventing it from
being removed.
Report was that converting a novel into a blank spellbook via water
damage resulted in a spellbook of blank paper that increased weight
when put into a bag of holding.
Spellbooks weigh 50 units but novels were defined with a weight of 0;
when one was created, a non-zero weight of 1 got assigned. Blanking
it didn't update the weight; that stayed at 1. Putting it into a
container reset the weight to match the new type: spellbook of blank
paper, so its weight increased.
Do that when blanking rather than wait until a container might fix it
up. If it is already in a [possibly nested] container, update that
container's weight too along with any outer ones.
This also changes the base weight of novel from 0 to 10, so it still
gets magically heavier when turned into a spellbook of blank paper.
(The alternative seems to be to destroy it instead.)
The Book of the Dead weighed only 20 units which seemed odd to be so
much less than a spellbook. This changes that to 50 to match those.
If a monster fled from the hero by intentionally jumping into a vault
teleporter located in a niche which was still hidden and the hero
saw it happen, the trap would be mapped but the niche would remain as
a secret corridor spot. The hero couldn't move onto the trap until
searching or wall kicking or other map disclosing activity converted
the spot into regular corridor.
Trap doors in hidden niches did already change the secret corridor
into normal corridor to unhide the trap's spot, but only if the hero
saw it happen. Now the terrain change occurs even if hero doesn't
see it; only mapping the trap depends on that.
While testing the fix, I noticed that a monster jumping onto a vault
teleporter was teleporting randomly rather than being sent to the
vault, unlike when triggering such a trap by accident. The code has
changed for 3.7 but this bug was already present in earlier versions.
There's no need to process windowtype a second time after options
parsing. The sequence set windowtype, process options, set
windowtype again was intended to deal with the options setting it
to some other value, but there's a flag available to disable that
from happening.
Remove a stale comment and update one or two others.
Remove several trailing spaces.
Change the data type of a couple of variables from schar to int and a
couple others from int to coordxy.
Redo a nested 'if' sequence to un-nest; results in a bloated diff due
to reducing indentation for a big chunk of code.
Change monster movement to use u_on_newpos() when swallowed hero's
location moves along with engulfer so that a clipped map will be kept
up to date.
u_on_newpos() bit: player can't see the map while swallowed so hero
can't see objects on the map, hence shouldn't gain more info about
any generic objects if engulfer moves closer to some.
At the moment engulfer movement is manipulating <u.ux,u.uy> directly
rather than going through u_on_newpos(), but that's about to change.
Otherwise a clipped map doesn't get updated properly until the hero
is eventually expelled.
Pull request from argrath: reduce the size of m_move() and eliminate
several goto's by splitting off 'goto postmov' into a separate routine.
Some of the comments have ended up out of date, referring to 'above'
or 'below' for stuff that moved away. That can be fixed up later.
Closes#1139
Pull request from entrez: when dipping gloved hands into pools or
fountains to wash them, subject those gloves to water damage. Also,
showing '-' as a likely candidate when picking an inventory item to
dip while at a pool or fountain location didn't work if player had
the 'force_invmenu' option set.
Closes#1141
Pull request from entrez: a 3.6 problem with mimics coming out of
hiding when they shouldn't was indirectly fixed by an earlier change.
Fix it directly.
Also, add a fixes entry since there didn't seem to be one.
Closes#1149
Issue reported by elunna: hero witnessing a wand of striking being
zapped by a monster didn't have that type of wand become discovered.
Monsters observing hero resisting--or failing to resist--the effect
on hero didn't learn about target's current resistance capability.
Barely tested.
Fixes#1157
For
|Autopickup what?
| a - amulets
...
| A - all classes
prevent invert all and set all from setting the 'A - all classes'
entry. For invert, toggling it is wrong. For set, suppressing it
from being set is academic since all other entries get set.
Simplify the notes about what happens when no classes are selected,
and when autopickup is On about how to not autopickup anything at all.
Add one when it's Off, about how to make the chosen classes matter.
Pull request from entrez: if breaking a wand of digging or playing
a drum of earthquake destroys an altar, provoke the god's wrath.
Likewise for shop damage, have the shopkeeper demand payment for
repairs.
Also revise the handling for some digging messages.
Closes#1137
drop_uswapwep() avoided calling makeplural() in a pline which also
had a call to Yobjname2(), with a comment about the possibility of
clobbering its static return buffer. uswapwep might be a stack that
results in Yobjname2 indirectly calling makeplural to produce a
plural description. But makeplural() has used xname's pool of obufs
since before uswapwep became a thing, so the code was evidently
cloned from some other out of date usage.
I was going to just move the makeplural() call into pline() but it
dawned on me that uswapwep must be one handed, so don't pluralize
hands at all. And since uswapwep might have the same description as
uwep, explicitly mention "left hand" to distinguish.
When testing 'm )' I noticed that weapon and alternate weapon weren't
offering the chance to toggle two-weapon mode. When already on,
providing it as a choice to toggle it off is simple, but when at is
off that isn't the case. There are lots of reasons why attempting
to toggle it on might fail and it is silly to offer as a choice if
failure is sure to occur. This tries to filter out the majority of
reasons why the player can't toggle it on when deciding whether to
include 'X' as a choice.
Make the various item-in-use commands put up a menu--which allows
choosing an item for context-sensitive item action--if/when preceded
by the 'm' prefix. Some of them do that even without the prefix ('*',
'[', or '=' when more than one ring is worn). By default '(' shows
primary weapon, then secondary one if dual-wielding. 'm (' shows a
menu of primary, alternate whether dual-wielding it or not, and quiver.
character_race() was going out of bounds when scanning the races[]
array, relying on a field value that the fencepost entry didn't set.
This incorporates the previous fix for UNDEFINED_RACE but also changes
character_race() to not care about that anymore.
If any items are in use and hero isn't wielding anything, include
| - bare hands
in the primary weapon slot of the display of used items as an alert.
More useful for perm_invent than for #seeall.
If no items at all are in use, continue to show "not using any items"
without any specific weaponless alert.
When sortloot() is called for inuse_only, pass a filter that screens
out items which aren't in use so they won't be needlessly sorted.
For '*' and for persistent inventory with perminv_mode==inuse, show
the items in a specific order and within four labelled groups rather
than within their object classes:
|Accessories
| amulet
| right ring
| left ring
| blindfold
|Wielded/Readied Weapons
| primary weapon
| alternate or secondary weapon
| quiver/ammo pouch
|Armor
| suit
| cloak
| shield
| helmet
| gloves
| boots
| shirt
|Miscellaneous
| lit candles and/or lamps
| attached leashes
The accessories come first due to the default 'packorder' position
for amulets; weapons before armor likewise. If you wield a potion or
quiver some gold, those non-')' items will appear in the weapons
section since the ordering is based on slot rather than object class.
Rebuild doc/*.txt (other than Guidebook) with 'nroff -man -c -Tascii'
rather than just 'nroff -man' to prevent it generating non-ASCII
characters for hyphen, aprostrophe, single and double quotes, long
dash, possibly others. Also preprocess with '--grep-define ALLDOCS'
so that a few parts of the text don't end up being specific to the
local configuration.
The next time they're rebuilt they'll probably be subject to the
ping-pong effect of inserting padding spaces for justification
(alternating right-to-left vs left-to-right as intended but starting
with different parity so lots of gratuitous changes) since my quite
old version of groff triggers that for Guidebook.txt.
Pull request from argrath would have made sure that an uninitialized
buffer wasn't used after choose_classes_menu() issued an impossible
warning, but there was no point in continuing if bad (or not yet
supported) arguments were passed, so panic instead. Bypass the pull
request's commit because it would have been immediately replaced.
Closes#1146
Macros to conditionally include color fields in defsyms[] and objects[]
are no longer needed. The one for mons[] was already gone but traces
were present in a comment.
When picking up multiple items (or looting multiple items) in one
operation, only show encumbrance for the first item that causes that
to change instead of complaining about non-zero encumbrance on every
item. The very first item is treated as if it caused a change, so
you get "you have a little trouble lifting <obj>" even if you were
already burdened, same as before.
Only lightly tested.
Sync with decl.c. dbridge.c never had anything to do with these
variables. They were part of decl.c before they got collected into
struct g, then split among struct ga to gz. (This only fixes up
the comment in gl; there may be more, possibly quite a few more.)
These might be better classified as /*dungeon.c*/ although they
weren't defined there.
Pull request from AndrioCelos: for feedback during pickup, add a
separate message from stressed instead of sharing the burdened one
and issue messages at higher encumbrance levels.
This 'tweak' will probably need more tweaking to reduce verbosity
when picking up multiple items in one operation.
Closes#1135
"engraved part of a room" and "engraved part of a corridor" sound
silly. Change to "engraving in a room" and "engraving in a corridor".
Still displayed to player as just "engraving".
An orhpaned wintype.h tweak got dragged in. Renumbers to_core_flags.
In the past couple of days the code for '/' and ';' to examine
objects was changed to handle ROCK_CLASS differently (as part of
revising looking at map spots showing the engraving symbol). It
could potentially set up a static buffer in the object classes loop
and then overwrite that when processing another class. I couldn't
trigger any feedback anomalies, even when changing bouldersym to
various values including class characters both before and after '`',
but this redoes the suspect code to make it more robust.
Also, refine the test for whether a screen symbol matches an object
symbol.
The other three elemental planes go all the way to the map edges.
Fire was 76x20 rather than full 79x21. This adds new two columns on
the left (necessitating some coordinate adjustments) and one on the
right plus one new row on the bottom. Not particularly interesting,
just padding.
With CLIPPING disabled you should need a terminal or window with at
least 25 lines to change the 'statuslines' option from 2 to 3, but
it was being allowed on tty when there were only 24 lines available.
I think the other interfaces always have clipping capability enabled
so aren't affected.
Not many level maps extend to the bottom row (line 22 for a 1-based
count) so it wasn't likely to be noticed during play. That points
that maps which don't use all rows and/or all columns could get by
without clipping by adjusting their position. However, implementing
adaptive clipping is not something that I'm going to try to tackle.
Issue reported by entrez: on tty, ^C while a menu was open followed
by 'yes' to "Really quit?" would lead to a bad window panic.
Brought on by screen erasure changes included with recent SIGWINCH
(window resize signal) changes.
Closes#1145
'/ e' (or '/ `') lists nearby engravings (including headstones) that
the hero has read or felt (even if currently covered up) or can see
on the map;
'/ E' (or '/ |') lists all such on the level.
If the hero remembers an engraving and then monsters scuff it out of
existence, it will magically disappear from the list of remembered
engravings when deleted. I don't think that's worth bothering with.
[During testing, my pet seemed extremely reluctant to step on a
corridor engraving. That could have been coincidence but it seemed
to keep happening until I moved so close that it had no choice. I
wasn't carrying tripe.]
Report headstone engraving when using farlook to examine a grave:
| a grave (grave whose headstone reads: "foo")
or
| a grave (grave whose headstone you haven't read)
Make the farlook of ordinary engravings operate more like farlook of
other things:
| a boulder or a statue or an engraving (engraving with text: "bar")
rather than
| a boulder or a statue or an engraving with text: "bar"
The "or a statue" phrase will now be suppressed because statues aren't
shown as backtick anymore, so the parenthesized form isn't quite as
long as it would otherwise have been. If OPTIONS=boulder:symbol is in
use, the "a boulder" part will be gone too.
| an engraving (engraving with text: "bar")
or
| an engraving (engraving that you haven't read)
Make quicklook include engraving text. It's quick because it doesn't
ask the player to pick additional spots or whether to look up relevant
data.base quote, not because it skimps on useful information.
Autodescribe still does not include engraving text.
When using the 'm' prefix with #overview to get a menu of visited
levels and then picking one to annotate, replace the generic prompt
"what do you want to call this dungeon level?" with more specific
location information. Location details are visible while within the
menu but as soon as you choose something that goes away.
Pull request from entrez: when issuing the "welcome back" message
when restoring, print the current level's player-suppliedannotation
if there is one. Doesn't show automatically generated annotations
like "Oralce of Delphi" or "a sink" or "stairs to the Gnomish Mines".
Closes#1142
'm O' is a prime candidate for using ':' to select a menu item since
you can use that to avoid scrolling through many pages, but typing ':'
would immediately overwrite two or three lines of the menu with a
status refresh. curses doesn't suffer from this problem. X11 and Qt
show menus in separate windows do don't either. Not sure about WinGUI.
I think that this may have been reported in the past, but if so I don't
recall by whom, or why it wasn't addressed.
If the value is "no color&none" report it as "no-color&none" in 'm O'
and for #saveoptions.
Allow "OPTIONS=menu_headings" without any color or attribute value to
mean "no-color&inverse" as it once did before the player could choose
which attribute or color was supported, and matching the default used
when 'menu_headings' hasn't been specified at all.
Accept "OPTIONS=!menu_headings", meaning "no-color&none".
Explicitly reject "OPTIONS=!menu_headings:anything". It was rejecting
that due to blanket rejection of negated option, but reporting "can't
both have a value and be negated" whether there was any value present
or not.
For preselected menu entries when interactively choosing a new value
via the submenu of 'm O', use the current color and attribute rather
than NO_COLOR and ATR_NONE.
Simplify suppression of highlighting for menu header lines during end
of game disclosure. Didn't actually affect as many things as I was
expecting.
Plus a bit left out of the optfn_dogname() parsing commit.
Get rid of all the unnecessary 'if (!opts)' checks if the optfn_xx()
routines.
Replace the replicated contents of optfn_catname(), optfn_dogname(),
and optfn_horsename() with a common routine. optfn_dogname() was
different from the other two for no discernable reason. Player can
no longer assign the name "none" to an initial pet via RC file,
although there's nothing preventing doing so with C/#name command.
Pull request from argrath: optfn_pickup_types checks 'opts' for
whether it is Null after having already used it without checking.
Remove the unnecessary test.
Closes#1132
The submenu of 'm O' for recently added option 'perminv_mode' didn't
have color 0 changed to NO_COLOR. On tty the entries came out blue,
on X11 they were nearly invisible. Qt and curses didn't seem to care.
I checked all the add_menu() calls in src/*.c and managed to refrain
from the impulse to reformat, mostly.
Pull request by entrez: have monsters and the hero use the same code
when deciding whether to destroy a missile that hits a monster after
being thrown or shot.
Closes#1129
I used ^G to create a monster and specified "invisible owlbear". I
then got "An owlbear appears next to you." Except it didn't; it was
invisible and I lacked see-invisible. I imagine that newsym() was
called for the new-yet-invisible monster, but that remained buffered
and was gone overridden by the time pending map update got flushed
at some point after the monster was made invisible.
Add a new makemon() flag to turn a newly created monster invisible
during its creation, before "monster appears" message is delivered.
Since that message will now be suppressed in this situation, use the
cursor-flash hack that indicates where the new, unseen monster got
placed. Creating "1000 invisible <mon>" is something you probably
won't do twice.
Pull request from entrez: hero walking over a zombie's burial site
will only disturb it if meeting a minimum weight threshold.
Update several weight macros to be 'unsigned', matching mons[].cwt.
[I'm not sure about this one. 'unsigned short' promotes to 'signed
int' these days on most platforms.]
Closes#1125
PatR