The g? structs had a mix of variables that were written to
the savefile, and those that were not.
For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.
This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.
Details:
gb.bases -> svb.bases
gb.bbubbles -> svb.bbubbles
gb.branches -> svb.branches
gc.context -> svc.context
gd.disco -> svd.disco
gd.dndest -> svd.dndest
gd.doors -> svd.doors
gd.doors_alloc -> svd.doors_alloc
gd.dungeon_topology -> svd.dungeon_topology
gd.dungeons -> svd.dungeons
ge.exclusion_zones -> sve.exclusion_zones
gh.hackpid -> svh.hackpid
gi.inv_pos -> svi.inv_pos
gk.killer -> svk.killer
gl.lastseentyp -> svl.lastseentyp
gl.level -> svl.level
gl.level_info -> svl.level_info
gm.mapseenchn -> svm.mapseenchn
gm.moves -> svm.moves
gm.mvitals -> svm.mvitals
gn.n_dgns -> svn.n_dgns
gn.n_regions -> svn.n_regions
gn.nroom -> svn.nroom
go.oracle_cnt -> svo.oracle_cnt
gp.pl_character -> svp.pl_character
gp.pl_fruit -> svp.pl_fruit
gp.plname -> svp.plname
gp.program_state -> svp.program_state
gq.quest_status -> svq.quest_status
gr.rooms -> svr.rooms
gs.sp_levchn -> svs.sp_levchn
gs.spl_book -> svs.spl_book
gt.timer_id -> svt.timer_id
gt.tune -> svt.tune
gu.updest -> svu.updest
gx.xmax -> svx.xmax
gx.xmin -> svx.xmin
gy.ymax -> svy.ymax
gy.ymin -> svy.ymin
Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
gf.ftrap, gl.light_base, gt.timer_base
The consolidation of global variables from scattered source
files into decl.c and declared in decl.h was begun in 3.7.0.
Their placement in common files was done for centralized
initialization and potential re-initialization during a
"play again" scenario.
It wasn't really necessary for all of them to be housed in a
single huge structure to meet the "play again" requirement,
and the single huge structure has been a little unwieldy when
it comes to maintenance.
Following this commit, instead of one single extremely large structure
named 'g' to house all of the relocated global variables, they
are distributed into several ga through gz.
To make things easy for the developer, each variable is placed
into the struct corresponding to the starting letter of the variable.
That way, no lookup is required in order to know which struct houses
a particular variable, it is a simple match to the starting letter
for all the centralized global variables.
A global variable named 'amulets', would be found in ga.
ga.amulets
^ ^
A global varable named 'move', would be found in gm.
gm.moves
^ ^
A global variable named 'val_for_n_or_more' would be found in gv.
gv.val_for_n_or_more
^ ^
A global variable named 'youmonst' would be found in gy.
gy.youmonst
^ ^
Instead of using index() macro defined to strchr, use C99 strchr.
Instead of using rindex() macro defined to strrchr, use C99 strrchr.
If you want to try building on a platform that doesn't offer those
two functions, these are available:
define NOT_C99 /* to make some non-C99 code available */
define NEED_INDEX /* to define a macro for index() */
define NEED_RINDX /* to define a macro for rindex() */
Instead of allocating space for ((n + 1) * size) (to make room for all
entries plus terminator), it allocated space for (n * size + 1).
init_extended_commands_popup would therefore write past the end of the
memory allocated for command_list and command_indx when trying to store
their respective terminator entries. This meant the X11 windowport
would crash when accessing the extended command menu, if NetHack had
been compiled with -fsanitize=address.
I also did some minor cleanup/refactoring to eliminate variables and
lines that were made redundant or useless by 9d64d13, which changed the
way the function worked and removed the need for things like tracking
indices in the source and destination arrays with separate variables.
This replaces the old pushq/saveq arrays (which were used to save
the keys pressed by the user for repeating a previous command)
with a new command queue. This means there's no hard-coded limit
to the saved keys, and it can repeat extended commands which are
not bound to any key.
Fix '#repeat' for tty; both it and ^A can repeat an extended command.
Fix both for curses; they can repeat an extended command instead of
just repeating the initial '#' to start getting an extended command.
X11 (tested), Qt (tested), and probably Windows GUI (not tested)
behave the same as before: ^A (or #repeat) after an extended command
just repeats the # to run the dialog to get an extended command.
I hope this introduces fewer bugs than it fixes but I don't think I'd
bet on that....
The extended command input prompt was behaving in an unintended way:
Typing #a<enter> executed #adjust. Spaces in the entry prevented matching
any command. No error message was given when no command was matched.
Fix all of those, so it behaves more like the tty.
Clean up the tty, curses, and X11 windowport code, so they don't use
the extcmdlist array directly, but query with extcmds_match
and extcmds_getentry.
Looking up scrollbars did not work as intended. The code wanted an
ancestor widget that had both horizontal and vertical scrollbars,
but menus either have none or just vertical. The lookup code found
some top level widget and returned bad data.
Add some prototypes and add a new include to a couple of files that
use config.h instead of hack.h. So sys/unix/Makefile.src has been
changed slightly.
Support for scrolling within menus via first-/previous-/next-/last-
page keystrokes ("^<>|" by default) was added to X11's general menu
handling but the extended commands menu uses a special menu rather
than a general one. This clones the relevant code to add support for
those keys to extended commands.
The expansion of the extended commands list to include every command
has made picking extended commands out of X11's menu become tedious.
This uses the existing 'extmenu' option (previously tty-only) to
control whether all the commands are present or just the traditional
subset not bound to non-meta keystrokes ('adjust', 'chat', 'loot', &c).
Update tty command completion to ignore #shell and #suspend when
they're disabled. (Since they aren't flagged for command completion,
this should be unnoticeable.)
Update X11 extended command selection to not show shell and suspend
in the menu when they're disabled. (Trickier than I expected.)
X11 currently rejects #suspend (at run time, not compile time) but
allows #shell. If it was launched syncronously from a terminal
window, shell escape behaves sanely. Otherwise, that seems like
asking for trouble.
Both the "help" button at top and the "help" extended menu command
were hilighted by the X resources. Make the top buttons have
"btn_" prefix, so they're easily distinguished in the resources.
Due to the new player selection dialog I did, it was possible
to rename your character - but this didn't rename the lock files
and tried to load a save from the wrong name.
This is a bit of a hack, but seems to work and didn't seem to
cause problems for the tty.
A wishlist/TODO item: when "female" is highlighted, change "caveman"
to "cavewoman" and "priest" to "priestess". If it gets toggled to
"male", change them back.
This eliminates nearly 40 warnings, most by suppressing complaints of
used function arguments but a few for unused local variables. There's
also some reformatting thrown in....
There are still 18 warnings about uses of XtSetArg(), about assigning
const to non-const.
The dialog shows the player's name, race, role, gender, and
alignment in a single window, similar to the Qt4 dialog.
Also allows randomizing the character selection.
Use the dialog by setting OPTIONS=player_selection:dialog
Umpteenth revision of the X11 extended command menu. Add a new
resource to NetHack.ad to control its initial size.
I still hope there's a better way to do this, but this is my last
shot at it.
When the extended command menu auto-scrolls as the player types in
characters, scroll so that all matching entries come into view rather
than just the first one. For example, it someone types 'w', instead
of just highlighting and showing "wipe", it will highlight "wipe"
(because that has become the default response when <return> is used)
but also show "wiz-this", "wiz-that", and "wmode". It actually shows
one extra entry beyond the last matching one--so you can see that
there aren't any more ambiguous choices--except for 'w' where "wmode"
is the very last extended command.
Previously, on subsequent popups of the extended command menu, the
scrollbar's slider was left drawn in the position it was in during
the previous time even though menu content wasn't scrolled. Now it's
forced back to the top (non-scrolled) position when that menu is
popped up.
When the extended command menu is big enough to need a scrollbar,
leave more elbow room when forcing its height to fit on screen.
The last entry was frequently obscured by OSX's "docking tray"
desktop decoration and the resize hotspot (bottom right corner of
the menu popup) could be hard to access.
I'm not particularly happy with this code. There really has to be
a better way to accomplish what's needed.
I upgraded from OSX 10.5.8 via 10.6.3 to 10.6.8, plus Xcode to whatever
version was on the 10.6 dvd, and ended up with a more recent version of
gcc that is configured to use 64 bit longs and 64 bit pointers (by
default; presumably that can be changed if necessary). It triggered
several warnings about converting int to pointer of different size or
vice versa even when explicit casts were in use, and a couple of other
things.
The big memory allocation for tiles that was unfreed according to
heaputil was actually freed by X according to a comment in the code.
But free it explicitly for #if MONITOR_HEAP so that the alloc/free
tracking stays accurate.
Also, the cached extended commands menu was not being freed, so take
care of that. I wasn't sure where to handle it; I ended up making it
happen when the map window is torn down.
X11 had been ignoring add_menu(..., MENU_SELECTED) to specify a
pre-selected menu entry. This adds support for that.
Attempt to implement pre-selected entry for PICK_ONE menu sanely by
returning the pre-selected entry instead of toggling it off if the
user chooses it explicitly. Inner workings of menus are convoluted
so I'm not sure it's 100% correct, although testing hasn't found any
problems. (tty currently returns 0 for "nothing picked" when
explicitly picking a pre-selected entry in a PICK_ONE menu, and the
core jumps through hoops to handle it. That can't be cleaned up until
all interfaces which support pre-selected entries achieve sanity.)
Make "random" be chosen for <return> or <enter> during role selection
and highlight it to reflect that. (Role selection for X11 uses its
own code instead of nethack menus, so pre-selection isn't applicable.)
Without this, the keyboard commands don't work in the extended
command window on Linux. If the translations are removed from
menuformview, then the keyboard commands don't work on Mac.
Having the translations in both doesn't seem to hurt.
