ScarOptions

What ScarOptions does

ScarOptions is the options menu you were going to spend a fortnight building. Five pages, Graphics, Display, Audio, Gameplay and Controls, build themselves in C++, save to the same file the engine already uses, and re-apply themselves on every launch.

What makes it quick to live with

• Zero setup, genuinely. Reparent a Widget Blueprint to ScarOptionsMenuWidget and add it to your menu. Or skip even that and call Open Scar Options Menu with an empty class: the built-in layout is a full-screen, blurred, tabbed panel that works with no art at all.
• It does not fight your project. ScarOptions never replaces UGameUserSettings, so a project that already subclasses it, and there can only ever be one, still works. No DefaultEngine.ini edit anywhere.
• Every row can be undone. A small amber arrow appears beside any setting that differs from what it was when the panel opened, and puts that one value back.
• No Apply button, on purpose. Changes write to disk a moment after the last edit, and closing the panel flushes anything still pending.
• Edit the panel, do not rebuild it. One button generates a Widget Blueprint of the built-in layout into your project, already named and wired, so you can restyle it and keep the rest.
• Rebinding for both input systems. Enhanced Input and the legacy Action/Axis mappings are both detected and listed together, with one row per axis direction so rebinding "forward" cannot silently cost the player "back".
• Good defaults before anyone opens it. On the first launch on a machine, ScarOptions benchmarks the hardware and picks a scalability preset that fits.

Two-minute setup

There is no configuration step. Enable the plugin and pick whichever of these two routes suits your menu.

Route A: your own Widget Blueprint

1. 01Right-click in the Content Browser, User Interface, then Widget Blueprint. Name it WBP_Options.
2. 02Open it, File, then Reparent Blueprint, and choose ScarOptionsMenuWidget.
3. 03Add it to your menu however you add any widget: Create Widget then Add to Viewport, or drop it inside an existing panel.

Route B: one node, no Blueprint at all

Drop Open Scar Options Menu into any graph and leave Menu Class empty. It creates the built-in widget and adds it to the viewport.

Open Scar Options Menu
    Menu Class = (empty -> built-in layout)
    Z Order    = 100
    Return     = the menu widget, if you want to keep a reference

Closing the panel

The X and any Back button fire On Close Clicked, a dispatcher, so bind it from whatever opened the menu: a pause screen that has to come back, a controller that wants gameplay input again. BP On Back Clicked covers the same moment for a Blueprint subclass. The menu then removes itself and hands input back.

Switch Remove On Close off to close it your own way instead: swap to a home screen, play a fade. Settings are already saved by the time either fires, so there is nothing to confirm.

What the player sees

Five tabs across the top, a scrolling list of rows under them. Every row is a label on the left, a control on the right, and an undo arrow that appears only once that row has been touched.

Graphics

Overall Quality is the preset: Low, Medium, High, Epic, Cinematic. Changing it moves every per-feature row below it, exactly as the engine scalability system does. The eight per-feature rows are View Distance, Anti-Aliasing, Post Processing, Shadows, Textures, Effects, Foliage and Shading.

Motion Blur closes the page. It drives r.MotionBlurQuality and, unlike the rows above it, the engine does not persist it on its own. ScarOptions does.

Display

Audio

Master, Music, Sound Effects and Voice Chat, all 0 to 100%.

Gameplay and Controls

Gameplay carries Mouse Sensitivity, which applies itself to both input systems, and Camera Shake, which your game applies with one node. Controls carries one rebind row per action, one per axis direction, and a Reset All Bindings row at the bottom.

Where settings are stored

Everything lands in one file:

Saved\Config\<Platform>\GameUserSettings.ini

That is the same file the engine already writes. Settings the engine owns, resolution, window mode, VSync, frame rate and every scalability level, stay in UGameUserSettings where they have always lived. Settings it does not own, the four volumes, sensitivity, camera shake, the two toggles, gamma and motion blur, live in UScarOptionsUserSettings, which writes to the same file.

Why not subclass UGameUserSettings

The usual way to add settings is to subclass UGameUserSettings and point GameUserSettingsClassName at it in DefaultEngine.ini. That is a fine choice inside a single game and a bad one for a plugin: a project can only ever have one such class, so a plugin that claims it is unusable for anyone who already subclasses it, which is most projects of any size.

• No ini edit. Nothing to add, nothing to get wrong, nothing to document for your team.
• No conflict. Your project keeps whatever UGameUserSettings class it already has.
• Same file on disk. One place, one restart, everything the player chose.

