choose_classes_menu was declared extern. The only caller presently
was calling it was optfn_pickup_types() in options.c.
It could have had the extern declaration from include/extern.h and
declare it as static within options.c, if that was the only use
anticipated. Also, if the one existing caller were all there would
ever be, the argument passed to it that was the subject of pr #1146
could have just been removed along with the switch.
Checking the comments above the function, however, it was clearly
designed as a general-purpose function that could be called from
anywhere for the functionality desired, even though there's presently
just the one caller, passing just the one variation of the category
argument.
Relocate the general-purpose function over to src/windows.c, where
several interface-related / menu-related general-purpose functions
already reside.
options.c has gotten *huge* and this is a fitting opportunity to
reduce its size a little.
A very small number of relatively recent macro definitions got
placed in mondata.h, even though they had a 'struct monst *'
argument, rather than a 'struct permonst *' argument.
Relocate the macros with the 'struct monst *' argument to
include/monst.h, leaving the macros with the 'struct permonst *'
argument in include/mondata.h.
This is useful for debugging and it allows the index
to be used directly instead of calculated in a
monsndx() function, which has been removed.
I left monsndx() in as a simple short-hand macro for the value
and didn't change the use cases, the reasoning being that this:
monsndx(mon->data)
is arguably a little easier on the eyes than:
mon->data->pmidx
LOW_PM, NON_PM, SPECIAL_PM have been included in the 'enum monnums'
now, instead of as individual macro definitions.
I chose to add the pmidx field as an instance of the enum declaration,
because that has very advantageous results in some debuggers, where it is
then shown as:
pmidx PM_GRAND_MASTER (349) monnums
instead of the less-informative:
pmidx 349 int
Adding the element count to the extern declaration for mons from:
'extern struct permonst *mons[];'
to the more specific declaration to that in src/monst.c:
'extern struct permonst *mons[NUMMONS + 1];'
then allows navigation through the mons array in one of the debuggers.
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.
"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.
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.
<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.
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.
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.
These are meant to be 'cwt' values and directly comparable to a
particular pm->cwt, which is an unsigned short. My concern here was
signed/unsigned comparison warnings like the one fixed in 1538b40, but
I'm not sure if this is actually necessary: there is already a
comparison between cwt and WT_HUMAN in max_mon_load() which apparently
doesn't produce the warning...
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.
Everything else in c_commmon_strings had this qualifier, but
c_vision_clears was just const char *. There doesn't seem to be any
reason for that so change it to be consistent with the others.
This is largely taken from xNetHack with a few minor changes. Dipping a
potion into a sink can help with item identification by producing the
potionbreathe effect (or a sink-specific effect, for a couple potions).
Dipping other items will just run water over them. I also added the
capability to wash your hands at a sink.
Dipping hands (with '-') or currently-worn gloves in a fountain or pool
will cause the hero to wash her hands, washing away any oil and clearing
the Glib intrinsic timeout. This does mean bare hands can be used to
fish for fountain effects, without having to pick up a stray arrow and
carry it around as a dipping item, but having your hands be the only
thing that does not activate those effects felt weird. If that would be
too unbalancing this could be scrapped.
Various places checking for whether a monster was on the map based on
mstate flags were inconsistent about which ones they checked (and then
place_monster() was additionally inconsistent with all of them about
which bits were cleared when placing a monster onto the map). I think
some places were also more convoluted than is now necessary because they
date back to mstate being an alias for mspare1, which it shared with
migflags before those became two separate dedicated fields (MSTATE_MASK
also dates back to this and is no longer used, so I removed it).
I tried to go through all the MON_foo mstate bits, understand when/why
they are set, and make the various functions I noticed more consistent
(with each other, and with my understanding of how the bits work) about
how they are treated. I don't know for a fact that I understood
everything right -- some diagnostic bits that aren't used for much of
anything, like MON_OBLITERATE, had me mystified until I read the 5ee78c5
commit message -- but this patch hasn't caused any new problems (sanity
check or otherwise) with the fuzzer in my testing so far. All the same,
it could probably use review by someone who has a good sense of what the
mstate bits mean.
Put everything through a single function that can handle all the
complicated parts of using the correct proposition for different terrain
types, and will not just call things "solid ground" indiscriminately.
This got complicated but I'm not sure if it's possible to do it much
simpler while still using the distinct names for each type of terrain
(unless you are OK with the sentences sounding sort of wonky).
I realized that failed explore-mode authorization on a special-mode
saved game cannot downgrade the game mode further down to a normal game,
because this would dump the player back into a state where she has
completed some part of the game in explore mode but is eligible for the
topten list. This is even more true when the game was formerly a
wizard-mode game. Unforunately, that was the state my previous commits
left the game in.
Instead, if restoring an explore-mode or wizard-mode savegame, and the
player is authorized via sysconf for neither of those modes, fail
restoration entirely and start a new game instead. That's sort of
clunky and there could probably be more explanation provided, but it
should be an exceedingly rare occurance and I'm not sure what
alternative exists that would still honor the EXPLORERS and WIZARDS
restrictions. This shouldn't affect the way they default 'down a mode'
in other circumstances, i.e. the overwhelming majority of situations in
which EXPLORERS authorization is needed/checked.
For the same reason, I realized that the player can't be prompted
whether or not to enter explore mode, if being downgraded from a
no-longer-authorized wizmode save while explore mode is authorized. The
change from wizard mode to explore mode must be mandatory. I have also
switched that up so that it will force the change -- unfortunately, this
has the side effect of allowing the preservation of the save, but it's
more important to make sure a wizard mode game doesn't get reverted to
normal mode. They won't be able to load the save into wizard mode
anyway.
The sysconf EXPLORERS list restricting access to explore mode was being
evaluated and used when a player used the #exploremode command in-game,
or when specifying -X or OPTIONS=playmode:explore on the command line
when resuming a normal game, but not when starting an entirely new game.
When SYSCF is avilable, check for authorization early, similar to debug
mode authorization, to restrict access to explore mode to EXPLORERS
under (hopefully) all circumstances.
Change 852f8e4 by requiring a minimum impact before a buried zombie
nearby will be disturbed: light, but still excluding things like
scrolls, if it's a violent impact (dropped while levitating, thrown, or
kicked), and fairly heavy if the hero is just placing the item on the
ground normally.
Moving the call out of flooreffects meant it no longer applied to
pushing boulders around, so have moverock disturb nearby zombies. I
additionally had wake_nearby do the same thing.
Finally, I renamed check_buried_zombies (which doesn't really reflect
what it does) to disturb_buried_zombies.
Add a new option 'perminv_mode' to augment perm_invent. It handles
the same choices as the temporary TTYINV method: show all items other
than gold, show full inventory including gold, or only show in-use
items (similar to the '*' command).
For tty, both the all-except-gold and full-inventory modes can add
the poorly named 'sparse' variation which populates unused slots in
its fixed grid with the inventory letter that would go in each.
For others, the default has been changed from full-inventory to
all-except-gold. Note that gold is treated as part of 'all' or of
'in-use' if it is quivered because having the amount be shown on the
status line doesn't make that redundant.
Changing the default may mess up WinGUI if it assumes that perm_invent
is full inventory with gold.
Initially I was going to change perm_invent into a compound but this
leaves it as an on/off toggle and adds perminv_mode as a separate
option for how to show the inventory when the toggle is on. It may
make sense to combine them since dual controls is a little confusing,
but right now setting perm_invent On when perminv_mode is 'none'
changes that to 'all' and changing perminv_mode away from 'none' when
perm_invent is Off toggles it to On.
Guidebook.mn has been updated but as usual Guidebook.tex is lagging.
Confusion between 'o_status_cond' and 'pfx_cond_'. Still confusing
but I think now working as intended and expected.
If any cond_xyz option has been loaded from the RC file or changed via
'm O', #saveoptions still saves the full set rather than just the ones
that are different from their default value.
