Opened 5 years ago

Closed 5 years ago

#2809 closed defect (fixed)

Pressed keys persist in game past when they are released

Reported by: scythetwirler Owned by:
Priority: Must Have Milestone: Alpha 19
Component: Core engine Keywords:
Cc: Patch:

Description (last modified by scythetwirler)

The engine does not seem to catch the keyup event and some keypresses are effectively held down permanently when they are not.

To reproduce: When you press a key when it's not laggy and the key is lifted while the game lags, the keyup is not registered to the game. (You have to repress the button and unpress it to hope the game catches the keyup to work around it).

Attachments (2)

commands.txt (8.9 KB) - added by mimo 5 years ago.
savegame-lagfest.0adsave (933.0 KB) - added by elexis 5 years ago.
0ad savegame for Deep-Forest with 300 units, ready to lag

Download all attachments as: .zip

Change History (24)

comment:1 Changed 5 years ago by historic_bruno

Doesn't seem related to r15767 unless I'm missing the obvious. I haven't been able to reproduce it in a single-player Ubuntu 14.04 VM either. It occurred in a 4x4 multiplayer game, with one person on Windows 7 and another on Ubuntu.

comment:2 Changed 5 years ago by scythetwirler

Also happened to me in a 2v2 (on Ubuntu).

comment:3 Changed 5 years ago by scythetwirler

Can verify that it still happens for me.

comment:4 Changed 5 years ago by scythetwirler

When you press a key when it's not laggy and the key is lifted while the game lags, the keyup is not registered to the game. :/ (You have to repress the button and unpress it to hope the game catches the keyup).

Last edited 5 years ago by scythetwirler (previous) (diff)

comment:5 Changed 5 years ago by scythetwirler

Description: modified (diff)

comment:6 Changed 5 years ago by historic_bruno

Is there a chance it's related to r14057? I know that was a year ago, but it does specifically mention fixing hotkey behavior at low framerates. My other suggestion would be to go back in SVN history until you find a revision where this doesn't occur.

comment:7 Changed 5 years ago by scythetwirler

Indeed, it seems to be caused by r14057.

I was able to reproduce it with r14058 and r15765, but not with r14056.

comment:9 Changed 5 years ago by scythetwirler

and...I'm unable to reproduce this on Windows at r15839.

comment:10 Changed 5 years ago by historic_bruno

We discussed this in today's staff meeting. I don't think it's a release blocker if it's been broken for a year, but scythetwirler will try to debug it. We could also revert r14057 if it's worse than what it fixed.

comment:11 Changed 5 years ago by scythetwirler

There doesn't seem to be an easy way to fix it given the time that we have. Reverting r14057 introduced an even more severe problem - hotkeys triggering out of order, while it did fix this specific issue.

Unless anyone has any immediate idea on how to fix this, I think pushing to A18 is the right decision.

Last edited 5 years ago by scythetwirler (previous) (diff)

comment:12 Changed 5 years ago by Itms

Milestone: Alpha 17Alpha 18

comment:13 Changed 5 years ago by mimo

I've just noticed that commands are quite often sent several times to the Engine, I suppose it is the same problem that this ticket ? This can be easily seen in the commands.txt file where the same command may be recorded several times, sometimes even twice in the same turn. Some orders (setting of trade routes for example) are messed up with such dupplication.

comment:14 in reply to:  13 Changed 5 years ago by historic_bruno

Replying to mimo:

I've just noticed that commands are quite often sent several times to the Engine, I suppose it is the same problem that this ticket ? This can be easily seen in the commands.txt file where the same command may be recorded several times, sometimes even twice in the same turn. Some orders (setting of trade routes for example) are messed up with such dupplication.

That doesn't sound like the same thing being reported here. Can you provide an example commands.txt? And which OS are you using?

Changed 5 years ago by mimo

Attachment: commands.txt added

comment:15 Changed 5 years ago by mimo

I'm on Linux (kubuntu 14.04) and just run a new test: in the attached commands.txt, already at turn 47, the gather command is sent twice in the same turn for the same entity.

comment:16 Changed 5 years ago by Zdema

The keys "sticking" due to a lag spike isn't unique to this engine. It is something that I have experienced in unity as well. I don't know of a way to fix it if there is one, but I don't beleive this is a problem that should be a major focus if it only occurs in the lag spikes. It has an easy fix on the user side and the only way I can think of that might work is to track the lag spikes and recheck key inputs when they drop but that could cause more spikes only increasing the problem :/

comment:17 Changed 5 years ago by Philip Taylor

Might this be an SDL 1.2 bug? It has MAXEVENTS 128, and if you have more events than that per frame (e.g. it's laggy and you wiggle the mouse a lot and press some keys) I think it will just drop any further events. Looks like it's fixed in SDL 2.0. Don't know if that's being triggered in this case, though.

comment:18 Changed 5 years ago by Pierree

It happend to me multiple times, with lagg related inputs. I use Ubuntu 14.10 and yesterday I looked into my SDL version installed and it was 1.2 so I installed SDL 2.0 and am now going to look how it responds to the change, maybe it is fixed now.

But maybe there should be added a fail safe in case there is a situation that SDL 2.0 is not available to use or someone can't install the newest SDL 2.0.

A simple fail safe like, after 5 seconds a key is pressed it checks whether or not the key is still pressed, if so continue like nothing happend, if not than reset the key to not pressed status. or anything similar.

Adding the SDL 2.0 library itself to the source is an option too, I see in the latest version of 0AD (16242) that SDL 2.0 library already has been added to the source.

Currently for the Alpha 17, a possible fix would be to install SDL 2.0 since most people don't have 2.0 yet, even I didn't on ubuntu 14.10 which got released like 4 months ago.

To install SDL 2.0 on Linux Ubuntu/Debian? use:

sudo apt-get install libsdl2-2.0-0 libsdl2-dev

for other distros, the library name is probably the same so just use your usual app install command, if library name is not the same you can also just google it :-)

It is not guaranteed to be a fix for this bug, but maybe it helps.

comment:19 Changed 5 years ago by elexis

The bug still exists on A18 (Singleplayer & Multiplayer). As mentioned above, it requires (1) that the game becomes 'laggy' and (2) that many keys are pressed.

(1) can be reproduced easily on DeepForest? with Deathmatch resources, 2x game speed and 300 units gathering wood in a small area.

It's an important bug, I experience it in > 50% of all Multiplayer matches and I feel im not the only one.

Changed 5 years ago by elexis

Attachment: savegame-lagfest.0adsave added

0ad savegame for Deep-Forest with 300 units, ready to lag

comment:20 Changed 5 years ago by leper

Milestone: Alpha 18Alpha 19
Priority: Release BlockerMust Have

Should be fixed by using SDL2 on Linux (see #2847).

comment:21 Changed 5 years ago by elexis

Some linux distributions provide custom patches for SDL 1.2.

Arch Linux has this one that specifically fixes this issue it seems:

"the last delivered keyboard event is a keypress, the release never arrives."

https://projects.archlinux.org/svntogit/packages.git/tree/trunk/SDL-1.2.15-SDL_EnableUNICODE_drops_keyboard_events.patch?h=packages/sdl

This might be the reason why one arch user doesn't experience this bug at all, despite using SDL 1.2 His version string is "1.2.15-7", while "1.2.15" is the most recent, official release and also the one used on Ubuntu 14.10 currently.

According to another player, Fedora is also affected by this bug.

comment:22 Changed 5 years ago by fabio

Resolution: fixed
Status: newclosed

SDL2 is now enabled by default everywhere, closing.

Note: See TracTickets for help on using tickets.