I tried my file with a blendbot build r60141…and the problem is the same…Yes my scene does have an overlay scene And I do use python for keyboard …Heres a small file that recreates the problem. Press S to rotate the cube. Keep repeatingly press “s” and u will notice that the keypress doesnt always get registered.
nokeypress.blend (406 KB)
Well, I converted the UI of an old project to an overlay scene and I am starting to see what people are talking about here.
Moguri, Kupoman, Agoose77, I believe that this bug should be a priority fix because it affects such a basic game engine function for so many people, I read that Kupoman confirmed it in the bug tracker last month and mainly affects projects using overlay scenes, but now he has more information which might help with tracking it down.
And yes, I can confirm from the report information that this issue is in the embedded player only, launching the game in the Blenderplayer works fine.
You know, I can get used to using the Blenderplayer to test my games, the floating window for one thing means I can keep the text editor and such in the view so I can quickly get back to tweaking code, the fixes from Kupoman also means that it’s more viable as a serious testing solution. (no debug properties though, but it does have anti-aliasing).
But still, I would like to hear from Kupoman or Moguri to see if they made any progress on a fix yet.
Hi, guys, are you sure this has something to do with an overlay scene alone? Because I’m having this problem occasionally with bge.logic.keyboard in just one scene.
I can also confirm this with both sensor and with bge.logic.keyboard. Both get occasionally stuck.
nice.
Do you think it’s ok to devel in 2.67a and generate the .exe from 2.68 r57815 meanwhile ?
268a relase notes
I think the overlay scene may contribute to reproducing the problem but can have it happen simply attaching a a couple keyboard sensors to a cube to make it move left and right out of a fresh default scene. Nothing fancy needed so the bug exists without it being necessary. I am downloading the latest buildbot 64bit build for Mac to try out tonight. (Sep 18th r60216)
EDIT:
Okay I tested several of my scenes that it had been popping up in none of which use an overlay and I haven’t hit it in over 30 mins of testing. I am going to keep working in the buildbot build for the next couple days to see if it appears because it is a certainty that it will do it to me in the release 2.68a r58536 64bit Mac.
EDIT 2:
In investigating a problem with one of my scripts I noticed that it was easier to get the keys to stick if/when the framerate suddenly dropped for any reason. I made a test blend that adds small cubes with SPACE to a scene and parents them all to a larger one which can be moved with up and down arrows. When the total count of small cubes nears 2000 on my system and I press up or down the framerate suddenly drops and the key will stick 90 - 100% of the time. Esc will eventually work to exit or I am able to press up or down again to get the release of whichever key it was to register. This repros in the buildbot build I was using and the released one. No overlay scene needed.
I’ve posted the blend to my dropbox: https://dl.dropboxusercontent.com/u/41710/addObject_Keystuck.blend
Any update from the developers if this is going to be fixed, because this affects so many people that I can’t imagine it not being a high priority.
We get a collision API committed, but it’s not going to help the BGE if it’s decided that this bug won’t be fixed.
Downshift, go to the BGE bug tracker and attach the .blend into the active report, if the devs. can get a file where it happens that often it could really help them find the issue.
Done. I’ve updated #36319.
Thanks, DownshiftDX. I didn’t realize it yet, but now that you mentioned that the bug is occurring with ticrate drops, that’s exactly the case. I hope this bug gets high priority too.
A possible fix has been committed by Brecht.
http://lists.blender.org/pipermail/bf-blender-cvs/2013-September/059466.html
If it fixes the issue, then it would seem to me like the commit introducing this bug wasn’t exactly committed as part of BGE development, but to prevent addons from breaking if they were using SDL (this bug for example should fix the SDL errors printed to the console).
Good to hear this, Ace! Hoping what is being hoped!
Littleneo can mark this thread solved now, I tested a build with the fix and the game where I had the issue didn’t seem to have it anymore. This was verified with a mini-golf game where you use the mouse to rotate the direction in which to hit the ball.
In previous builds, the mouse movement mechanism would act somewhat drunk and drift around a little, the new build has shown to fix that. The keys to move the camera around would also get stuck sometimes, but the new build doesn’t have that.
Question: any chance of this affecting mouse also? I’m having a slight problem where mouselook keeps drifting even though it should only run the script when mouse sensor is active (.positive). Mouse sensor attached to python controller with no True pulse mode on.
It (the mouse “bug”) behaves similar to the keyboard issue (this bug discussed in this thread).
EDIT: oops I should read more, I see Ace Dragon already answered my question I think 
I have keypress issues with 2.68A* as well,
has anyone found a reason?
somthing change about the keyboard actuator?
I remember reading about some new keyboard additions having to do with other languages,
Read the page above your post, I’ve been running my game using the embedded player in recent SVN builds and I can confirm that the keyboard issues are fixed.
You can either download an SVN build or 2.69 RC1 now or wait until the official release.
Cool thanks 
it’s not that big of an issue as it’s just silly little demos I am making at the moment, so it’s a non-issue
thanks
I thought I was already on 2.68b but I am a silly person
Littleneo can mark this thread solved now
sorry Ace Dragon but I wont yet for 2 reasons :
. I just tried blender-2.68-r60555-win64.zip from buildbot and I still have issues with the mouse (left button is not working at all) but this could be me I did something a bit strange with mouse inputs (that works perfectly in 2.67). (and lost all of my driven shape key : ‘automatic script are disabled’ / ‘ID user decrement error’… omg).
maybe it comes from the project and stuff I don’t know about but I got no time to investigate in the next days.
keyboard looks fine this is great. I didn’t investigate with pads.
. build is not announced and published on the main blender board so for the normal blender user the bug is officially still here. and builboticially there’s still issues for me anyway.
has someone issues also with mouse buttons in 60555 (official win64 Sat Oct 5 02:53:48 2013) on buildbot ?
Did you try 2.69 testbuild:
thanks Mahalin I didn’t.
I spent a bit more time : everything is ok with the testbuild and the 60555 actually, sorry :o
KX_MOUSE_BUT_LEFT RIGHT and MIDDLE constants at least have changed and I wrote them as integers in my module,
and oh ok the ‘trusted source’ thing about the bones driven with expression…
and the standalone player is ok.
please note I had to edit the save as runtime script, (game_engine_save_as_runtime.py) :
comment line 115 :
# blend_path += '.blend'