Applying on launch

A game-instance subsystem re-applies audio, gamma and motion blur on every start. The engine restores none of those on its own, which is the usual reason a hand-built options menu forgets the volume between sessions. It defers by one tick, because at subsystem-initialize time the audio device and RHI may still be coming up.

On the very first launch on a machine it also runs a hardware benchmark and applies the scalability preset that fits, so the game looks and runs right before anyone opens a menu. It runs once, ever, and can be switched off in Project Settings.

Project Settings

Edit, then Project Settings, then Plugins, then Scar Options. Every field here is optional; the menu works with the page untouched.

The Controls page

Click a row, press a key. Escape cancels and leaves the row exactly as it was. Delete or Backspace clears the binding. Mouse side-buttons bind like any other key. Left-click is excluded, because that is how the row was clicked in the first place.

It takes effect immediately

A rebind writes straight into the project action and axis mappings and rebuilds the key maps, so it is live on the next key press, not the next launch. It then persists to Saved\Config\<Platform>\Input.ini.

One row per axis direction

An axis such as MoveForward is really two bindings, W at +1 and S at -1. Giving it a single row would mean rebinding "forward" silently destroys "back". ScarOptions builds one row per direction and labels them MoveForward (+) and MoveForward (-), editing only the mapping with that exact key and scale.

Analog sticks and mouse axes are skipped. They are not single keys, and binding one to a keyboard key would break the axis.

Reset All Bindings is a real reset

It reads Config/DefaultInput.ini, the file SaveKeyMappings never writes to, so it restores what the game actually shipped with rather than re-saving whatever the player already changed. It only touches binds the player was allowed to edit, so debug and dev-only binds are never destroyed. If no defaults are found it logs a warning and does nothing, rather than wiping every binding.

Both input systems, on one page

Restyling a rebind row

With no art, each row builds its own button and caption. To style them, make a Widget Blueprint parented to ScarOptionsKeyBindRow, add a Button named KeyButton with a TextBlock named KeyLabel inside it, and set it as Key Bind Row Class on the menu widget.

Undo and autosave

The amber arrow

When the panel opens, every row value is recorded. From then on, a row whose value differs from that record shows a small undo arrow on its right; clicking it puts that one setting back. A panel nobody has touched shows no arrows at all, so the arrows are a live diff of what this visit changed, not a row of decorations.

The baseline is captured on construct, which means closing and reopening the panel makes the current values the new baseline. That is deliberate: once the player has left the screen, those values are simply what they have.

Autosave

Changes are written to disk a short time after the last edit, 0.35 seconds by default. The delay is a debounce: dragging a slider fires hundreds of change events, and without it every one of them would be a disk write. Closing the panel flushes any write still pending, so the last change a player makes before hitting the X is never lost.

Because of all that, there is no Apply or Save button in the default layout. There is nothing left for them to do. If you want them back for familiarity, tick Show Legacy Action Buttons and the Apply / Save / Reset / Cancel row is built at the bottom.

Live apply

Apply On Every Change is on by default, so the player sees the effect of a graphics setting the moment they change it rather than after committing. Turn it off if the apply cost is painful on your minimum-spec hardware.

Blueprint reference

Get Scar Options Settings returns the live settings object from any graph. Everything in the first table is called on it.

The settings object

Helper nodes

On the menu widget

Setting ids

For Undo Setting, and for reading On Scar Option Changed:

Resolution       WindowMode        OverallQuality   ViewDistance
AntiAliasing     PostProcessing    Shadows          Textures
Effects          Foliage           Shading          VSync
FrameRate        ResolutionScale   Gamma            MotionBlur
MasterVolume     MusicVolume       SfxVolume        VoiceVolume
MouseSensitivity CameraShake

Camera shake and sensitivity

Most of this menu applies itself, Mouse Sensitivity included. Camera Shake is the one setting the engine has no global hook for, because there is no such thing as a project-wide shake multiplier, so your game applies it at the point of use with one node.

Camera shake

Replace Start Camera Shake with Play Camera Shake Scaled and you are done. It applies the player multiplier for you, and skips the shake entirely when they have turned it to zero rather than starting one at zero amplitude that still occupies a modifier slot for its full duration.

Play Camera Shake Scaled
    Player Controller = Get Player Controller
    Shake Class       = your shake
    Base Scale        = 1.0

If you start shakes some other way, Apply Camera Shake Setting gives you the multiplier on its own.

Mouse sensitivity

