I guess your designed your finite state machine in a way that you need to check the events all the time. This might be necessary … may be not. Usually finite state machines do not need to run all the time. This is what makes them so efficient.
Oh dear, I didn’t mean to get back on to FSMs, I accidentally posted prematurely… What I was going to ask next was how can an FSM use callbacks if, (maybe I’m getting the wrong idea about FSMs) state changes are supposed to be generated internally from within the state? Like, I don’t want an external function reaching in and changing the state of the machine without mediation.
But after thinking some more it seems obvious that a mix of external callbacks and internal polling can do the job quite well.
What is left is the not so simple to build GUI to allow the user reconfiguration. This is something you need to create regardless what system you implement.
One problem on that is - the BGE does not support OS keyboard mapping. So you are limited to display key-codes and the not really sufficient default mapping to US keyboards (which btw. are not used in Germany at all). This means you see incorrect characters representing keys in the GUI.
Yes, Keymapping, and especially international keymapping is something most Blender users don’t get around to.
And after testing some Blends made by French Blender users recently I’ve noticed they don’t use QWERTY.
In my own keymapping function I just used the event to string method to label keys, actually I use a Korean keyboard, but it has American English layout:
So the eventToString method returns the correct strings, most of the time.
Annoying that the key labels will be wrong for non-qwerty users.