Original Post — Direct link

Putting bdisablemouseacceleration to True in the gameusersetting file and putting it to read only doesn't work anymore. What the hell are you thinking epic games, mouse acceleration totally ruins the game for me. It's inconsistent and unnecessary, could feel the difference straight away when playing in THIS season, also noticed all the gamemodes went back to "FILL" instead of staying at "NO FILL" when I had put my gameusersettings to read only from before this season. Please revert this change. Can't even play the game anymore ffs.

External link →
about 5 years ago - /u/MichaelNoland - Direct link

TL;DR:

There is not now, nor has there ever been mouse acceleration in Fortnite on Windows, and the only relevant input change recently is that in 7.40 we switched STW to use the same mouse sensitivity settings/behavior as BR (called out in the release notes https://www.epicgames.com/fortnite/en-US/patch-notes/v7-40 as "Sensitivity handling behavior unified across all game modes.").

For more technical details, read on.

If you want to follow along in the UE4 source code, you can add link your GitHub account to your Epic Account( it's free, you just need to agree to the UE4 EULA and follow the instructions here https://www.unrealengine.com/en-US/ue4-on-github).

UE4 uses 'high precision' mouse input directly whenever the mouse is captured (FSlateApplication::ProcessReply is what enables or disables raw input, and capture into a game viewport always sets it, c.f., FSceneViewport::CaptureMouse). High precision input means we grab the raw mouse move messages via the OS api, rather than grabbing the OS cursor position (which is subject to OS level smoothing and acceleration).

First off, there is a misleadingly named variable in FortGameUserSettings called bDisableMouseAcceleration, but this only affects how MacOS handles raw input at the engine level, and has never done anything at all on Windows at any point. On Mac there is a problem at the OS level with high precision input mode, which is why the bDisableMouseAcceleration variable exists:

/** Whether to disable Mac mouse accel */
UPROPERTY(config)
bool bDisableMouseAcceleration;

When the game user settings ini is loaded, this is copied into a console variable:

static IConsoleVariable* CVarDisableMouseAcceleration = IConsoleManager::Get().FindConsoleVariable(TEXT("io.Mac.HighPrecisionDisablesMouseAcceleration"));

if(CVarDisableMouseAcceleration)
{
    CVarDisableMouseAcceleration->Set((int32)bDisableMouseAcceleration);
}

The only place that defines or consumes the io.Mac.HighPrecisionDisablesMouseAcceleration console variable is in MacOS specific code (which you can view at https://github.com/EpicGames/UnrealEngine/blob/b70f31f6645d764bcb55829228918a6e3b571e0b/Engine/Source/Runtime/ApplicationCore/Private/Mac/MacCursor.cpp if logged in):

int32 GMacDisableMouseAcceleration = 0;
static FAutoConsoleVariableRef CVarMacDisableMouseAcceleration(
    TEXT("io.Mac.HighPrecisionDisablesMouseAcceleration"),
    GMacDisableMouseAcceleration,
    TEXT("If set to true then OS X's mouse acceleration curve will be disabled while using high-precision mouse mode (typically used when games capture the mouse) resulting in a linear relationship between mouse movement & on-screen cursor movement. For some pointing devices this will make the cursor very slow. (Default: False)"));

We default this value to false because, as the comment says, some Mac input devices will become incredibly slow if you try to use high-precision input mode in a raw mode.

On Windows, mouse input starts at https://github.com/EpicGames/UnrealEngine/blob/b70f31f6645d764bcb55829228918a6e3b571e0b/Engine/Source/Runtime/ApplicationCore/Private/Windows/WindowsApplication.cpp

When Slate is set to high precision mode (any time the game viewport has the mouse captured for gameplay), this means we use WM_INPUT instead and ignore WM_MOUSEMOVE messages. You can read about this here: https://docs.microsoft.com/en-us/windows/desktop/dxtecharts/taking-advantage-of-high-dpi-mouse-movement

From the platform layer, it takes a bunch of hops to get out of Slate and into engine-side gameplay land, but all of them are direct pass-throughs with no modification of the raw delta value from Windows along the way. At that point FN applies the sensitivity settings from your game input settings but does not mix the raw delta value this frame with the value from any previous frames. After that, it goes into FN game code and ultimately updates the player control rotation and player pawn orientation, again without any ballistics being applied.

Finally, it's worth noting that when the mouse is not captured (e.g., when you see a visible mouse cursor in the front end or menus), we do not use high precision mouse movement and default to the regular OS cursor input. This gives you the same 'feel' you expect from the mouse in other desktop applications (but not games), and typically does have acceleration applied (depending on your OS settings).

Cheers,

Michael Noland