BGE LOGIC DEV: Long awaited Mouse Actuator upgrade is now in master

This actuator allows users to show/hide the mouse cursor using logic bricks, as well as control object rotation with a mouse in the BGE.
The mouse rotation is flexible enough to allow any type of mouse look, as well as banking for flight controls.

Good to see that Moguri is taking time to review and commit patches that have been sitting in the tracker, very good news for game developers and an indication that BGE is not dead in any sense.

I imagine a lot of people are going to reduce the amount of Python in their games in favor of this :slight_smile:

Wow, this is great news. I can’t wait to try it out.

This is going in the wrong direction, for 2 reasons:


It seems out of place in the context of the SCA paradigm, where actuators should perform on pulses (and information) received from sensors, via controllers. Instead, this actuator digs out inputs directly from the system, and goes on to perform actions that other actuators can already perform (to a large extent).

We already have a “mouse movement” sensor, and a “motion” actuator -> We should be able to compose them into a “mouselook” feature, and the fact that we can’t is the real fundamental problem.

A “mouse actuator” seems like yet another iteration of “if you can’t do what you should, do whatever you can” development methodology, which focuses on short-term gains, while ignoring long-term problems … Or goes on to produce just outright ridiculous nonsense, like the Save/Load additions to the Game actuator.


The whole notion of “specific feature bricks”, which are hardwired into the system, is pretty silly, because in being so specific, they are highly uncomposable, and therefore leave an open demand for even more bricks, which could never be satisfied in the core of the system (user needs are just too varied).

It would make far more sense to create a Python sensor, and a Python actuator brick. With those, we could at least provide everyone with a wide library of useful tools (in a well defined context), without cluttering the engine source.

This begs the question, does the BGE source code actually have a specific section for logic bricks (it all looks to be in Ketsji from the .diff output)? Also, just how many of the bricks have their own .cpp, and .h file as opposed to multiples clumped together?

Perhaps Moguri could look at trying to reorganize the logic brick code to more closely resemble the file structure used for the node types in Cycles, it would make it more straightforward to add bricks without worry about cluttering the code.

EDIT: Quickly looked at the developer site’s source code browser, some of the logic bricks are in Ketsji and some are in GameLogic, doesn’t seem to make much sense (is there any reason why the logic brick code can’t be ripped to its own GameLogic/bricks subfolder, which could possibly allow for the removal of Ketsji since a new developer would probably have no idea what the name means).

I agree with Goran, especially on point 2.

The good thing is I do not need to use it. So I can keep my bricks clean and still have my own implementation.
But I guess it will be nice for all the beginners not knowing how to implement such things by themselves.


Ketsji is the BGE. And yes the bricks have their own source files. If you want to look into the source be aware the object structure does not necessarily reflect the Python object structure or the GUI object structure.

This thread is about taking over an existing patch. It is not a feature request thread. Please open an own one.

