EDIT :
lastest builds are ok ! see #38 and #39
nevertheless it’s not annouced yet on blender.org, the download link still points to th version with the keyboard bug.
it looks like there’s issues with the keyboard sensor (allkey) ?
I can’t reproduce yet in a simple test file, but this big game that works fine in 2.67 has delays and misses KX_INPUT_JUST_RELEASED (stays ACTIVE), and JUST_ACTIVATED very often in 2.68a.
setup :
keyboard sensor, true leveltriggering enabled, all keys
controller python module to ‘inputs.keyboard’ (same issue with a python script)
inputs module :
def keyboard() :
co = g.getCurrentController()
ow = co.owner
for key,sta in co.sensors['keyboard'].events :
print(key,sta)
play, test with A key :
97 1 (just activated)
97 2
97 2
97 2
97 2
97 2
97 2 (just released)
97 2 (hey you should be 3 buddy)
97 2
97 2
97 2
97 2
97 3 (Z key just activated : A finally switches to 3.)
122 1
122 2
…
it does not react 1/3 times (nothing in .events)
what could I check or tweak ?
EDIT :
lastest builds are ok ! see #38 and #39
nevertheless it's not annouced yet on blender.org, the download link still points to th version with the keyboard bug.
I can’t tell you where to begin looking but this may be something I have seen recently as well. The keyboard actuator seems to be getting stuck on occasion causing my character to just continually run in the direction of the key press. Other keys will still register and allow me to stop the movement temporarily, but as soon as I release them it is like the stuck key is still down.
I thought my keyboard may be the problem so I tried a different one and it reproduced. I haven’t investigated beyond that since it happens rarely.
I’ve been having a similar problem. A quick question to both of you, does the scene with the problem have an overlay scene?
It seems to be I only experience this issue when there’s an overlay scene present.
I don’t have an overlay scene in any of my bits and pieces of my project that I’ve been working on. (But this is assuming it is really all the same problem.) I haven’t gotten to implementing handing all the keyboard input in python yet for any of my projects, just the mouse and the basics for joystick support. Everything using the keyboard has been through the keyboard sensor either triggering a python module or an AND to a motion or property actuator.
I’ll try poking around with my first-person test area blend that it happens most often in tomorrow.
Any news on this? Added more code and the keyboard problem frequency seems to rise with logic usage %. I am using direct python keyboard states instead of the sensors.
If all else fails and you really need keyboard/mouse input, you could always use a Python module. Although this will be specific to the OS so Windows will require accessing the Windows API using pywin32 and Linux assuming X Windowing System, would probably require access to xlibs/xcb through python bindings. Or pygame, pymouse, etc. for a more cross-platform solution.
I haven’t been able to pin anything down yet but it has been happening for me both using a keyboard sensor with python and the logic brick sensors directly tied to movement actuators. I have a straight forward function for accessing them like this:
def getKeyInput():
retKeys = []
for key,status in sens.events:
if status == g.KX_INPUT_JUST_ACTIVATED:
retKeys.append(e.EventToString(key))
elif status == g.KX_INPUT_ACTIVE:
retKeys.append(e.EventToString(key))
return retKeys
I store retKeys in the globalDict for anything else in the game to look at that needs access to the keys right now, though eventually it will all be in the one script and will check against what mode the game is in for what keys should be doing. I suppose I should check to see if this applies to other input such as controllers as well…
I seem to be getting a 1 / 20 repro when “tap” is set on the sensor and when it repros the key is clearly shown just as if it was being held down continuously and pressing it again will clear it. I could be wrong but it seems much less likely to happen for me when my sensor doesn’t have tap set. (I usually use the sensor to feed my script with no settings at all…) It may also happen more often when pressing multiple keys but I am not convinced as I’ve been hitting WAS together repeatedly and in pair combinations and having some success, but then I have had it hit when I press just W to move forward when the start the game engine or after some time continuously holding D to run into an object that prevents movement… I just can’t work out 100% steps to reproduce it yet.
I think a bug should be filed anyway as enough people have been seeing this. Maybe there was a recent change that screwed something up and the dev in charge will know where to look.
Can one of you download a buildbot build so we can tell the devs. if it’s in need of a fix?
I tend to use recent SVN builds and I have tried four different projects to see if this bug occurs (one of them with an overlay scene), all of the tests on my end turned out negative.
Here is an example script that doesn’t use any mouse or keyboard sensors. You guys might wanna try it. It only needs an always sensor connected to a Python controller set to module execution mode for the object you want to control.
def main(cont):
import bge
keyboard = bge.logic.keyboard
active = bge.logic.KX_INPUT_ACTIVE
scale = 0.6
cont = bge.logic.getCurrentController()
obj = cont.owner
mouse = bge.logic.mouse
width = bge.render.getWindowWidth()
height = bge.render.getWindowHeight()
NWidth = (width / 2) / width
NHeight = (height / 2) / height
x = round(mouse.position[0] - NWidth,3)
y = round(mouse.position[1] - NHeight,4)
obj.applyRotation([0.0,0.0,-x*scale], 0)
obj.applyRotation([-y*scale,0.0,0.0], 1)
bge.render.setMousePosition(bge.render.getWindowWidth() // 2, bge.render.getWindowHeight() // 2)
if keyboard.events[bge.events.WKEY] == active:
obj.applyMovement([0,0,-0.5], 1)
if keyboard.events[bge.events.SKEY] == active:
obj.applyMovement([0,0,0.5], 1)
if keyboard.events[bge.events.AKEY] == active:
obj.applyMovement([-0.5,0,0], 1)
if keyboard.events[bge.events.DKEY] == active:
obj.applyMovement([0.5,0,0], 1)
if (keyboard.events[bge.events.LEFTSHIFTKEY] == active
and keyboard.events[bge.events.WKEY] == active):
obj.applyMovement([0,0,-2], 1)
I’ve had this problem before and I can’t seem to remember how I fixed it, but you could always consider switching to the python keyboard instead, that one works without a hitch.
I just noticed that my example file works ok only as long as it doesn’t have the overlay scene added. As soon as i add the overlay scene to the camera the mouse starts to drift out of control. Seems to be a bug in the source code somewhere.