Delta X and Delta Y for Mouse Movement no longer change when using UserInputService

[JasonTheOwner]

UserInputService results delta X and delta Y as illustrated in this link, no longer work:

http://wiki.roblox.com/index.php?title=API:Class/UserInputService/MouseBehavior

Uncopy locked proof:

https://www.roblox.com/games/749981875/Delta-X-and-Delta-Y-UserInputService-bug-Demonistr

See console for feedback - delta X and Y remain at 0 (zero) when moving the mouse around the screen. This breaks a lot of gun and camera scripts using UserInputService. Been broke about two weeks I think...

[kyle-emmerich]

This is intended behavior and has been the case for a long time. The Delta parameter is only non-zero when the mouse is locked.

The problem with your test place is that the mouse isn't being locked correctly. I'm guessing that the normal PlayerScripts camera is setting it to Default on the first frame after your script runs. This is undesirable behavior, of course.

[hockeychaos]

In fact, I tried to change the behavior once, but when I turned it on in production, a lot of games broke because they assume delta is (0,0) when the mouse isn't locked. Other apis like windows APIs do this as well so it at the least isn't uncommon.

On Mon, Apr 24, 2017 at 10:29 AM, Kyle Emmerich notifications@github.com wrote:

This is intended behavior and has been the case for a long time. The Delta parameter is only non-zero when the mouse is locked.

The problem with your test place is that the mouse isn't being locked correctly. I'm guessing that the normal PlayerScripts camera is setting it to Default on the first frame after your script runs. This is undesirable behavior, of course.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Roblox/Core-Scripts/issues/840#issuecomment-296759463, or mute the thread https://github.com/notifications/unsubscribe-auth/AG9Vinga-fRMd3N6-wru42l1qB7U3IiPks5rzNwIgaJpZM4NFtZh .

-- ben

[JasonTheOwner]

The example on the roblox page for moving the camera around by using the delta X doesn't even work anymore due to this though. It doesn't matter if the mouse is locked or not.. Using the default mouse it doesn't work.

Plus these are established gun scripts that were created last year (an FE conversion of Turbofusion) - now not working... I'm having to do my own Delta X, Delta Y calculation to work around this.

[JasonTheOwner]

Here's the example the roblox page - even shows how to lock the mouse.. This is broken:

http://wiki.roblox.com/index.php?title=API:Class/UserInputService/MouseBehavior

[hockeychaos]

This actually isn't broken, although the documentation could be better.

This doesn't work if you throw it in a local script because it may run before one of the camera + control scripts ends up overriding the behavior. You can test this by putting a wait(5) at the top of the example, and your cursor will lock.

For more info about camera + control scripts check out this page: http://wiki.roblox.com/index.php?title=Mobile_Controls

On Mon, Apr 24, 2017 at 10:51 AM, JasonTheOwner notifications@github.com wrote:

Here's the example the roblox page - even shows how to lock the mouse.. This is broken:

http://wiki.roblox.com/index.php?title=API:Class/ UserInputService/MouseBehavior

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Roblox/Core-Scripts/issues/840#issuecomment-296768668, or mute the thread https://github.com/notifications/unsubscribe-auth/AG9ViteZ-uy3seNk_RtKyVO71kH8Sf4Yks5rzOE6gaJpZM4NFtZh .

-- ben

[JasonTheOwner]

Thanks Ben and Kyle,

ON the servers, there seems to be no problem with the gun. With my code example that I sent you a link to, I can see there's definitely something happening with overriding scripts/settings - delta X, Y work for a bit, when the server first starts and then it all derails after a minute or less.

In Studio, on the Mac, I never see it working.. probably still a timing issue with scripts overriding the mouselock, as you said. The behaviour IS different, but as long as I know what's going on, I think I can figure out a workaround.

I try to keep my issue reports dry and without much warmth, but this time I'm going to say it:

Thanks again guys, keep up the amazing, brilliant work! Its looking great.