Scrolling by keyboard gets stuck

[UV_Completion]

If you scroll around using the keyboard sometimes the "key up event" seems to get lost so that the game scrolls forever in one direction. I haven't been able to find a workaround for this other than aborting the match. If you try to scroll in the opposite direction you can compensate the scrolling as long as you press down the key but there seems to be no way to restore normal conditions.

This bug is difficult to reproduce. It seems to me that it occurs primarily when the game lags for a short moment while scrolling. It does not seem to happen if one uses the mouse for scrolling.

I could try to give further information if necessary or even to look at the relevant code if someone could point out to me where it is located.

Edited September 22, 2011 by UV_Completion

[historic_bruno]

If you scroll around using the keyboard sometimes the "key up event" seems to get lost so that the game scrolls forever in one direction. I haven't been able to find a workaround for this other than aborting the match. If you try to scroll in the opposite direction you can compensate the scrolling as long as you press down the key but there seems to be no way to restore normal conditions.

This bug is difficult to reproduce. It seems to me that it occurs primarily when the game lags for a short moment while scrolling. It does not seems to happen if one uses the mouse for scrolling.

I could try to give further information if necessary or even to look at the relevant code if someone could point out to me where it is located.

I seem to have encountered this as well, on OS X. Which OS are you using?

Edit: the scrolling code is in CGameView::Update (source\graphics\GameView.cpp).

[UV_Completion]

I seem to have encountered this as well, on OS X. Which OS are you using?

I'm on Debian GNU/Linux and using the most recent git version.

Edit: the scrolling code is in CGameView::Update (source\graphics\GameView.cpp).

Thanks, I will take a look as soon as I find time. But as I'm not familiar with the code I can't promise anything.

[janwas]

Thanks for the report; it'd be great if you would look into this!

It could be a problem within SDL, but that's a bit less likely because it seems to happen on the OS X backend, too.

If you see any gremlins lurking within out input handling chain (starting at lib/input.cpp), I will be happy to give it a look and/or apply a patch.

Incidentally, if you see this problem again, it should be possible to work around it by pressing+releasing the same `stuck' key.

The problem does not arise with mouse scrolling because we check each frame whether the mouse is near the border. Once the mouse returns elsewhere, movement will stop immediately.

[UV_Completion]

I put some debug code in Hotkey.cpp:HotkeyInputHandler() two weeks ago but haven't been able to trigger this bug again since then. This is kind of strange because it happened on an almost daily basis to me before. Either it's a weird timing problem which would make it impossible to debug for me because I have no detailed knowledge about the inner workings of that code or some third party dependency got updated in the meantime (I'm on Debian Testing and perform an update every day). I'll try without debug code again as soon as I find time to do so (may take a while though).

Thanks for the report; it'd be great if you would look into this!

It could be a problem within SDL, but that's a bit less likely because it seems to happen on the OS X backend, too.

If you see any gremlins lurking within out input handling chain (starting at lib/input.cpp), I will be happy to give it a look and/or apply a patch.

Incidentally, if you see this problem again, it should be possible to work around it by pressing+releasing the same `stuck' key.

I'm pretty sure I tried this and it didn't work. That's the reason why I suspect HotkeyInputHandler() because there is some code which prevents key up events from doing anything under certain conditions (which I do not truly understand).

The problem does not arise with mouse scrolling because we check each frame whether the mouse is near the border. Once the mouse returns elsewhere, movement will stop immediately.

This makes sense.