Though since today read only does nothing, which makes the mouseacceleration command broken and your modes keep changing to a default setting. Read only means the file stays unchanged after checking it. 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).ġ00% sure, when you change your game modes to no fill and then put your gameusersettings to read only it should always stay at no fill. 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.įinally, 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. 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. You can read about this here: įrom 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. 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. 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. For some pointing devices this will make the cursor very slow. 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. TEXT("io.Mac.HighPrecisionDisablesMouseAcceleration"), Static FAutoConsoleVariableRef CVarMacDisableMouseAcceleration( The only place that defines or consumes the io.Mac.HighPrecisionDisablesMouseAcceleration console variable is in MacOS specific code (which you can view at if logged in): int32 GMacDisableMouseAcceleration = 0 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")) ĬVarDisableMouseAcceleration->Set((int32)bDisableMouseAcceleration) 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 */ 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).įirst 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. 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). 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 ). 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 as "Sensitivity handling behavior unified across all game modes.").
0 Comments
Leave a Reply. |