Upcoming changes to scroll delta behavior

Updates Announcements
#1

Hi Creators,

We’re releasing an overhaul of how the engine handles scroll and trackpad inputs. For the most part this is a strict improvement, enabling the trackpad behavior people expect and fixing some nasty bugs, but it has some small backwards compatibility considerations.

In this post we’ll go over the current state of things, the new changes, and what potential problems to double check for in your scripts.

TL;DR:

The way the engine gets scroll inputs from trackpad / MagicMouse is changing and you may need to update your code to maintain your intended zoom / scroll rates.

  • The delta value passed in InputObject.Position.Z for MouseWheel events is changing.

    • Previously: The delta was always -1 or 1, except on Mac Client, where it was never larger than one but was often fractional.
    • Upcoming: The delta value is for the most part directly proportional to what the underlying system scroll event specified, and may be any floating point number on any platform.

  • We’re not expecting this to have a large impact because mobile remains unchanged and we included backwards compatibility affordances for most APIs.

  • Update checks like wheelInputObject.Position.Z == 1 to avoid breakage.

  • APIs other than MouseWheel input objects remain unchanged.

  • This will be rolled out in-experience by the end of March.

Current state of scrolling behavior

If you’ve ever dealt with event handling code much on Roblox, you’ve probably run into some confounding behavior related to scrolling, especially if you’ve tried to write code that handles multiple platforms. Here’s a brief rundown of just some of the current weirdness.

  • Mac Client and Mac Studio playtesting have completely different camera behavior.

  • Zooming out is faster than zooming in with Mac Studio but not with Windows Studio.

  • Windows trackpads do not scroll smoothly, they always scroll in steps like a mouse wheel.

  • ScrollingFrames scroll at hyperspeed when using a Mac trackpad.

  • On Mac Client you can horizontally pan a ScrollingFrame with MagicMouse but not trackpad.

  • On Windows, wheel delta = 0.5 for UserInputService.PointerAction but 1 for InputObjects.

  • Shift + Scroll to pan a ScrollingFrame works in Mac Client and Windows Studio but not Mac Studio.

How did we end up here?

Roblox has evolved to support more and more platforms and input devices over the years. Each round of support was well written on its own, but had a few rough edges. Unfortunately, not only do those rough edges add up over time, they compound, resulting in ever weirder behaviors.

Now, we’re thoroughly shaking all the accumulated nonsense out of the system.

Upcoming state of scrolling behavior

Our philosophy is to peel back all of the accumulated special cases in the platform specific trackpad / mouse code. Once we’ve done this, the clients can pass the native scroll behavior players expect from their systems directly to the engine, with just a few pieces of targeted backwards compatibility where required.

Following that philosophy, here’s what’s changing:

  • Windows Client / Studio, Mac Studio, Android, and Playstation no longer restrict scroll deltas.

  • Some input devices on those platforms will now pass scroll deltas other than -1 / 1.

  • Mac Client no longer limits the scroll delta to 1; flicks may be larger than 1.

  • This naturally supports smooth vertical trackpad scrolling on all platforms.

  • While playtesting, Mac Studio behavior now matches Mac Client behavior.

  • Inertia scrolling is enabled for ScrollingFrames on Mac.

  • The horizontal panning direction for ScrollingFrames was inverted, this has been fixed.

To avoid breaking existing code, we’ve also done the following:

  • Mouse.WheelForward and GuiObject.MouseWheelForward have been given reasonable behavior with all input devices. They offer a built in solution for scrolling in steps / pages.

  • The camera scripts have used UserInputService.PointerAction for input since 2019. This event will continue to fire with comparable values to support forked camera scripts.

  • We enabled inertia (continued movement after lifting your finger) for ScrollingFrames on platforms which support that. To avoid giving in-experience cameras on Mac unexpected inertia, public APIs like MouseWheel / PointerAction exclude events resulting from inertia on Mac.

Natural extensions which haven’t been implemented yet:

  • Horizontal trackpad inputs on platforms other than Mac.

  • Pinch to zoom in Studio (use I/O when playtesting on Mac if you have no mouse wheel)

Timeline

  • We’re adding a “Scroll Event Overhaul” beta feature in this week’s Studio release to test your code against the new behavior.

  • We’re going to attempt to enable the changes in mid March, and will keep the thread updated with what we’re doing. This is a complex change covering every platform so some platforms may have it enabled while others don’t as we work on rolling it out.

What’s needed from you

Check your code for two problematic UserInputType.MouseWheel patterns:

  • Code which checks inputObject.Position.Z > 0 but does not use the delta value will scroll excessively fast with a trackpad because it overestimates the intended delta.

  • Code which checks inputObject.Position.Z == 1 will no longer scroll at all with trackpad because the scroll value won’t be exactly equal to 1.

