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.
The #version command is a leading substring of the #versionshort
command and for Qt, it couldn't be executed by typing, only via
mouse click or one of the Qt-specific menus. #version<return>
or #version<space> now works for that.
The #versionshort command ought to be renamed to something else.
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...
When responding to '#', the Qt interface puts up a grid of buttons
labelled with the names of commands. Then if the user types
instead of clicking on a button, buttons which can no longer match
are removed rather than grayed out. The remaining ones keep their
same relative positions. Once whole rows or whole columns were
gone, it looked awful. With rows gone, the size of the grid
shrank but the popup stayed the same size, so the one-line prompt
area expanded to fill up the vacated vertical space. That caused
the prompt and partial response to move as they stayed centered in
their growing area. With columns gone, the width of the buttons
in remaining columns expanded and they spread out to take up
vacated horizontal space. Once the candidate commands were all
in one column, the buttons spanned the width of the grid. (That's
mostly my fault due to changing the grid from being row-oriented
[a b c]
[d e ]
to column oriented
[a d]
[b e]
[c ]
which resulted in columns going away a lot faster and possibly down
to one when the old layout always had at least two. But old layout
could drop to one row; the current layout always has at least two.)
Also, accept ^[ as ESC. Typing ESC when partial input is present
kills that input but keeps prompting. Typing ESC when no input
is present (none entered yet or a second of two consecutive ESCs)
cancels the operation.
Allow ^U to kill partial input. If used when no input is present,
nothing happens, similar to backspace. Unlike tty and curses, it's
hardcoded here. That shouldn't be a problem because ESC can be
used as a substitute if ^U isn't what the player normally uses.
Multiple stints of flailing about without a clue finally led to
a breakthrough. When writing a new message to the multi-line
message window, force the view back to showing the starts of
lines if player has scrolled it to the side and left it that way.
Put another way, if it has been scrolled to the right, scroll it
as far as possible back to the left.
Not caused by a hidden macro this time...
|mon.c:1549:10: warning: declaration shadows a variable in the
| global scope [-Wshadow]
| long flags = 0L;
| ^
|../include/flag.h:392:29: note: previous declaration is here
|extern NEARDATA struct flag flags;
Be prepared for life-saving to contradict "<mon> falls to pieces".
Purely hypothetically at present (with no plans to change) since
golems don't benefit from amulets of life-saving.
