Bug #11771

Player unit continues to move indefinitely after keys are released

Added by sbsmac over 5 years ago. Updated about 4 years ago.

Status:Expired Start date:07/08/2010
Priority:Normal Due date:09/01/2011
Assignee:- % Done:


Target version:-
Affected ArmA II version:1.57.76815 First affected build:
Reproduced by another DH user:No First affected ArmA II version:
I am using some Mods:No Single / Multi Player?:
I am using: BIForumURL:
Reproducible for you:No NGUrl:
Related to content of DLC: WIKIurl:


This is an issue that was present in ArmA2 and has now also been seen in OA (both 1.52 and beta 71900).

It is possible, after a combination of key-presses, for the players's avatar to continue moving forward at a walk even after all keys have been released. The movement continues indefinitely until another movement key is then pressed and released.

This has been reported by many people during MP, I haven't yet seen it in SP although this may just be because MP PvP tends to lend itself to the kind of jinking and button-mashing that provokes the problem !

I suspect it is caused by some combination of sprinting (Wx2) and rapidly jinking left and right. I will add further informaton as and when I have it.

CTFRockyWoods-C5-.Chernarus.pbo (636.6 kB) sbsmac, 12/25/2010 13:14

Related issues

related to ARMA2 Community Issue Tracker - Bug #6033: [60141 & 60295] After respawn stuck in animation/keypress... Rejected 11/21/2009
related to ARMA2 Community Issue Tracker - Bug #13702: Player caught/trapped in sideways strafing animation loop Expired 09/15/2010
related to ARMA2 Community Issue Tracker - Bug #10462: disableUserInput - movement without pressing any key Assigned 05/03/2010


Updated by kju over 5 years ago

  • Due date set to 08/01/2010
  • Status changed from New to Feedback

hm are you sure a key combo to be the source?

I am only aware of the issue with disable key input to have the key(s) stuck
pressed that moment. Once we dropped that from AAS, we never ever had the problem again.

Updated by sbsmac over 5 years ago

I can confirm that disableKeyInput is not used at all in the missions that exhibit this behaviour.

The only key-related handling I do is

(FindDisplay 46) DisplaySetEventHandler ["keydown"," _null = [_this select 1] spawn check "];

where check returns true in the case where the pressed key is either bound to 'salute' or 'command mode'. One could imagine keyboard-matrix ghosting resulting in the wrong DIK-code being reported to the event-handler but the error here seems to be one where a keyup event is being lost (or, more likely, animation-state is becoming confused).

Xeno has also confirmed (by Wave) that he has seen this in his missions and thinks that it was introduced sometime just before the 1.05 patch release. My recollection is similar and it may have crept it around the time that #4043 was fixed.

So in summary, I'm pretty sure that this is not a script related issue but I'm still looking for a good repro case.

Updated by kju over 5 years ago

  • Due date changed from 08/01/2010 to 10/01/2010
  • Status changed from Feedback to Assigned

Xeno most likely refers to the changed behavior of disable user input.
It was introduced shortly before 1.05 final (aka in 1.05 BETA).

AAS was the only missions I know of with the problem
(due to that disable user input left over from norrin revive).

There might be very well a different issue; I am just pointing out this now
known source and once removed, we never had a problem again.

Updated by Xeno over 5 years ago

I had it a few times when playing online with OA, no other addons started.
It was a PvP mission (cfarma2 server). No revive, just plain and simple pvp.

Updated by Fireball about 5 years ago

  • Status changed from Assigned to Duplicate
  • I am using some Mods set to No
  • Reproducible for you set to No

Dupe of #13702.

Updated by BCA_Cat_Toaster about 5 years ago

I can confirm this, got already used to it honestly. Don´t know if it´s still present in the latest Beta-Patches. Will have an eye on it.

Updated by sbsmac about 5 years ago

  • Status changed from Duplicate to Feedback

Fireball - I'm not sure this is a duplicate. In my case I think the movement is forward rather than sideways. Quite likely the same underlying mechanism though.

Updated by kju about 5 years ago

Does it happen for someone who is not using default controls?