If you find one of these patterns, here’s how to avoid breakage when we release the changes:

  • If you want to scroll/zoom by a distance related to the input you should use the delta value in your math something like zoomAmount = rate * inputObject.Position.Z.

  • If you want to scroll in discrete pages / steps, use mouse.WheelForwards, someGuiObject.MouseWheelForwards or UIPageLayout which we’re mapping to a reasonable cross-device behavior out of the box.

You can test your code in Studio using the Scroll Event Overhaul beta feature once we make that available, or on Mac Client since Mac Client already sends smaller deltas when using trackpad / MagicMouse. Code which currently works on Mac Client should not require any changes.

Things to pay particular attention to:

  • Studio plugin UIs with custom scrolling behavior not using ScrollingFrame.

  • FPS experiences where you scroll to switch weapons.

  • Old camera code forked before 2019 (when PointerAction was introduced).

  • The zoom sensitivity of custom camera code using WheelEvent.

Let us know if you have any questions or concerns, thanks!

128 Likes
How to detect scrolling of mouse wheel
#2

This topic was automatically opened after 10 minutes.

#3

Will this Beta be there at Version 662?

I can’t wait (I hope for a) for DPI fix and UserInputService Keyboard input fix so that when games prompt me to press Y I don’t have to click on Z because QWERTZ and QWERTY. :thinking:

And SHIFT + 7 that triggers a "/" on some keyboard layouts, shouldn’t open the In-Game Experience Chat, to not interfer with Backpack and custom Sprinting. :thinking:

11 Likes
#4

Please tell me this will come with more control over how ScrollingFrames scroll. It’s maddening to try to scroll on small frames because of the lack of control over sensitivity for developers

10 Likes
#5

Yes, it’s in this week’s v662 release.

3 Likes
#6

Not immediately but not having to work around fragmentation between platforms will make further improvements easier.

20 Likes
#7

i had to create my own scrolling system because of that reason alone, I even replicated the scrolling tween. Ideally, us developers should just be able to adjust the scrolling distance/intensity on ScrollingFrames.

That aside, this change will be very good

6 Likes
#8

Do these improvements have any sort of priority to them? We know there was considerable work being done on them due to the new Explorer UI, but it’d be really nice to have that momentum continue forward and result in improvements to our amount of control as well

2 Likes
#9

Custom Mouse Sensitivity, even if it’s through scrolling. Is it good or bad? Because of LuaBridge :thinking: And to keep movement smooth.

Or maybe it’s because it has to be used with :RenderStepped or similar.

3 Likes
#10

Speaking of DeltaTime, will studio camera movement with high framerates ever get fixed? The controls become noticeably faster when the framerate is higher, and this has never been fixed or even acknowledged when proper framerate settings were introduced.

The same is also true for the Play-Solo Freecam with panning and zooming. I find it embarrassing that such trivially improper implementations of DeltaTime are riddled across the Roblox codebase.

4 Likes
#11

This is a little unrelated but a scroll sensitivity property would be very helpful and big improvement.
Something like:

— Can control the X and Y scroll sensitivity.
ScrollFrame.ScrollSensitivity = Vector2.new(2, 1)

Edit: When I say scroll sensitivity I mean the amount of pixels it moves when I Scroll in a direction. Example: achieving similar smooth scrolling like the studio workspace scroll frame.

6 Likes
#12

:thinking: Interesting?
2025-02-25T00:33:00Z

2 Likes
#13

This is fixed in the new camera controls beta.

3 Likes
#14

Even with the beta enabled the camera slows down / speeds up sometimes, I have to select a part and press “F” for the camera to do a zoom animation and fix itself. The camera controls are still not entirely fixed.

Also why would the camera fix be in a beta, it should be a full release by now. I hope they start fixing a bunch of stuff to do with delta and support frame rate.

4 Likes
#15

There is a free plugin made by Maximum_ADHD which fixes the issue without using the new beta https://create.roblox.com/store/asset/8193134286/FPS-Unlocked-Studio-Camera

6 Likes
#16

As both a developer and player that uses both a Windows machine and a macOS machine, I am excited to see fixes for parity across operating systems for scrolling behavior coming.

3 Likes
#18

Is this somehow connected to an issue where scrolling in scrolling frames would get stuck at some point and not let you continue scrolling?

2 Likes
#19

I really appreciate it thanks! :smiley:

3 Likes
#20

Great to see this as an upcoming feature just wish you announced it about 2 weeks ago before I made my own custom scrolling handler

4 Likes
#21

thank you for taking into account devs who use forked playermodules

4 Likes