This fixes all warnings produced by GCC 5, except the ones related to
system functions. Those could be fixed by including the proper headers,
but it would be better to replace the system-dependent code with
functions from mdport.c.
fuse() now expects a pointer as the argument to a fuse function. If
this is one of the functions that takes int, fuse() follows the pointer
and stores that value in the f_list slot, in the integer field of the
argument union. When the fuse goes off, do_fuses() recognizes the
function and passes it the integer field instead of the pointer.
This has the disadvantage of hard-coding the functions that require int
in daemon.c, but since the int is copied into f_list, it no longer has
to be in static or global memory, which simplifies several files.
Functions for printing options now return void. Functions for setting
options now return int. Argument types still vary, though converting
all the option pointers to void* would be possible.
Functions for starting and stopping daemons and fuses now expect the
type 'void (*func)()'. Only a few functions in XRogue needed to be
modified to fit. Determining the type of the argument is left for a
later date.
Building with GCC5 should now produce less than 200 lines of warnings
per game.
This is done by make, in the 'docs' target, which is now part of the
normal build process.
Unfortunately, not all the games include troff sources. Getting decent
HTML output from groff is still a difficult process which will not be
attempted at this time. There are a few bugs in the 'install' and
'uninstall' rules.
Not to mention that the documentation is sometimes inaccurate.
Almost 1500 lines of compiler warnings remain, and the GCC developers
are already working on a new version with even more warnings turned on
by default.
MSVC complained that they might be used uninitialized. In some cases,
this might have been possible.
XRogue already has initializations for all these variables.
Another fix for overwritten messages, this time for potions of monster
detection and magic detection.
I've made the message appear before the display of information, which
may be closer to the originally intended behavior.
When scrolls of magic mapping or gold detection were read, their
characteristic messages were displayed before overwriting the whole
screen to show the newly discovered information. They are now shown
after updating the screen, so they will be visible.
Updates to the screen took place in the wrong order, causing messages
and "--More--" prompts to be hidden before they could be seen.
There are probably similar bugs caused by other items.
Removing the call to msg() in restore() resulted in msgw remaining as
it was when the game was saved. This results in another display glitch
like that fixed by r163. Adding an empty message puts msgw into a
reliable state.
new_level() redraws the whole screen, including the message line, so if
msg() has just been called, the message will likely not last long
enough to be noticed. These cases have been changed so that msg() is
called after new_level().
If a fall through a trapdoor is fatal, "You fall into a trap!" is no
longer printed, but the tombstone should make things clear.
The save and restore code assumed sizeof(long) == 4, which is not the
case on x64. Reading only 4 bytes from the savefile left the others
uninitialized, which led to problems like billions of experience points
or gold pieces.
This line causes a segfault on x64. I suspect one of the char*
arguments to msg() is being corrupted. But gdb doesn't make it easy
to debug variadic functions, and the crash doesn't occur when running
under valgrind. So the message is being removed until I can discover
the root of the problem.
The restore() function displayed a status message via wprintw() instead
of using the msg() functions. If the inventory was then viewed before
a call to msg(), msgw would obscure the first lines of the inventory
list.
There are surely more bugs related to messages.
md_shellescape() sets SIGINT and SIGQUIT to be ignored, storing the
previous handlers, and restores them after the shell exits. But it
mixed up the two handlers.
Since the signals were usually handled by the same function, this fix
doesn't have much effect, but anything that makes signal code less
confusing is a good thing.
File locations can be customized via './configure'. 'make install'
does not work yet. Options for wizard mode and load checks may not do
what is intended.
Fun fact: there's an enlightening epigraph in the introduction to the
autoconf manual.
state.c now saves the fuse that refills alchemy jugs, using the method
of numbering objects previously applied to Advanced Rogue 5. Alchemy
jugs that are empty when the game is saved will continue to function
after it is restored.
Savefile compatibility should not be affected.
In both games, command() loops and calls the action function twice for
each command: once to schedule it by setting player.t_action and
player.t_no_move, and again, to actually do it, once player.t_no_move
has been reduced to 0. Each loop decremented count, so repeated
commands were only repeated half the number of times the player typed.
count is now decremented only when ch has been set to the repeated
command.
Keypad 5 is now equivalent to the '.' key.
XRogue does not include md_readchar() and its ability to work around
deficiencies in the terminfo entry. So the key will not be recognized
in screen/tmux or anywhere else without the kb2 capability. Adding
md_readchar() would be more complex than it was for Super-Rogue, since
XRogue already does KEY_* interpretation in command().
The 'askme' option is on in some games and off in others, probably due
to authorial preference. I am going to be consistent and turn it on in
all of them.
Advanced Rogue 5 and 7, and XRogue, now open the scorefile and logfile
at startup and then drop any set[ug]id privileges if the savedir is not
being used.
