Opened 10 years ago
Closed 9 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 )
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)
Change History (24)
comment:1 by , 10 years ago
comment:4 by , 10 years ago
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 ht egame catches the keyup).
comment:5 by , 10 years ago
Description: | modified (diff) |
---|
comment:6 by , 10 years ago
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 by , 9 years ago
comment:10 by , 9 years ago
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 by , 9 years ago
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.
comment:12 by , 9 years ago
Milestone: | Alpha 17 → Alpha 18 |
---|
follow-up: 14 comment:13 by , 9 years ago
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 by , 9 years ago
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?
by , 9 years ago
Attachment: | commands.txt added |
---|
comment:15 by , 9 years ago
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 by , 9 years ago
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 by , 9 years ago
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 by , 9 years ago
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 by , 9 years ago
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.
by , 9 years ago
Attachment: | savegame-lagfest.0adsave added |
---|
0ad savegame for Deep-Forest with 300 units, ready to lag
comment:20 by , 9 years ago
Milestone: | Alpha 18 → Alpha 19 |
---|---|
Priority: | Release Blocker → Must Have |
Should be fixed by using SDL2 on Linux (see #2847).
comment:21 by , 9 years ago
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."
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 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
SDL2 is now enabled by default everywhere, closing.
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.