Reported by ars3nly as "#1250: Repeating #sit causes a sitting loop", with a followup comment describing how to reproduce easily, and by Umbire as "#1229: Curses and extended command menus". Repeat count from previous command carried over to current command when ^A was used to re-run the current one. Reset 'last_command_count' every time a repeat count is obtained, even when the new one is 0. This is a much simpler fix than what was used with several previous attempts, but it seems to be working. The do-again code is convoluted, but the tricky bit was the fact that this problem only happened when number_pad was On with repeat counts entered as 'n<digits>'. I still don't understand that aspect, but it wasn't happening for count of simple '<digits>', making reproducing it by someone who doesn't use number_pad be difficult.... Closes #1229 Closes #1250
This commit is contained in:
@@ -1964,6 +1964,9 @@ restoring a save file could trigger impossible "rnd(0) attempted" if it tried
|
||||
fix regression of a post-3.6 fix: if 2 Wizards of Yendor were in play and 1
|
||||
escaped the dungeon, bookkeeping for current number of Wizards stayed
|
||||
at 2, interferring with future Wizard behavior
|
||||
sometimes a repeat count from the preceding command carried over to most
|
||||
recent one when using do-again (^A); if the most recent one was an
|
||||
extended command, the spurious repeat was for '#'
|
||||
|
||||
|
||||
Fixes to 3.7.0-x Platform and/or Interface Problems Exposed Via git Repository
|
||||
|
||||
@@ -4743,8 +4743,8 @@ parse(void)
|
||||
|
||||
foo = get_count((char *) 0, '\0', LARGEST_INT,
|
||||
&gc.command_count, GC_NOFLAGS);
|
||||
gl.last_command_count = gc.command_count;
|
||||
}
|
||||
gl.last_command_count = gc.command_count;
|
||||
|
||||
if (foo == gc.Cmd.spkeys[NHKF_ESC]) { /* esc cancels count (TH) */
|
||||
clear_nhwindow(WIN_MESSAGE);
|
||||
|
||||
Reference in New Issue
Block a user