Opened 9 years ago

Closed 8 years ago

#1577 closed bug (fixed (in master))

Movement delay breaks movement

Reported by: myshkin Owned by: david3x3x3
Milestone: 3.4.0 Keywords: prefs

Description (last modified by myshkin)

Reported by macang on IRC: when movement delay is nonzero and the roguelike keyset is on, the hjkl movement keys only work every other keypress, and the yubn movement keys don't move at all. He reported this with 3.3.2 on OS X 10.6.6; I can reproduce it with v4 on OS X 10.6.8 with both the roguelike and standard keysets. I suspect it is not port-specific.

Change History (7)

comment:1 Changed 9 years ago by myshkin

  • Description modified (diff)
  • Keywords prefs added; keyset removed
  • Summary changed from Movement delay breaks the roguelike keyset to Movement delay breaks movement

comment:2 Changed 9 years ago by myshkin

On IRC, BreathesFire? confirms that it also occurs on 3.3.0 Windows:

Oh that's odd.  Adding a movement delay disables num-keypad input, but the standard arrow keys work
Working off a windows 10-3-2011 compile
Actually, it forces you to hold down the key and wait for effect
I'm thinking movement delay should only apply to auto-run with '.'
It also stores the last movement key and waits for input after x-milliseconds, then uses the old direction
so if you are holding down a movement key, release, then press a new direction, you will continue once more in the old direction
Using the run command also requires holding down the key to get a running direction prompt
Then the game delays for each space ran, but the screen is not updated between each sqaure movement
The result is a long delay until @ appears at the end of his run.
So yeah, movement delay is unplayable on 3.3.0 for windows

comment:3 Changed 9 years ago by myshkin

See also this oook thread. The bug is not as old as 3.2.0.

comment:4 Changed 9 years ago by magnate

  • Status changed from new to confirmed

comment:5 Changed 9 years ago by fizzix

  • Owner changed from myshkin to david3x3x3
  • Status changed from confirmed to assigned

comment:6 Changed 9 years ago by david3x3x3

I ran a git bisect and I think the problem was introduced with commit 9ca1731.

comment:7 Changed 8 years ago by magnate

  • Resolution set to fixed (in master)
  • Status changed from assigned to closed

[b346826] in master and [807b29f] in v4-master - thanks David!

Note: See TracTickets for help on using tickets.