How to get access to mouse over sensor via python?

Hi everyone, i have a quick question about scripting. Please excuse my newbiness…

I have an ‘always sensor’ connected to a python controller. How can i get access to mouse over sensor without using any ‘mouse sensor’?

The only real way is to get the mouse position using bge.logic.mouse and then use camera screen ray to get the hit object

This is indeed a good question. I guess it is this is one of the question that are not computable.

May question:
Why do you have an always sensor connected when you need a mouseOverAny sensor?

Ups, sorry :o, maybe i should’ve asked: How can i get access to mouse over sensor without using any ‘mouse sensor’ logic brick? i dunno.

Anyway, i’m glad Agoose77 get my point.
Thank you for the answers Agoose77 and Monster :yes:.

My question is due to my lack of knowledge and experience, i guess. I’ve read in some threads before, about the downside of having too many logic bricks. So if i want to optimize for performance, i should have as few logic bricks as possible, right?

The thing is… a while ago i’ve seen a couple of video tutorials about scripting in BGE. In those videos, the tutor only uses always sensors to move a character and firing bullets. No ‘keyboard sensor’ at all in logic bricks (only for the bullets script he used an additional ‘Touch sensor’ logic brick). So i think, if we can use an always sensor without keyboard sensor in logic bricks, maybe we can use it to replace mouse sensor logic brick as well? Naive thought is it :o? hehe… sorry if it is.

As a beginner i really don’t know what will i find (a dead end or not). Whatever the result, i still believe that scripting as much as i can, is a good exercise to gain experience. I’ve played with hit.object before, but never touch the camera screen ray yet. I’ll try it ASAP. If i fail, i don’t mind at all using mouse sensor logic bricks.
Thanks guys.

No, Logic bricks are faster than any code you can write with Python.

The thing with the always sensor is this:
-> You enter your car by just jumping through the (hopefully open) window.

Some people think this is much more elegant as they do not need to open the car doors.

The thing with the mouse over sensor is following: you dig your own hole into the car as you want to avoid the door’s window.

There is no pure-Python solution with the BGE. That is as the BGE is not Python. Python is a kit (or toolbox) that provides you with a lot of freedom to customize your game. But it still runs on top of the BGE.

To stay with the car. You get a large toolbox to design the interior and exterior of your car. Your approach sounds like you want to avoid the existing doors and enter the car via engine hood.

I suggest to try to understand how the BGE runs. (you can find some guides in my signature)
There will be enough situations when you have to use Python.

My point is that you don’t need a logic brick to do mouse overs - you misunderstood my language dConclusionMan.
In many cases, I prefer to write logic in Python rather than use built in bricks - it’s a cleaner workflow, less breaks when recreating the setups. But, there are some cases whereby you should use inbuilt logic, because the performance cost is so great / impossible when working in code. For example, the collision system is not exposed to the Python API, and you only need one mouse over sensor to work with mouse overs in a scene, so why write it in code?

No python does not improve performance. It is just a tool. The design of your game improves the performance (or not).

Basically it is like this:

Not executing a controller (of whatever type) is faster than executing a controller
-> do not trigger unnecessarily.

A lot of logic bricks are slower then fewer logic bricks
-> try to reuse or avoid logic bricks.
-> in a lot of cases you can measure in a different way to avoid sensors
e.g. one MouseOverAny Sensor vs. a lot of Mouse Over Sensors
e.g. one player senses a lot of enemies nearby rather then a lot of enemies senses one player nearby.
-> be aware this strongly depends on the situation

In your example you have 4 Mouse Sensors (unfortunately you do not tell what configuration they have). You might be able to skip a few of them.

You have four always sensors (unfortunately you do not tell what configuration they have). You might be able to skip a few of them.

You can find some best-practice tips in my signature too (guides).

It’s not? Ouch, it seems like i did misunderstood some threads i have been reading in the past. I’ll do some experiments then, to find out when i should use python or just plain logic bricks. Thanks again, people.

Let me lay it out in simple form.
Code isn’t easily definable as fast or slow. We can profile code and determine its relative speed from the number of function calls it makes, and how long they take. In pure form, logic bricks are always going to be faster than Python, because they are written in C++, which is a faster (non interpreted) langauge. The reasons for using Python are twofold, firstly it gives you a greater scope in the engine, as you have access to an entire language, and not a subset of game-specific features, and secondly that it allows you to do more than one thing at the same time.
Logic bricks are typically good, and fastest for the functions they were designed for. However, when you want to make (for example) a Minecraft -like block building game, Giving each block logic to control itself is a slow approach. In such an instance, Python is faster because it can act as a parent overseeing the gamelogic, and perform smaller, only necessary calculations.

