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.
NetHack has historically had problems (both in terms of interface
and in terms of gameplay exploits) caused by unidentified items
not stacking with identified items. The 3.7 change to cause items
picked up by monsters to become unidentified has exacerbated this,
e.g. there's an undesirable strategy in which players give
ammunition to hostile monsters in order to unidentify it, allowing
it to stack with other unidentified ammunition so that the whole
stack can be enchanted with a single scroll.
This commit makes it possible to stack items with different
identification statuses (unles Blind), in effect causing the
unidentified items to be identified by comparing them to the
identified items (this is consistent with the mechanic via which
two stacks of unidentified items can be determined to be the same
as each other). The hope is that this will prevent any gain from
exploits involving intentionally unidentifying (or intentionally
failing to identify) items, that it will prevent interface clutter
caused by (e.g.) a Ranger's main projectiles becoming partially
unidentified as a nymph picks them up and subsequently failing to
stack, and that it will reduce the incentive to backtrack to an
altar to merge, e.g., a stack of formally-known-uncursed and a
stack of informally-known-uncursed food rations to stack.
'/ 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.
Sometimes I annotate a level with a note like "watch out, chameleon
below", which is useful to remind myself of some danger or thing to
remember when returning to the level -- but if saving and restoring on
the level itself there's no reminder of that annotation. If you restore
on a level with an annotation, print it as part of the "welcome back"
message.
Apparently, color option is meant to apply only to the map, so doesn't
need to appear here, and the reference on the previous commit was wrong.
<curses guicolor>
on: map, menu items, menu headings, menu prompt/title can all feature color, as can
menu borders, menu-selector letters.
off: map, menu headings, menu prompt and menu items (menucolors on) can still feature color,
but all other non-map features such as menu borders, menu-selector
letters will not have color.
<menucolors>
on: menu items can have colors if they match one of the regex in config
file; menu headings, menu prompt can also be in color (based on menu_headings option).
off: menu items won't have colors, but menu headings, menu prompt still
will feature colors (based on menu_headings option); those are not impacted by turning
off menucolors.
<color>
off: map, menu items, menu headings, menu prompt/title all, everything should have color suppressed.
<curses guicolor>
on: map, menu items, menu headings, menu prompt/title can all feature color, as can
menu borders, menu-selector letters.
off: map, menu headings, menu prompt and menu items (menucolors on) can still feature color,
but all other non-map features such as menu borders, menu-selector
letters will not have color.
<menucolors>
on: menu items can have colors if they match one of the regex in config
file; menu headings, menu prompt can also be in color (based on menu_headings option).
off: menu items won't have colors, but menu headings, menu prompt still
will feature colors (based on menu_headings option); those are not impacted by turning
off menucolors.
It was impossible to select entry 62 in the allopt[] array
from the 'm O' menu, apparently because of a collision with
the ascii value of a question mark.
Entry 62 was currently the guicolor option.
This implements the mechanics to use the ctrl_nhwindow() interface
capability to pass down a setting change from the core to the active
window port, without resorting to accessing a core global variable
from within the window port, and without altering the interface..
The passed setting is honored in the tty and curses window ports.
X11 and mswin receive and store the values, but no implementation
to change the menu prompt style is there yet.
Qt does not store the values or have an implementation.
The setting change is done in allmain.c immediately after
creating the WIN_INVEN window.
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.
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.
Remove menu_color support from the window port side of the interface.
The window port just has to honor the color parameter that was added
to the add_menu() interface definition in June 2022 commit
2770223d10, and let the core-side of
the interface handle things.
To that end, this does the following:
Removes the #define of add_menu() from include/winprocs.h and add a
real core-side add_menu() function to windows.c which acts as a
trampoline to the window port win_add_menu() function, while providing
a single location to adjust the parameters passed to the window port
function. get_menu_coloring() is now called in there.
Moves get_menu_coloring() from options.c into windows.c and makes it
static.
Removes all the calls to get_menu_coloring() from the tty, Qt, X11,
curses, and win32 interfaces and adjusts their code to simply honor
the color parameter in add_menu, similar to what the menu_headings
change from earlier today did.
Instead of just accepting an attribute, it's now possible to
use a color, or both color and attribute, for example:
OPTIONS=menu_headings:inverse
OPTIONS=menu_headings:red
OPTIONS=menu_headings:red&underline
Default is still just inverse.
This lets the player change the menu heading color without
needing to use menu colors for them.
Also makes it so the core uses NO_COLOR instead of 0, for all
the menu lines which don't have any prefedefined color.
Tested for tty, curses, x11, qt, and win32
There is a comment above the function indicating that it should be
aligned with hero ammo breakage, but this wasn't the case. One big
difference is that any monster-thrown or -shot object would be deleted
unconditionally if it hit another monster trapped in a pit. I don't
know why that was in there, but it's not present in hero ammo breakage
chances, and it meant that a monster could sling the Mines luckstone at
the hero, hit a monster in the pit, and permanently lock the hero out of
getting the luckstone (as just happened to a player during the current
tournament). This pulls the hero breakage rules out into their own
function and uses that for monster breakage as well, to make sure they
are aligned. I also refactored drop_throw a bit to reduce the number of
separate variables tracking whether the object was deleted (was create,
objgone, and retvalu), and changed its (and ohitmon's) type to boolean.
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
cg.zeroobj was originally added (under its previous unprefixed name)
for providing a one-line way to zero out the fields of a struct obj.
struct obj tempobj;
tempobj = cg.zeroobj;
initfn(struct obj *otmp)
{
if (otmp)
*otmp = cg.zeroobj;
}
More recently, the address of cg.zeroobj began to be used as a return
flag to indicate some things, but the 'const struct obj zeroobj' wasn't
an ideal fit for the purpose and required a number of casts, including
casting away const.
Provide a better fitting variable (gi.invalid_obj) and eliminate a
number of casts.
