And the main part of this that should make Social a little happier
These two types allow users to make use of the keyboard and mouse without the need for a keyboard or mouse sensor.
Full description from Moguri in the link, those with Python knowledge like myself will appreciate we can start removing keyboard and mouse sensors from various major game objects, especially if the game has a lot of keyboard and mouse events.
He has a bonus too, a 2nd patch which brings back most of the texface options to the UI.
But how to trigger the scripts without an keyboard/mouse sensor?
The Python controllers would never register a new event and
the use of the keyboard/mouse is hidden in the script (not visible at the logic brick).
My opinion:
I would never remove these sensors. If you produced “spagetti”-bricks you should think about a redesign.
The keyboard sensor already has an “all keys” mode. There is no need to have an sensor for each possible key.
If you produced “spagetti”-bricks you should think about a redesign.
Well, Im going to redesign my project when 2.5 will be finished
The Python controllers would never register a new event and
Maybe one “always” sensor would do for all of the python controllers that have something to do with keyboard. However, I´m not sure what will it do with performance. But Blender checks all of the sensors every frame anyway, so the differnce would not be so big… or am I wrong?
Here is an example script. It handles player movement based on keyboard input. All that is needed is an always sensor attached to a python controller with this script:
# Shorten GameLogic because I'm lazy
gl = GameLogic
# Import the GameKeys module for some constants
import GameKeys as gk
# Get the keyboard object
keyboard = gl.getKeyboard()
# Get the object that owns this controller
ob = gl.getCurrentController().owner
# Based on keyboard input, move the player
linv = 0.0
rot = 0.0
for key in keyboard.events:
# key[0] = keycode; key[1] = input status
if key[1] == gl.KX_INPUT_ACTIVE:
if key[0] == gk.WKEY:
linv = 10
elif key[0] == gk.SKEY:
linv = -10
elif key[0] == gk.AKEY:
rot = 0.04
elif key[0] == gk.DKEY:
rot = -0.04
ob.setLinearVelocity((0, linv, 0), 1)
ob.applyRotation((0, 0, rot), 1)
I am wondering why in priciple people complain on keyboard/mouse sensors? In other words at what curcumstances one needs these function to be exposed to python?
All that I can say is as I’ve been slowly learning python I’ve noticed a cleaner logic pipeline in my game.(I try to plan out as much dynamic interaction as possible in alot of my assets and objects.)
I also cut the use of switching states down to about half or even a single state for a given object.
Thanks Moguri and Ace Dragon for making this available especially your example. it’s simple and easy to understand.(just for fun and practice I’ll probably impliment it in Voidkeepers.)
When you have a class that needs mouse events and you don’t want to set up sensors in every scene. When you are just trying to get the mouse’s position and you feel that you really shouldn’t have to connect a sensor. (eg. mouselook)
All I did was copy the URL and make a thread about the patch because I thought it would be of interest. Moguri did all of the actual work, I don’t even have a compiler installed. Moguri deserves all the thanks for the actual work in helping to improve the GE as he’s a developer.
I currently do not write any code or patches for Blender and help with development, I just report developer mails and commits that would be of particular interest to the community.
@Bigbob:
You are right the sensors are checked each time. The processing of the controllers has more impact on the performance.
Any kind of controller that runs at every frame will eat more processing power than a controller that gets processed when a change happens.
This will be worse with a python controller and the controller performs checking (what the sensor should do) and does nothing most of the time (how fast can you type?).
I mean, imagine you go to the door every 5 minutes to see if someone is there instead of going when the door bell is ringing.
I aggree in some cases it makes sense to have a script run every frame. For this kind of processing the sensors have the pulse buttons.
What I miss with the mouse sensor is:
an “all key” mode. But three mouse sensors are not the big deal.
the real mouse position without the mouse moved. Currently it always returns 0,0 which is just incorrect.
