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.
Arrays of struct delayed_action were declared before the definition.
Also, daemon.c and state.c defined it differently. The state.c
definition, in which d_arg is a union, is now used everywhere.
This is the least bad option, but fuses and daemons are still a
disheartening morass that undoubtedly shelters more bugs.
state.c had put file_name into the save file. The saved value was used
to overwrite file_name on restore. If the save file had been renamed,
unlink(file_name) would then fail, because file_name held the old name.
To avoid breaking savefile compatibility, file_name is still saved, but
it is read back into a temporary buffer and then ignored.
I thought I fixed this already.
Alchemy jugs are refilled by the alchemy() fuse, which takes a pointer
to the jug object as an argument. When written to a save file and read
back out, the pointer is unlikely to point anywhere useful.
Instead, rs_write_daemons() now stores an index into the player's pack
or the list of objects on the floor. rs_read_daemons() uses this
number to locate the object when restoring.
This change should not cause any new issues with old savefiles, but it
is unable to make a broken alchemy jug work again.
Daemons and fuses take a single argument, nominally an int but either
ignored or unsafely cast to a pointer. Its type has now been changed
to void*.
The save/restore code no longer tries to store this argument in the
savefile. For doctor(), this is not a problem, because player is the
only argument it is ever given as a daemon. However, alchemy() will
fail to do anything when passed NULL. Fixing this would be complicated
but possible.
Summary: the code is slightly safer, but alchemy jugs are guaranteed to
stop working after save and restore, instead of just extremely likely.
The player name is stored in whoami[], which is length 80 in most games
(1024 in rogue5). Only the first 10 chars were used to create
file_name, because that buffer is the same length. Increasing the size
of file_name to 256 permits using all of whoami.
The name is also no longer truncated to 20 chars when writing the log.
All games should now be able to handle 79-character names without
collisions. Anything more would break save compatibility.
In rogue5/state.c, rs_read_daemons() zeroes out the argument and delay
if the daemon slot is empty. Unfortunately that code ended up on the
wrong side of the brace that closes the for loop, so instead of running
after each daemon, it got run once after the loop exited, when the
index was of course out of bounds.
This tended to manifest, when compiled with -O2, by overwriting hw and
setting it to NULL. When inventory() next ran, hw would be passed to
wgetch(), which returns ERR when it gets a NULL argument. This made
md_readchar() think something was wrong and autosave the game.
Upon investigation, rogue3 was found to commit the same mistake.
rogue4 and srogue don't zero the data. arogue5 already does it
properly.
Someday I am going to run all this through Valgrind. Someday when I
am a kinder person who will not be driven to invoke hordes of trolls
and centaurs upon the original authors.
The save/restore code took the pointer intended as an argument for the
doctor() daemon and wrote it to the savefile as an int. I don't know
why it took so long to fail horribly. The problem has been avoided by
replacing the value with &player when restoring. That seems to be the
only argument ever actually used.
The code also writes only four bytes for an unsigned long; if
sizeof(long) == 8, it casts to unsigned int first. It failed to do the
cast when reading back, with the result that four bytes were read and
the other half of the number was effectively uninitialized.
It apparently works now, but the save/restore code ought still to be
regarded as decidedly unfortunate.
Some .o files need to be rebuilt if config.h changes. Adding it to the
list of headers may still fail to solve the problem, because some of
the Makefiles use implicit rules or do not list dependencies properly.
