I recently tried using an experiment i created using the game engine with an MRI response box. the way the response box works is that it has 4 buttons, and when they are pressed sends a “keystroke” message to the OS (in other words, when i have notepad open it will type a letter when i click the button as if it were the key on the keyboard).
however, for some reason i am getting inconstant behavior from blender. the game works fine when using the regular keyboard, but when using the response box only works in about 60% of the times the buttons are clicked.
i tried using diffrent computers, and the phenomena was persistent, but with different success % for each computer.
i have no clue as to what might be causing this - any ideas?
i created a file as simple as possible - a simple box moving left-right using the “r” and “g” keys (which corespond to the red and green buttons on the response box)
this works easily and correctly form the keyboard, but not from the response box (or more accurately, works in 30% of the times it is clicked…)
ok, this is even wierder. i just hooked it up to a script that reads raw-input and print it to the console, and the response box works fine with it (it print “r” or “g” to the console) - so i will try to create a version that runs by script instead of logic blocks, but i still have no understanding of the problem…
Another update (thought the problem is still unsolved) -
It works better on faster computers. in fact, when run from a the best desktop computer i could find it improved to over 90%…
The problem is obviously with the keyboard event queue which misses some keystroke messakes. i need to bypass that somehow but have no idea how…
using python “raw_input” causes it ot block untill ninput comes. any other command? does blender support multi-threading within it so i can open it in a background thread?
I have the exact same problem, and was wondering if you happened to have made any more progress in solving it. Have you figured out how to bypass the keyboard event queue? I sent you a private message as well.
I cant claim to truly understand the problem but basicly I made enough progress to be able to ignore it - the problem doesnt exist on strong enough computers (especially with quad-cores and up), and when using the “allkeys” option in blender 2.5 the problem doesnt exist either (which is why in the long-term I am upgrading all of my experiments from 2.49 to the new version after putting it off for a long time…).
I also discovered that it depends on the exact model of the response box. for some reason the problem is much more severe on new response boxes (the actual box and optic cable are less significant. the important part is the gray box it connects to the computer through)
(so bottom line - currently i’m using the “good” old reponse box and a fast computer and thats enough, but thew next experiments will already be in 2.5)
You don’t call any blender api function or access any blender api attributes from any other thread then the main thread. That’s simple.
If You wounder what us other threads are, they can process stuff, call blocking functions (like raw_input) whiteout locking up the game. They can then put things back to the main thread through queues of some sort, and the main thread can send new tasks through queues. A lightweight queue that’s comes with python is deque. See: http://docs.python.org/py3k/library/collections.html#collections.deque