The attached file is a modified version of Raider’s mouselook script. It appears that most mouselook scripts suffer from the same disease. If your mouse cursor is not in the center of the game window, the camera will “jump” when you start the game, knocking your view off center. Raider was thoughtful enough to put in a line (line 44) that keeps the camera from jumping on the first frame no matter where your mouse is, but that only works if your mouse is moving during the first frame.
I am relatively certain that I remember seeing a mouselook script a long time ago whose author claimed that the camera jumping symptom had been eliminated, but I have not been able to find it.
I downloaded your file and tested, and no matter where I start with my mouse, the camera doesn’t jump at all. I tried moving the mouse when I started and keeping it still.
I also don’t remember ever downloading a Blender game that has a mouselook that the camera jumps at the beginning. Possibly it’s something with your computer or graphics card?
Ok, maybe I should have describe it better. For me, if you put your cursor in a corner of the game window and then start the game, nothing happens until you move your mouse, at which point the script moves the camera sharply towards your cursor. Essentially, you start with your view in a different direction, but only after moving your mouse.
Are you using a mac? There’s a bug in the mac version of blender where the mouse position is not updated until the user moves the mouse- so the script works fine, but blender doesn’t.
It doesn’t do that for me at all. It must be something on your end. I can put my mouse wherever I want. Start the game with it not moving, then move my mouse and it doesn’t jump or anything. It moves just like it should.
@Captain Oblivion
I’m not using a Mac, but that seems to be the same problem.
@gomer
I think that a good mouselook system should not require the user to place his or her cursor anywhere prior to starting the game. Plus, if you don’t know it’s going to happen, it’s a little weird.
@Monster
Actually, that doesn’t seem to be the problem with me, but thanks for alerting me that there are other problems.
I used another script attached to an “always” sensor that sets the mouse in the center, and that does work. However, I tried the file on a different computer without the new script and the old script worked perfectly fine without it. It appears that the old script works fine as long as the framerate is higher. The framerate is about 40 on this good laptop, but 10 on the computer that didn’t run properly.
Weird, but I guess that makes sense.
EDIT:
I haven’t tested it yet, but I’m assuming that the script will run correctly on just about any machine in a runtime. The runtime runs much faster than Blender on the weird computer.
I got the problem with the [0,0] on multiple Win PCs and multiple Blender Versions (can’t tell for 2.50).
The mouse sensor’s position is not updated when you click a mouse button without moving the mouse, but when you release the mouse button.
The mouse sensor’s position is always updated when you move the mouse.
You can test with this code (make sure the first sensor is a mouse sensor):
def showMousePos(cont):
for sens in cont.sensors:
print str(sens)+":",str(sens.positive)+",",
sens = cont.sensors[0]
print cont.sensors[0].position
To avoid the problem I recommend to add a mouse movement sensor. If this sensor is positive (at least the first time), you can read the coordinates from any mouse sensor.
The alternative was suggested above: set the mouse position explicit. For a mouse look where you wouldn’t see the cursor this is acceptable. The mouse is set to the middle of the screen later anyway.
Just a question…the problem didn’t occur on my system either, but I was wondering why you didn’t just attach an always sensor with True level triggering off?
That way, that sensor would fire once, and the mouse would be set back to the middle before the person even had time to touch it.
Yeah, that would work. Thanks! The name “always” kind of threw me off, so I didn’t think that would work. I wondered why the GE didn’t have an “onstart” sensor already. Well, that makes much more sense. :o
The Delay sensor set to a time of 0 does the same thing. I tend to think of it of the more “correct” way to do things on startup, although I always used the Always method back when there was no Delay sensor.
If you name it Delay or Always, both names are confusing if you want to trigger a controller once at start up.
But if you know how sensors trigger controllers both make sense. And I’m pretty sure they produce the same result.
I name the Always sensor without pulse modes “sInit” so I know it triggers at object creation. When I set True Pulse I call it “sAlways”. That makes it easy for me to see what the are supposed to do.