render.setMousePosition and logic.mouse.position Strange Behavior

This is using 2.66(haven’t tested it on others). I have just noticed that if I run either of those from a function in a module attached to a Mouse(Movement) sensor that the function continues to fire even after mouse movement stops. I only noticed because the logic use jumped about 4% when I touched the mouse but it never came back down. I confirmed it with a print statement. When I comment out the offending line, the mouse controller behaves like it should(only prints the test statement when I move the mouse). Uncomment the line and it just keeps on printing after the mouse has stopped moving.

Has anyone else noticed this? I searched on the forum and didn’t see anything relevant.

There is no need to use this attributes at all. The Mouse Sensor (in movement mode) already provides the mouse position (which makes the most sense anyway as the mouse sensor interacts with the mouse).

hmm, i guess i’m just not seeing how else you can manually set the mouse position without using either of those above. i hate to ask but what am i missing?

AH, sorry. I did not see your want to write the mouse position, rather than reading it.

In general, a controller runs for exactly one frame when it is triggered by at least one sensor. If you did not trigger the code (by sensor state change or true/false pulses) the additional processing should not be from your Python code.

Can you prepare a simple demo file?

This is it at it’s most basic. I made a few notes in there. If you are not running it from a console you can see that it is continuing to run if you have Framerate and Profile enabled - the logic usage goes up to 2% when it should be 0%.

setmousebug.blend (455 KB)

edit: i tested all 64bit versions back to 2.63a(oldest i have on hand) and the problem persists. the logic usage increases the farther back in blender version i went(barely noticeable increase, probably not related). i should mention that i am running openSUSE 12.2 64bit linux, latest official distro kernel.

i was beginning to suspect that this is what is behind all the mouse drift topics i have seen. if the function continues to run then it makes sense why someone’s mouse look script would drift at certain window sizes. unless this is only happening to me.

The problem seems to be mysterious but it is simple.

The long logic processing time comes from the print statement (printing to console is slow).
The print statement is called every frames after the first execution of the controller.

The problem arises when you set mouse cursor to any position.
This is recognized as mouse movement within the next frame -> which ends in a loop as this code changes the mouse cursor position too.

This can be seen as a bug but does not necessarily as setting the position is a change.

To avoid the loop you can set the mouse position ONLY when the current position does not match the new one:

mouseSensor = ...
currentPosition = mouseSensor.position

wantedPosition = [0,0]

if currentPosition != wantedPosition:

that’s where i was headed. thank you very much. i just wanted to confirm that it wasn’t only me. i agree that it’s not really a bug.

by the way, the higher logic usage continues with or without the print statement and incrementing code. i just included it for an extra visual.

works perfect. no more drifting or twitchy logic usage.