compile esc key inconsistancies

Hey guys,
I’ve been having some problems with the esc key ending my simulation. The simulation I’m working on has an extensive menu system so I wanted the esc key to ‘go back’ rather than quit the game. This works fine when running it in Blender or when its compiled and run in a window… yet when compiled and run in full screen the esc key shuts down the simulation. I’ve tested this with the simple cube in a default simulation to double check and sure enough it still does it.

Is Blender designed to function differently for fullscreen vs windowed? If so, how can I turn that off? Or failing that… can I just turn off the esc key binding to quitting the simulation?

I’m running Vista Business on a Vostro (Dell) 200 and have replicated the bug on other Vista Business machines.

Is there a reason why you couldn’t just use another key?

Yes I have the same problem and dyeing to know how to get rid of that little irritation
Even the Eternal Odersey (sweet) has this trick of ‘hiding’ or closing the console window without quiting the game and the esc is a bit different(although it still quits the game)
How are these little thing done??

@DarkGuy: Everyone instinctively presses the Esc key to get out of something so no, I can’t really use another key.

@TrueFlection: Ahh I’m glad I’m not the only one! Could you post a link for how to hide the console window?

What version of Blender are you using? The Esc key function should be consistent in Blender 2.46 and later. Prior to 2.46 the behavior was inconsistent as you described.

Thanks! That’ll be it… I’m using 2.45.

Hey the dave,

I use version 2.46, made a little demo and tried to use the escape-key in the game. (see atachement).
When in fullscreen mode the escape-key does not automaticly end the game-engine; at least not in my demo.
On the other hand I did not compile it, this might make a diverence.

Greetings to you


(If your game stays aborting when pressing the escape key, you could try making a keyboard hook, so to get the keycode in your program first, before it is send to Blenders Ge (or not send it at all)).

Hey again,

I found this o the I.N.

might be important, because I suspect Blender using pyHook to (or somthing like that).


Hey Jbal,

Thanks for the link and the testing. It was only the compiled version that had the inconsistancy. I’ve talked it over with the others and we’ve decided that the most efficient solution is to upgrade to 2.47. We can’t see any reason why our project would stop working (or break in any particular way) so the only thing left to do is try it out =) If that doesn’t solve the problem then I’ll be sure to post but that seems extremely unlikely.