Although choose_classes_menu() is only used for objects, it is written
to handle monsters too. My change to give <space> special handling
might have broken selecting ghosts if it's ever used for monsters so
fix that.
More on clearing pickup_types so that autopickup reverts to picking up
evertyhing: for menustyle:Full and Partial, add a menu entry for 'all
classes' as an alternative to unselecting every class already set.
Also, Full and Partial had no way to include venom. Now it's a choice
when in wizard mode. There's still no way--other than switching to
Traditional or Combination--during normal play (where venom objects can
exist if they were wished for in wizard mode and then left in bones).
To use 'O' to clear a value from pickup_types with menustyle Traditional
or Combination, you needed to give a value starting with 'a' (for 'all').
Accept space(s) too, similar to removing an object or monster name.
When options processing encountered OPTIONS=windowtype:X,
the code would immediately attempt to switch over to that
windowtype right in the midst of options processing.
This stores the chosen option into
chosen_window[WINTYPELEN]
thus allowing the startup code to choose it after
options processing has been completed.
Some code added for 3.6.1 tries to find the longest matching prefix
when comparing a user-supplied with previously set up fruit names.
It does so by temporarily replacing space with NUL then passing that
to makesingular(). After already having named a fruit (resulting in
something to try to compare with), attempting to assign a name
beginning with two or more spaces would yield an impossible "singular
of null?" warning.
After the warning, the name minus its leading spaces got successfully
assigned. I'm not sure why a single leading space didn't trigger it
too, nor where the leading (and trailing, if any) spaces are going
away when the name is assigned.
Fix by removing all leading and trailing spaces from a new fruit name,
and combine consecutive internal spaces to one, before any other
manipulations. (This can result in names that used to work as-is now
being simplified a bit--when consecutive internal spaces have been
given--but that shouldn't be a problem.)
Also, don't complain about "missing parameter for 'fruit:'" if user
hits <return> when prompted for fruit name by 'O'. An empty fruit
name at that stage is just a no-op.
Changes to be committed:
modified: include/winprocs.h
modified: src/options.c
modified: sys/share/pcmain.c
new file: sys/share/safeproc.c
modified: sys/winnt/Makefile.msc
modified: sys/winnt/stubs.c
new file: sys/winnt/windmain.c
modified: sys/winnt/winnt.c
modified: win/win32/vs2017/NetHack.vcxproj
modified: win/win32/vs2017/NetHackW.vcxproj
modified: win/win32/winhack.c
Because multiple window ports are supported on Windows
now, even in the same executable and selectable via
config file in some cases, some adjustments became
necessary. There will likely be some further refining
of this over the next day or two.
List of changes:
Move Windows startup from sys/share/pcmain.c and
into its own sys/winnt/windmain.c so that it can
be modified to fix some current breakage, and
allow altering the order of some things.
There is startup processing code that is common to
all of the Windows WindowPorts, but that startup
processing code needs to have no dependency on
any one of those WindowPorts.
Yet, during startup processing, some of the initialization
routines can end up calling NetHack functions that
expect an active Window port underneath, and if there
isn't one, routines like pline, impossible, panic can
end up invoking null function pointers.
Place a new file sys/share/safeproc.c, in which a complete
window port is available for early startup processing
purposes. It's WindowPort name field is set to
"safe-startup" just for reference. The prototypes in
include/winprocs.h require that SAFEPROCS be
Usage:
windowprocs = get_safe_procs(0);
initializes a set of winprocs function pointers that ensure
none of the function pointers are left null, but that's all it does.
windowprocs = get_safe_procs(1);
initializes a set of winprocs functions pointers that ensure
none of the function pointers are left null, but also
provides some basic output and input functionality using nothing
other than C stdio routines (no platform or OS specific code).
The conditional code related to WIN32 has been removed from
sys/share/pcmain.c
The code common to all of the Windows WindowPorts calls
get_safe_procs() almost immediately to ensure that
there is a set of WindowPort winprocs available.
In the 'special options' section at the end of 'O's menu, change the
spelling for the menucolors entry to "menu colors" so that it isn't
spelled exactly the same as the 'menucolors' boolean option. Only
affects what the player sees when reading that menu.
If player uses 'O' to add any menu colors and 'menucolors' boolean is
Off at the time, give a reminder to toggle it to On in order to have
those menu colorings become active. (Adding hilite_status entries has
a similar reminder for 'statushilites' if done while that is 0.)
When deciding whether to discard interrupted lock/unlock context while
changing levels, maybe_reset_pick() checks whether xlock.box is being
carried. But it was doing so after the old level had been saved and
memory for non-carried container there had been freed.
That led to a couple of other issues. context.travelcc was using -1
for 'no cached value', but the fields of travelcc have type 'xchar' and
shouldn't be given negative values. 0 should be fine for 'no cache'.
Failed partial restore which occurred after old game's context had been
loaded would begin a new game with old game's stale context. Restoring
goes out of its way to avoid that for 'flags' but didn't for 'context'.
There was a spurious seli-colon after an if's test, making a boundary
check be ineffective. When looking at that, I noticed that the 'O'
command's display of the current value for mouse_support ("0=off" and
so forth) was relying on implicit concatenation of adjacent string
literals, which would break K&R compilation. Do that concatenation
the old fashioned way....
While testing (after temporarily adding WC_MOUSE_SUPPORT to tty's
window_procs), I also noticed that wording used by config_error_add
looked strange when it was in response to giving a bad value via 'O'
command. Suppress its "config_error_add: " prefix is that situation.
On Windows only:
0 = turn off mouse_support
1 = turn on mouse_support and turn off QuickEdit mode
2 = turn on mouse_support and leave QuickEdit mode untouched
More generally, but not implemented anywhere:
0 = turn off mouse_support
1 = turn on mouse_support and make supporting O/S adjustments
(O/S adjustments not implented beyond Windows as yet)
2 = turn on mouse_support and do not make OS adjustments
(unimplemented as yet so behaves as 1)
Clean up quite a bit of minor things found with simple grep patterns:
operator at end of continued line instead of beginning of continuation
(and a few comments which produced false matches, so that they won't
do so next time), trailing spaces (only one or two of those), tabs (a
dozen or so of those), several casts which didn't have a space between
the type and the expression (I wasn't systematic about finding these).
I think the only code change was in the function for the help command.
This was discussed two years ago then nothing happened. Make
autodescribe for feedback when moving the cursor to pick something
default to on instead of off.
Demote #monpolycontrol and #wizdebug_traveldisplay from commands to
simple boolean options. The former has the same name, the latter
is called travel_debug. Rename #wizdebug_bury to #wizbury; it
shouldn't matter that it goes away when compiled without DEBUG.
There are now five wizard-mode boolean options: monpolycontrol,
sanity_check, and wizweight are documented in the Guidebook;
menu_tab_sep and travel_debug are commented out there.
Guidebook.mn has been tested; Guidebook.tex has not.
Bug report #H7156 listed three items, all relating to perm_invent:
1) it shouldn't persist across save/restore since restore might be
on a system which doesn't have enough room to display it (report
actually complained that config file setting was ignored when
restoring old games, which is an expected side-effect for options
that persist across save/restore);
2) permanent inventory wasn't updated when using scroll of charging;
3) attempts to update permanent inventory during restore could lead
to crash if it tries to access shop cost for unpaid items.
Items (2) and (3) have already been fixed. This fixes (1).
Replace 'flags.perm_invent' with a dummy flag, preserving save files
while removing it from flags. Add 'iflags.perm_invent' to hold the
value of the perm_invent option.
The win32 files that are updated here haven't been tested. Whichever
branch contains the curses interface needs to be updated; ditto for
any other pending/potential interfaces which support perm_invent.
Take a step towards eliminating merging hilite_status rules during
highlighting by creating a single rule instead of multiple ones
when specifying multiple attributes for the same highlight via the
'O' command's menus.
Old:
(pick_one menu to pick a color) + (pick_one menu to pick an attribute)
| hilite_status:title/always/red&bold
(pick_one menu to pick a color) + (pick_one menu to pick an attribute)
| hilite_status:title/always/red&blink
New:
(pick_one menu to pick a color) + (pick_any menu to pick attributes)
| hilite_status:title/always/red&bold+blink
At present, rule selection during highlighting still merges multiple
applicable rules instead of finding the best one first, with the
problems that entails.
Bonus fix: a hilite_status rule for status conditions which specified
"no attributes" would clear attributes for all previous condition
rules rather than just the one(s) in that "no attributes" rule.
The 'O' menu's 'list' for MSGTYPE settings showed truncated versions
of really long message strings but didn't show anything except the
hide/stop/norep setting for ordinary length ones. 3.6.0 showed the
latter correctly but suffered buffer overflow for the former; the
fix for that had a typo/thinko in it.
Toggling either ascii_map or tiled_map with the X11 interface switches
the map window from one style to another, but it was only working as
intended when done via the 'O' command. Setting ascii_map via initial
options only worked if tiled_map was explicitly cleared. This fixes
that.
Added support to detect when the current console font has glyphs
that are too wide and will cause rendering errors in the console.
If detected, we warn the user and change the code page to 437
and the font to Consolas. At exit, if we had changed the font
and code page then we will restore to the original font and code page.
The followup message about the fix for #5056 was trapped by the spam
filter so didn't reach us for a while.
xlogfile has an extra field to track various achievements made during
the game it logs, two of which are fully exploring the gnomish mines
and fully exploring sokoban. Those are accomplished by finding the
special 'prize' item on the final level of their branch: luckstone
for mines and bag of holding or amulet of reflecition for sokoban.
3.6.0 had a bug where any item of the target type found anywhere in
the dungeon resulted in achieving the relevant goal. A post-3.6.1 fix
for that required that the item be found on the end level of the branch
and attempted to require that it an item explicitly placed there by the
special level loader, but the latter aspect had a bug which meant that
random items of the appropriate type placed on final level would count
as the prize. Chance of extra luckstones on mines' end is fairly high,
so potential for false completion of the achievement was also high.
The second complaint was that since the achievement was only recorded
if the special prize item was found on final level, then if a monster
took it to another level then the achievement became impossible. (Not
true, the player could take it back, drop it, and pick it up again, but
that is admittedly a pretty silly hoop to jump through.) On the other
hand, if a monster removed the item before the hero found it, then a
case could be made that the hero hadn't really fully explored the
level. However, this fix records the achievement no matter where the
hero picks up the item. The final level must be entered--otherwise no
monster could possibly acquire and transport the item--but it isn't
guaranteed to have been fully explored. Big deal....
The prize could also be acquired in bones data. Before the second
portion of this fix, that wouldn't have mattered. But now it does, so
clear the prize indicator when saving bones unless it happens to be the
same level where that item is created (impossible for sokoban, where no
bones are left; not sure offhand about mines' end). The former prize
stone or bag or amulet becomes an ordinary one of its type.
This can all be done in a much cleaner fashion once we give up on the
current save file compatability. Putting obj->o_id values into new
context.mines_prize and context.soko_prize, plus a hack to mkobj() to
not reuse those two values if the o_id counter ever wraps back to 0,
would cover most of the details. Adding an achievement tracking flag
to lev_comp's object handling for use by the special level loader
would cover most of the rest.
X11 supports both ascii map and tiled map and is able to switch back
and forth during play. 'O' shows both of them as boolean options, but
toggling ascii_map did nothing since tiled_map retained whatever value
it had at the time. For core options handling, make toggling either
ascii_map or tiled_map also set the other one to the opposite value,
so ascii on forces tiled off and vice versa.
Add a new boolean option herecmd_menu. If this is on, and using
a windowport that supports mouse, clicking on your character pops
up a menu of actions doable in that location. Basically this is
nothing new, as almost all of the same actions were done before
on the mouse click.
You can also pop up the context menu with the #herecmdmenu
extended command
My tty+X11 binary was letting me see and modify status highlights under
X11 even though they don't do anything. Options parsing has to accept
them since we don't know which interface will be chosen, but interactive
option handling does know and shouldn't show inappropriate options.
initoptions_finish() should probably we validating all the wc and wc2
options, but I only added a check for trying to enable statushilites
when they're unavailable.
Give sensible feedback for obsolete options if options.c is modified
to #undef BACKWARD_COMPAT. Affects boulder, DECgraphics, IBMgraphics,
and MACgraphics.
When built without STATUS_HILITES, don't treat highlighting options as
if they were unknown. This may need some tweaking; the feedback feels
a bit intrusive so perhaps 'statushilites' and 'hilite_status' should
just be ignored when not available.
'hitpointbar' now relies on wc2 handling instead of being conditionally
present.
Turning the boolean option force_invmenu makes all the commands
that ask for an inventory item pop up a menu instead of asking
a text query. This should be much more friendlier to new
players, and is very useful for window ports on systems
with touch screens and no physical keyboard, such as cell phones.
