Recent change to the stairs structure now lets each stair keep
the destination level number and dungeon where the stairs go to.
When a level that can be on different depth (such as the Oracle)
became a bones level, and it was loaded in another game at different
depth, the stairs were still pointing to the old level number.
Save it as relative to the current level instead of absolute.
If attempting to checkpoint when changing levels discovered that
the alock.0 or 123wizard.0 file was missing and the game was
running in wizard mode, play continued after reporting trickery
but screen updating was left disabled. An early return in
savegamestateinlock() wasn't resetting the program_state.saving
flag to revert to normal screen updates.
I added a few return statements at the ends of void routines,
where they're optional, because it makes searching for early
returns easier. (Without these then when no early return is
present between current point and end of routine, the search
would move past the routine looking for 'return' later in the
file.)
save_stairs() was placed in between saveobj() and saveobjchn()
so I've moved it. (Has no effect on the recently reported stair
anomalies.) It was also accumulating the total stairway data
size in 'len' and never using that for anything, so I got rid
of it. (Ditto about anomalies.)
I started activating new program_state.saving and discovered that
saving of ball and chain could access freed memory. The change
for the former and fix for the latter are mixed together here (but
easily distinguishable).
The saving flag inhibits status updating and perm_invent updating,
also map updating that goes through flush_screen(). That should
fix the exception triggered after an impossible warning was issued
during a save operation. impossible() goes through pline() which
tries to bring the screen up to date before issuing a message.
During save, data for that update can be in an inconsistent state.
The code to save ball and/or chain when not on floor or in invent
(I think swallowed is the only expected case) was examining the
memory pointed to by uball and uchain even if saving the level had
just freed floor objects and saving invent had just freed carried
objects. So for the usual cases, stale pointer values for uball
and uchain would be present and checking their obj->where field
was not reliable.
Noticed while working on Qt's extended command handling, there
are an awful lot of "seeXYZ" commands. Keep the inventory display
ones (named versions of ')' to show wielded weapon(s), '[' for
worn armor, '"' for worn amulet, &c) and rename the others:
| #seenv -> #wizseenv debugging command
| #seespells -> #showspells '+' command
| #seetrap -> #showtrap '^' command
Also, expand the descriptions of #shell and #suspend a bit in
the Guidebook. LaTeX version is untested.
Move the core's global restoring flag (not the same as main()'s
local resuming flag) to a more logical place. Add a saving flag
in the process, but it isn't being set or cleared anywhere yet.
(Once in use it will probably fix the exception during save that
was just reported, but before that it would be useful to figure
out what specifically caused the event.)
The program_state struct really ought to be standalone rather
than part of struct g but I haven't made that change.
Removing an unused variable for wishing and some reformatting
that whent along with it got mixed in. Removes some trailing
whitespace in sfstruct.c too.
Only lightly tested...
