Mouse Script

So i am working on a game that will be kinda similar to how the Game Bastion works with the mouse. I need a script that will allow my character to track to where ever my mouse is on the screen.


Maybe this will help you :
Rotating around and zooming towards your character in blender game engine :



Mouse Script:

import Rasterizer as r

Thanks for trying but what i was thinking is that where ever i click it creates an empty that is only there as long as the mouse is held down and is parented to the mouse

Hey thanks for all the help. I was thinking about the invisible plane before u said it, but i just have no idea. I’ll have a look at all the links. Thanks :slight_smile:

I did a video tutorial on how to set up basic mouselook controls:

Maybe that could help.

If I understand your meaning of the mouse to 3d space, look at the blender wiki and find the ‘pathfinding’ page and open up the example blend and you will find a choppy, but efficent mouse to 3d space script. (you may need to tweak a few things with the script but I figured it out and I am no programmer) If you can’t find out how to do it I can give a step by step process of tweaking the script.


NinjAcademy: I am very interested in this, could you please be mores specific about which page you are talking about, a link would be nice:p

The Blender Wiki is very large, when you count previous versions, there is literally thousands of pages. For example is it this page ?

Or any of these other pages pathfinding

The point I was trying to make is that there is dozens, if not hundreds, of different ways of tackling the 2D/3D problem, they are all best guess approximations. When you map from 3D space to 2D space, you lose information. Going in the reverse, from 2D to 3D, that information never existed. As a result, you have to choose the method that best suits the objectives of your game.

There is literary classic called Flatland by A. Square, who lived in 2D space and was accidentally knocked out of his plane. The story is about his travels through the many hyper dimensions and how he perceived them. It is well worth a read!

Anyway, I am very interested in this and would be grateful for a link to the page you are referring to.


Ok Irvine, I can post the manual obstacles demo blend in the resources section.


I managed to dig through and find link for you Irvine, (or you can download it from the resorces page where I posted the blend)


Thanks NinjAcadem,

In general, when you refer to some other document, you should always post a link or explain why that is not possible. These post live forever, I myself frequently find myself reading post that are 6 or 7 years old and it is not inconceivable that a hundred years from now some student of history may read this post!

More importantly, the mysterious Google algorithm may take it into it’s head that this post is the best link for someone searching for “Blender mouse scripts”.

I know it is probably not directly relevant to your problem, but I have basically solved my current problems with the mouse and thought I would post the solution here because it illustrates what I meant by thinking outside the box. (Hopefully, it will also give you, or someone else, some ideas.)

Background: I am designing a GUI for a chess engine and for the Mouse-Pointer, I am using a lamp, (called the Mouse-Pointer,) which lives on a plane above the chess board. As it moves around the board, the cone of illumination indicates its position.

The initial problem: Because the pointer itself is invisible, I need to limit the Mouse-Pointers movements to the playing area of the board.

The dilemma: There are two coordinate systems, global and local. Ahh man, decisions, decisions… which do I use?

At first glance, there is not much difference between them. However, the player can rotate the chess board around the global Z-axis and the camera around the local X-axis… Big complication!

To list the advantages and disadvantages of each:

Local coordinates:

Advantages: Nice easy maths

Disadvantages: As the board is rotated, the apparent direction in which the Mouse-Pointer is moved by either the keyboard or mouse becomes confused. For example, moving the mouse to the right will move the Mouse-Pointer either right or left depending on the orientation of the board.

Global coordinates:

Advantages: Directional stability, moving the mouse to the right will always move the Mouse-Pointer to the right.

Disadvantages: The maths become a real nightmare, you are working with matrix transformations… :eek:
Sure, Python has the tools to do this, but… Let us just say that it is not to be undertaken lightly.

My solution: After playing around with both systems for three or four days, I finally had a brainwave… Use both!!!

What I mean is, work out the new position using the global coordinates update the Mouse-Pointers position and then, load the new position as local coordinates to check that it is inside the boards playing area.

Yes, it is obvious when someone points it out to you, but try figuring it out from first principles. I spent days struggling with some very high level maths, before I realized, that there was this nice, undocumented, conversion utility built into the BGE.

Anyway, here is the relevant code for using the mouse to move the lamp around the board:


# Takes input from mouse to move the 3D MousePointer around the chessboard.

# Note, Iam going to initialize the mouse to Mouse-Pointer position with a run once
# sensor and a python script attached to the board empty. The Mouse-Pointer position
# will also be updated by the keyboard script!

# import GameLogic and rasterizer modules
import GameLogic
import Rasterizer

# assign idx constants
x = 0
y = 1
z = 2

# other constants
boardsize = 8

# get controller script is attached to
controller = GameLogic.getCurrentController()

# Assign MousePointer
MousePointer = controller.owner

# get a list of sensors attached to the controller
SensorList = controller.sensors

# assign the keyboard sensors
Mouse = SensorList["Mouse"]

# get the size of the game window in pixels
MaxWindowX = Rasterizer.getWindowWidth()
MaxWindowY = Rasterizer.getWindowHeight()