Updated by sbsmac almost 5 years ago

Still present (seems slightly worse) in 1.56.

Updated by kju almost 5 years ago

  • Due date changed from 10/01/2010 to 01/01/2011
  • Affected ArmA II version changed from 1.53 BETA to 1.56.76134

Updated by kju almost 5 years ago

Do you play with default controls?

Can you please attach a mission where it happens.

This has yet to be seen in ECL, AAS, A&S missions or anything we played in OA.
That said I heard that valhalla might have the problem (as do very old AAS versions
that had the DEH issue I think - cannot remember the exact source atm).

Updated by sbsmac almost 5 years ago

Yes, I play with default controls. It's happened for me (and others) on a wide variety of missions. I am starting to suspect it may be provoked when reloading on the move but because it only tends to happen a few times in several hours of gameplay it's very difficult to say for sure.

Updated by sbsmac almost 5 years ago

Happened again last night with 1.57 patch

Updated by Sickboy almost 5 years ago

DisplayEventHandler sounds plausible; have you confirmed there is no DEH usage whatsoever in the missions tested?

Updated by kju almost 5 years ago

  • Affected ArmA II version changed from 1.56.76134 to 1.57.76815

Updated by sbsmac almost 5 years ago

Sickboy - see comment #2. The maps I usually play (and have seen this problem on) are available from http://www.armaleague.com/apl_maps/apl_ctf_16-Apr-10.rar. Since these are based on my scripts I know that the only use of the key event handler is as described above. I'm also pretty sure I've seen this problem on maps based on completely different scripts. (See also Xeno's comment #4). If one supposes it is a problem with the 'keydown' event handler the only mechanism I can think of would be for keyboard-matrix ghosting to somehow cause a 'keyup' event for one of the move keys to be interpreted as a 'keydown' event for the salute action. Counter-evidence for this is that the problem does not exhibit the action I've bound to the salute key as would be expected if ghosting was at work.

Updated by kju almost 5 years ago

The script looks fine. A few suggestions nevertheless:

a) Instead of the sleep at the end you can do:

waitUntil {sleep 0.01; (!(isNull (findDisplay 46)))};

b) Use a switch statement in dokeyCheck. AFAIK I remember the issue in AAS was that the script not always returned a value for the DEH. This should not happen in yours, but maybe making it more robust will help.
c) Integrate the updateKeyBindings code directly in dokeyCheck. The async updating of the values may be a problem in rare cases.
d) Finally try to disable your DEH completely and see if it helps (via mission param).

Updated by sbsmac almost 5 years ago

Just experienced exactly the same issue on a mission with a completely different set of scripts. So really, I think all this attention on DEH is a red-herring.

Updated by kju almost 5 years ago

What mission was it? Can you attach it please.

Updated by sbsmac almost 5 years ago

Attached. No use of DEH that I can see.

Updated by kju almost 5 years ago

Thanks Mac. The mission is very simple, old school OFP coding. :)

The sticky keys action I know only happened with/after respawn;
this is different here, right?

Can you please attach your profile to see whether key assignment
are default or any different.

If it is only a controls issue, which it may well be too,
someone needs to sit down and spend some time in the editor
trying to reproduce it.

People have done this for various other issues too.
Should be doable here too.

Updated by kju almost 5 years ago

Found the one caused by disableUserInput again: #10462.

Updated by kju over 4 years ago

  • Due date changed from 01/01/2011 to 06/01/2011
  • CPU deleted (Please specify!)
  • Audio card deleted (Please specify!)
  • Size of OS swap file deleted (Please specify!)

Updated by zGuba over 4 years ago

  • Due date changed from 06/01/2011 to 09/01/2011
  • Status changed from Feedback to Expired
  • Assignee set to sbsmac

Updated by zGuba over 4 years ago

  • Status changed from Expired to Feedback

Updated by Fireball about 4 years ago

  • Status changed from Feedback to Expired
  • Assignee deleted (sbsmac)

Feedback timeout. We still have related tickets for those cases left repo'able.

Also available in: Atom PDF