I’m working on it, at this moment. See the proposal (

Awesome :smiley: look forward to having a go anyone know what blend version this will be in ?


Yes, you’re are right. To stay well in the SCA paradigm and to simulate the Mouse Look behaviour you would need, at least, a modified “mouse movement” sensor in which you can obtain separately the x and y movements (incremental, from center, etc) and a modified motion actuator which accepts non-fixed values.
This 2 modifications are in my TODO list.


The whole notion of “specific feature bricks”, which are hardwired into the system, is pretty silly, because in being so specific, they are highly uncomposable, and therefore leave an open demand for even more bricks, which could never be satisfied in the core of the system (user needs are just too varied).

It would make far more sense to create a Python sensor, and a Python actuator brick. With those, we could at least provide everyone with a wide library of useful tools (in a well defined context), without cluttering the engine source.

For this part, I’m not totally agree. I think you can mix general feature bricks with specific ones because you don’t have a totally general SCA system for any purpose. Actually, you have a relative general SCA system mainly oriented to game/physics simulation production. Then in this scope, I think it is better to have specific bricks that helps with very usual tasks (I know that we can never satisfy all user needs).

Anyway, I will very grateful if all of you (or part of you :slight_smile: ) do a list with the main improvements that the SCA system needs (from short term ones to long terms ones). This way I will have a better way to follow :slight_smile: .

Another way of looking at this is the existing logic bricks are inadequate to implement a more modular mouselook system of logic bricks. However, it’s not always clear cut, what should be the appopriate level of abstraction.

About why the source code is structured the way it is, the BGE source code is all over the place…


There is no reason to have them hardwired in the engine: Given a completely python driven system, we could have a “standard library” of common bricks.

Also, the distinction between “short-term” and “long-term” is harmful: It implies that there is something relatively simple, but useful, that can be done “right now”, without affecting the long-term viability of the system as a whole, and that’s simply not true. In order to make meaningful progress, one must step back, and do the really hard work up-front, to have a solid foundation for all the other things (history proves that to be true).

Anyone thinking about “contributing” to the BGE should ask themselves: “Do I have the ability to do what actually needs to be done?”.

As long as the answer is no, they should not touch the code, because that would just do more damage to an already scarred engine.

Want to make everything work for everyone?

Allow properties, and sensor attributes to be able to be used as brik input values.

MouseMovment--------and property add Mouse.x
If mouse.x min max----/


I think I agree that it’s best not to break the SCA paradigm, but at the same time, it’s already broken. For it to be fixed, you’d kind of have to separate Python access from the logic bricks entirely, because currently Python can act as a sensor, controller, and actuator. On the other hand, it’s not like the Python controller’s bad the way it is - it allows sensors to be polled, logic to be executed, and actuators to be activated. There’s nothing wrong with that role of the Python controller, per se. I know people who use Python a lot such as myself tend to really abuse it and end up with an Always sensor and a Python controller running everything about the object, which isn’t really how it was supposed to be used.

A possible solution that probably will catch a lot of flak might be to completely replace the existing logic brick system with the HIVE node system if/when it’s finished. If they’re as easy to use, then they would allow for more functionality and more modularity. For example, we’d be able to compose a MouseLook node of our own using existing sensors, controllers, and actuators, be able to save those nodes to a group and save them out to a library (blend file, for example). We’d also be able to share variables and properties out from one node to another, like BPR seems to want above.

I would imagine this would break any older games, which wouldn’t be too much of a concern since users can just use the old version of Blender until they start a new project. Of course, the sensors, controllers, and actuators that currently exist might easily be transposed to nodes if they haven’t been already. It might not be too difficult at all to make a script to convert logic over to nodes, as well. Each sensor, controller, or actuator can only be attached to one or more other bricks of only one other type in a single direction (S>C>A) - that’s a cake-walk for nodes.

In addition to nodes, adding Python bindings that correspond to all currently available logic brick functions (like the 2D filter actuator or the Radar, Near, and Collision sensors), and providing an ability to override a game object’s logic with a single Python class with pre-determined stub functions would help things out a lot, I think.

I’m grateful to have a MouseLook actuator, nonetheless. Thanks for the merge, Moguri!

Ray--------and----------property target=Ray.hitObject



but not python, direct data links, almost like nodes.

MouseMove(X,y)(cap properties in here?)------and------property X=Mouse.x etc.

The reason to have the bricks the way they are is because they perform logic done in C++ code, this means the potential to get execution speeds that are otherwise hard to obtain with Python.

Unless you are willing to develop an integrated JIT solution for the BGE that makes use of a compiled variant like PyPy or Cython, it’s best to keep, reshuffle and organize all of the brick related code.

Also, splitting the Python API into two sections to force adherence to SCA will neuter its power significantly in terms of things like automating logic and creating complex systems, so I don’t think that’s an option either.

Personally I think I don’t know enough about it all to be able to say if it’s good addition or not. Only thing I can say that there are still a lot of bugs that need to be addressed. Aside of that there’s a lot that could be improved in design, especially when it comes to structuring the code, or so I’ve learned when reading developers discussions over the years. Of course I welcome new features, certainly those that are essential for making game development more effective, but isn’t fixing bugs (= maintaining the already existing code) prior to all of this? Let me put it like this, that I’m just very grateful for the bug fixes of the last few months and I am looking forward to more. Keep up the good work, Moguri!

like so

Bump Bump—This makes sense right?

Yeah that’d be really easy. I think that HIVE’s nodes would be able to output the name of the hitObject or any variable to another node.

I agree with MrPutuLips that HIVE’s nodes already should be able to do it (and so it’s a good idea to have it there), but no, I don’t think logic bricks should have such a functionality. There’s no sense in taking the time to push something that, as far as I know, should already be in HIVE nodes into the logic brick system.

I guess the means to the ends don’t matter as much as the ability to be applied,

it just would make the existing system much more robust, without changing much ui at all,