# get the mouses position on the screen
wx = Mouse.position[x]
wy = Mouse.position[y]

# correct for the fact that screen coordinates are upside down. This makes the mouse y direction
# counter intuitive.
wy = MaxWindowY - wy

# translate the mouse plane onto the imaginary plane of the board 
mx = wx*boardsize/MaxWindowX 
my = wy*boardsize/MaxWindowY

# Update the Mouse-Pointers global position
MousePointer.position[x] = mx
MousePointer.position[y] = my

# Trick: get the Mouse-Pointers local position and use it to check that the Mouse-Pointer
# is inside the playing area
mx = MousePointer.localPosition[x]
my = MousePointer.localPosition[y]

if my > 8:
  my = 8
if my < 1:
  my = 1
if mx > 8:
  mx = 8
if mx < 1:
  mx = 1

# Update the Mouse-Pointer local position
MousePointer.localPosition[x] = mx
MousePointer.localPosition[y] = my

# I thought about keeping the mouse screen position in sync with the mouse-pointers
# local position, but in practice it isn't necessary. The reason it is not needed is simply
# that all mouse movements are relative to the position of the mouse. In addition while
# there are no problems with the keyboard-cursor script, when implemented in this
# mouse-cursor script, it caused a feedback loop.

# End 

That’s it folks, I hope it gives people some ideas.

So what i have here is a blend with the mouse overlay working
The way it works is I have an overlay with the graphic of the mouse.
Then in the actual scene i have an empty with the same script working and a light is tracking to it.

I was wondering if there was a way to add an object where the light is hitting.
I have seen it done before…kinda…it was with a bullet hole script. where ever u were pointing and when you shot it some ray actuator hooked up to some python would create an object(bullet hole) on the wall or ground.

Thanks :slight_smile:

I have a very slow internet connection and, right at this minute, don’t have the spare bandwidth to look at your model. Again though what you are describing is very similar to what I am currently working on.

Basically, you need to know where the light is hitting. That can either be done by calculation, having a physical bullet and Collision sensor, a Ray sensor aligned parented to the light, or some other brilliantly innovative method that leaves us fellow gamers gasping at your genius.

Make a list of advantages and disadvantages

advantages: Gives very precise location coordinates
disadvantages: Depending on the geometry, potentially very nasty maths. You can design the geometry of the setup to make this calculation easy.

Physical bullet:
advantages: used with a collision sensor, it can give a very precise location.
disadvantages: you are working with local and global vectors and the maths can be intimidating. The trick outlined in my script may help?

Ray sensor:
advantages: Nice and simple.
disadvantages: The precision depends on the size of the target.

Brilliantly innovative:
advantages: Potentially very lucrative, even if it is not patentable, it looks good on the employment resume.
disadvantages: Muses can be very hard to find.

Once you have the coordinates, it is just a case of pumping them into an Edit object actuator

Hope that helps,


I want to use the ray sensor but i have no idea how to script.

The attached image shows the targeting set-up of a spaceship game I wrote last year. The pilot dodges about in space blasting large asteroids. While at the same time, trying not to collide with the little darlings.

Not exactly the same as what you are doing, but similar. The guns fire nice glowing plasma charges that exploded spectacularly. In other words, I was using edit object actuators to position an explosion overlay at the position where the bullets collided with an asteroid.

I hope you can see from the crude plan I have drawn, that the problem I was having was that when the bullets were fired straight out from the gun, then they did not hit the asteroid at the point targeted in the HUD cross hairs. Similarly, you should note that if I had just taken the asteroid position using a Ray sensor, I would have had the geometric centre of the asteroid, not a point on the asteroid surface.

I have attached the python scripts that I wrote to adjust the trajectory of the bullets to make it line up with the pilot and his targeting HUD. Finally, I did not find the BGE’s built in Radar/Ray sensor to be very friendly and have included the scripts that I wrote to replace it.

Hope this helps


Remember, your bullets do not need to be visible and you don’t actually need a gun. You just bring them into existence at the position of your ray sensor, with a velocity directed along the sensors direction. This would make most of the maths in my scripts redundant. Note: If I remember correctly, if you use simple motion and the bullet is too small, it can step through the material without being detected. With servo motion, I do not think you have this problem(?)

Attachments (3.58 KB)

Hey i was having this problem last year so thanks for clearing this up. I fixed it my own janky way back then.
So how does this detect a flat plane and add an item where it sees a plane? (not trying to sound sassy right now, i just dont understand)

It does not detect a flat plane!!!

What it does is gives you the position that a bullet, (fired along the direction of the ray sensor,) collides with surface of the target mesh. That is not the same as the geometric centre of the mesh that you retrieve from a ray sensor. You should be able to see from the attached sketch what the difference between the two are…

In the sketch, if you add an object to the scene at the geometric centre of the wall, then it will be inside the wall. If you add an object to the scene at the point of collision, it will be on the surface of the wall.

I just remembered you were using a lamp to illuminate the target, so you don’t even need a ray sensor. Just fire the bullet along the direction of the lamp!