Thus, never segregate your way of thinking into “only this” or “that”. Instead, learn why people don’t just use either format of game logic.

Like agoose77 and Monster said, Python is only a tool. Used correctly, it can spare logic calculations that would be carried out otherwise. Inherently, Python’s not faster than logic bricks (but is slower, in fact). But, with Python, you can, like agoose77 said, put logic in one place rather than everywhere, or execute logic only on certain conditions (i.e. if a game object is onscreen). It’s best to learn about Python and choose between Python and logic bricks when the need arises.

Agoose, well said!

@Agoose77: Thanks for the explanation :). I’ll keep that in mind.

Speed comparisons between Python and C++ are sort of pointless. Saying “logic is better than scripting” doesn’t help much, because I have seen very, very bad logic design which could have been outdone by a script any day.

For speed, the goal is to have as little “thinking” going on at each frame as is possible. Whether it is logic or Python.

BTW, for Python speed, it is good to know best scripting practices. This is helpful:

there many reason because brick in a medium game become much more slow .

1-you need to keep all sensors ever active (due to the sca)
2-python can work very often out of sca
3-with brick you still ever to the same level , cannot learn nothing because brick make “all” for you
4-with python you learn of course (math , geometry etc) , so ,you game become ever more fast

  1. mouse sensor –> AND controller –> some actuators

  2. mouse sensor –> Python controller –> some actuators

  3. always sensor –> Python controller –> some actuators

  4. always sensor + mouse sensor –> Python controller –> some actuators

  5. always sensor + mouse sensor –> Python controller

  6. always sensor –> Python controller

With python like this:

Always sensor--- Python Controller----------------- some actuator
Mouse Over-- /                               \----- some actuator
                                              \---- some actuator
                                               \--- some actuator
                                                \-- some actuator

but not necessarily faster

the “triggers thing” has almost no sense with python
a script potentially heavy MUST already having also some line of control

plus the impulse thing not work correctly with python.
(try to put a keyboard with tap, the controller is read two time!)

not to be trusted, a always sensor true solve to the root the problem of this strange impulse

Marco, I think you still do not get the point.

The SCA is already a fast and well established event system.
Moving the event system to an own “Python event system” means you have to reinvent the wheel (and maybe buggy).

This is like you have a house.
You decide using the entry hall is “noobish”.
So you place all your furniture in the garage (as you do not want to use the entry hall).
Finally you live in the garage. You get problems to enter the existing rooms of the house. You need to mount bypasses to get electricity and water.

Indeed you can build a very cool garage. But why not using the house and build very cool rooms in the house.

A story about me:
I was on the way to do exactly that: Establishing an own event system via Python (basically a large FSM).
Then I thought, hey this is all the same, why not invent a GUI so I do not need to dig through this large code (it was nearly 3000lines of code spread other 30 files). Halfway after designing a GUI I realized the GUI is already there.

The GUI is indeed not perfect but it works in more then 90% of cases. The remaining 10% can be done in the garage ;). Using the garage means I would not even disturb my wife decorating the rest of the house. And do you really want your wife in your garage playing with your beloved tools?

(now translate: you = game logic developer, wife = level designer)

What did I learned from that:

  • Logic bricks alone are not sufficient enough
  • Python alone is not sufficient enough either
    => Take the best of both worlds (as long as you know what the best is :D)

the aspect of a garage is because BGE is not thinked around the python

for example , instead of 20/30 states , need 2 states which not exist.
one for the first frame (init) and one when the obj is destroyed.
other things can be done to make more confortable the house-garage

at moment you have two choose:

using python simulating a brick (cut much power to python)
using python how you want … in the garage!

bge is not the house of python

:smiley: :wink:

Indeed you are right. The house is the BGE. The garage is Python.

To make Python the house you would need a game engine build around Python like Panda3d or pyGame.

Indeed you are right. The house is the BGE. The garage is Python.

can become.

to be honest, what is sca? is a system to move the model of blender , not other.

is too rigid to manage a game.