Applies itself. The legacy mouse axes get the setting through the sensitivity the project configured for them, scaled. Enhanced Input gets it through a Scar Options Mouse Sensitivity modifier that ScarOptions adds at runtime to every mapping that reads a mouse axis. At 1.0 nothing changes.

To apply the setting to something else, add that modifier to the action or mapping yourself. To take over entirely, switch Auto Apply Mouse Sensitivity off in Project Settings and run your look input through Apply Mouse Sensitivity before it becomes rotation.

Styling and custom layout

Three ways in, in increasing order of how much you want to change: adjust properties and change nothing else; start from a generated copy of the built-in panel; or place every control yourself.

Start from a copy of the built-in panel

Tools, then Scar Options, then Create Editable Menu Blueprint. This generates a Widget Blueprint of the whole panel into your project and opens it: background, header, title, tab strip, and every setting row laid out as it appears in game. Move things, restyle them, delete what you do not want.

It behaves like the built-in panel because it is the built-in panel. Every widget is named so the plugin binds to it, the category tabs still filter the rows, values still load and save, and the drop-downs and tabs are styled by the same code the runtime uses.

A second button, Create Editable Menu (frame only), generates just the surround and leaves the rows to build themselves at runtime. Both are also available from the console as ScarOptions.GenerateMenu and ScarOptions.GenerateMenu frame, so the asset can be regenerated from a script or a build step.

Two things are deliberately left out of the generated asset. Resolution has no options, because the list comes from the player own display at runtime and anything written in would be a guess. And the rebind rows are a named empty container rather than a list, because they are built from whatever bindings your project defines.

Styling without touching layout

Building your own look

Everything on the panel can be hand-placed in the UMG Designer, and controls are matched by name. Drop a Slider on your canvas, call it MasterVolumeSlider, and it is the master volume slider: ScarOptions binds it, pushes the saved value into it when the panel opens, and writes the player changes back. Style it however you like, because the plugin never touches its appearance.

Layout slots

Control names by page

Three rules worth knowing

• Sliders are forced to 0-1. Every handler maps that range into the real one itself, so a slider left at some other range would drive its setting to the wrong place, silently, which is worse.
• Drop-downs keep options you typed, because selection is by index. The two exceptions are Resolution and Frame Rate Limit, which ScarOptions always fills: a hand-typed resolution list is wrong on every machine but yours, and frame-rate entries have to stay in step with the limits in Project Settings.
• Value labels are optional. Supply MasterVolumeLabel and it gets "75%" written into it; leave it out and nothing is drawn.

Input behaviour

Auto Capture Mouse On Show, on by default, takes UI-only input on construct and re-asserts the cursor while the panel lives, defending against other UI that hides the cursor on its own tear-down. On close it hands input back as GameAndUI, because whatever opened the options is usually still on screen and still needs a cursor.

Restore Cursor On Destroy is off by default. Turn it on only when the options panel is the only thing on screen and you want the cursor hidden and GameOnly input restored when it closes.

Console commands

The editor tab

Tools, then Scar Options, opens a panel with the plugin and engine versions, a shortcut to the Project Settings page, the two buttons that generate an editable copy of the menu, and two actions worth having without launching the game: Run Hardware Auto-Detect Now and Reset Saved Player Options. The last is the fastest way to see exactly what a brand new player sees.

Engine compatibility

ScarOptions ships as one zip per engine release, UE 5.2 through 5.8. Download the one matching your engine.

Each zip contains source written for that engine and nothing else. There are no version macros in the code you receive, no ENGINE_MAJOR_VERSION ladders, no branches for engines you are not using. If you open the 5.4 zip you are reading plain 5.4 code, which matters the moment you want to fork it or step through it in a debugger.

• ScarOptions.uplugin, the descriptor, stamped to that engine version.
• Source/, the two modules, runtime and editor.
• Resources/, the plugin icon.

No Config folder, no Content folder, no sample maps, nothing to delete before you ship. The plugin adds no assets to your project and cooks nothing you did not ask for.

Installing

1. 01Unzip into your project Plugins folder, so you end up with YourProject/Plugins/ScarOptions/.
2. 02Regenerate project files.
3. 03Build. The plugin is source-only, so it compiles alongside your game module and there are no prebuilt binaries to mismatch your engine build.

Troubleshooting

Support and version

Version 1.0. Unreal Engine 5.2 to 5.8, with a separate build for each engine version. Blueprint-first and C++ compatible.

Support runs through our Discord at https://discord.gg/cq464nBPRE. You get help from the developer who built the plugin.