Reset and dirty state¶

At a glance

Get Game User Settings returns: the engine's global UGameUserSettings object for this process · Scope: local-machine settings, not one object per Local Player or World · Pending values: setters and loads change the object's requested state · Apply Settings: applies the requested state and saves it · Ordinary failure output: none—Load, Apply, Save, and Reset return no success Boolean · Can the reference be None? not in an ordinarily initialized game; guard the boundary in unusual early-startup, tool, or server code · Official pages: Get Game User Settings · UGameUserSettings

The one-minute version¶

Get Game User Settings gives you the engine-owned settings object for the local machine/process. It is global, not attached to the current map, PlayerController, or split-screen player.
A setter such as Set VSync Enabled normally changes a requested/pending value on that object. It does not by itself prove the live renderer or window changed.
Load Settings reads persisted GameUserSettings config into the object. Loading is not the same as applying every value to the running system.
Apply Settings applies resolution and non-resolution settings, then saves the settings to persistent storage. Do not automatically follow it with a second Save Settings call.
Save Settings persists the object's values without being the general “make these values live” operation.
Reset to Current Settings copies the currently active system state back into the requested settings. It is not factory defaults, not Load, and not Revert Video Mode.
Is Dirty asks whether supported requested values differ from current live state. It does not mean “the options draft differs from disk.” Keep UI dirty state in your own draft/snapshot model.
Load, Apply, Save, and Reset have execution outputs but no success/failure result. Platform restrictions, command-line overrides, or storage failure therefore need readback, project-owned reporting, or a custom service.
The stock class owns engine/device settings. It does not automatically apply your Sound Mix, Enhanced Input mapping, subtitle, or gameplay preference.

What `Get Game User Settings` actually returns¶

Unreal's Engine object owns one global UGameUserSettings instance. The Blueprint node returns that same live UObject reference:

engine process
└─ global UEngine
   └─ one UGameUserSettings instance
      ├─ requested resolution / window mode
      ├─ requested VSync / frame limit / dynamic resolution
      ├─ requested scalability quality values
      └─ any config fields added by the configured custom class

The declared return type is Game User Settings; the runtime object can be a configured subclass. Cast to that subclass only when the project has installed one as the engine's Game User Settings Class.

In normal Blueprint gameplay, engine startup has already created this object. If an unusual tool, commandlet, very-early startup path, or stripped server context cannot provide it, the return can be invalid; using that invalid target then produces the ordinary Accessed None behavior. A coordinator can validate the reference once and treat absence as a visible initialization failure rather than scattering Is Valid after every getter.

Global does not mean replicated¶

“Global” means one per engine process. It does not mean one network-wide:

each packaged client process has its own local object and config;
a listen server has its own local display settings, separate from clients;
split-screen Local Players share the same machine display settings object;
multiple play-in-editor (PIE) Worlds in one process do not gain independent per-World GameUserSettings objects; and
a dedicated server has no reason to make client display preferences into authoritative state.

Never send resolution, VSync, local quality, or category-volume preferences to the server merely because a settings widget lives in a multiplayer game.

Requested, live, and persisted are different states¶

The object sits between three states that can temporarily disagree:

State	Example	How to inspect it
Requested / pending	`Set VSync Enabled(true)` has changed the object	The ordinary `Get…` settings functions
Live / current system	the renderer still has VSync off until apply	Dirty checks and system-specific readback
Persisted	the config still says off until save	Load into a controlled snapshot or use project-owned persistence verification

Do not use the widget as a fourth hidden owner. The options screen should edit a draft, then copy validated values into GameUserSettings at its Apply boundary. See Options/settings screen architecture.

pseudocode — options coordinator, not engine source

OpenOptions
-> Settings = GetGameUserSettings()
-> require IsValid(Settings)
-> Draft = ReadRequestedValues(Settings)
-> OpenSnapshot = Draft

ApplyOptions(Draft)
-> validate Draft
-> call the relevant Set... functions on Settings
-> Settings.ApplySettings(CheckCommandLineOverrides = true)
-> read back requested/live state
-> only mark the screen clean when project policy accepts the result

Display mode needs an explicit Confirm/Revert preview path before it is treated as accepted; see Game User Settings: resolution, fullscreen, VSync, frame limit, scalability, and benchmark.

What each lifecycle function does¶

Function	Changes requested object values	Changes the live system	Writes persistent config	Success result
Get Game User Settings	No	No	No	UObject reference
Load Settings	Yes—reads stored values into the object	Not the general apply step	Reads	None
Apply Settings	Uses current requested values	Yes—resolution and non-resolution paths	Yes	None
Save Settings	No	No general apply	Yes	None
Reset to Current Settings	Yes—copies current live state into requested values	No new change needed	No	None
Set to Defaults	Yes—puts class defaults into requested state	No	No	None

“None” in the last column means the node has only an execution output. It does not return a Boolean, failure branch, error object, or asynchronous completion.

Load Settings¶

Load Settings(Force Reload) loads persisted GameUserSettings configuration into the existing object. It does not create a new object and it does not return the loaded data as a separate value.

With Force Reload off, the normal config cache can satisfy the load.
With Force Reload on, Unreal refreshes the config data before loading the object. Use this only when an external/cloud/config workflow may have changed the backing file; it is not a “load more correctly” checkbox.

Do not call Load every time a settings widget constructs. The engine performs its startup settings work before ordinary gameplay, including early resolution preload. Re-loading behind an open draft can erase user edits and create a second writer. Let one startup/coordinator path decide when a real reload is needed, then normalize the result before populating controls.

Load has no “file missing” or “parse failed” output. First-run defaults, version validation, platform config layers, and any custom fields determine the result. If your product needs a recoverable error message rather than engine config fallback, own that requirement in a project persistence layer.

Apply Settings¶

Apply Settings(Check for Command Line Overrides) does three important jobs:

applies requested resolution/window settings;
applies non-resolution settings such as scalability, VSync, frame limiting, and other supported fields; and
saves the settings to persistent storage.

The command-line flag decides whether explicit launch-time resolution/window overrides are allowed to win during the resolution request. The safe default for a normal shipped game is true: a user or support technician may have launched in a recovery mode deliberately. Turning the check off does not make an unsupported platform mode valid.

Apply is synchronous from Blueprint's point of view and returns no success status. It is also not an atomic transaction across GameUserSettings plus your audio, input, SaveGame, or cloud services. The project coordinator still owns ordering and partial-failure policy.

Do not double-save¶

The stock contract explicitly includes saving as part of Apply Settings:

wrong default pattern
Set values -> Apply Settings -> Save Settings

ordinary pattern
Set values -> Apply Settings

Call Save Settings separately when you intentionally changed requested or confirmation metadata without using the full Apply path—not as cargo-cult insurance after every Apply.

Save Settings¶

Save Settings writes the object's config-backed state to its persistent GameUserSettings storage. It does not mean all requested values were applied to the running renderer first.

This distinction produces a real trap:

Set Screen Resolution(NewResolution)
-> Save Settings
-> config may contain the request
-> current window has not necessarily changed

Use the correct Apply path before claiming the running system changed. For a video confirmation flow, preview resolution separately, then confirm and save only the accepted mode.

Save returns no Boolean. A plain Blueprint screen cannot prove that a disk or platform write succeeded from this node alone. If persistence success is a product requirement, wrap it in a project service that can verify/report the storage operation rather than showing “Saved” immediately.

Reset to Current Settings¶

Reset to Current Settings makes the settings object's requested values match the currently active system settings. That usually clears runtime dirty comparisons because requested and live now agree.

It does not:

restore factory/project defaults;
reload the last saved file;
revert only resolution/window mode to a last-confirmed pair;
apply some older values; or
save the new requested snapshot.

Use it when the live system is the intended truth—for example, after an external override and before rebuilding a draft. For a Defaults button, put the project's named defaults into the UI draft and wait for Apply. For a rejected video preview, use Revert Video Mode plus the resolution-apply path.

What `Is Dirty` actually means¶

Is Dirty compares the settings object's supported requested state with the current live system. Public focused checks include:

Is Screen Resolution Dirty;
Is Fullscreen Mode Dirty;
Is VSync Dirty; and
Is Dynamic Resolution Dirty.

The broad check also accounts for the class's applicable user settings. A true result means an Apply may be needed. It does not answer any of these:

Did the options draft change since the screen opened?
Does the object differ from the last saved config file?
Did a previous Save succeed?
Did another settings owner—audio, input, SaveGame—change?
Does the server agree with a local preference?

Consequences that surprise beginners:

Save Settings without applying can leave Is Dirty true: disk may now match the request while the live system does not.
Reset to Current Settings can make Is Dirty false even though the persisted file still contains older values.
command-line/platform overrides can keep requested and live state different after an attempted Apply.

Keep screen dirty state as Draft != OpenSnapshot (or per-owner dirty groups), not as a direct alias for UGameUserSettings::IsDirty.

Custom Game User Settings classes¶

The Engine exposes a configurable Game User Settings Class. A typical C++ subclass adds Config properties for project-specific machine settings, overrides defaults/application where necessary, and calls the parent behavior. The Engine creates that configured class at startup; then Get Game User Settings returns it and project code can cast to the subclass.

Do not construct a second settings UObject and expect the global Get node to find it. That creates two owners and leaves engine startup, resolution preload, and config saving attached to the original instance.

A custom config field is only storage until code applies it. Adding MasterVolume does not automatically change a Sound Class/Mix; adding SubtitleMode does not update every widget. Keep those runtime effects behind the same coordinator that owns Apply/Cancel.

Config, editor, packaged, and platform boundaries¶

UGameUserSettings uses Unreal's GameUserSettings config domain. In desktop development, generated values normally appear in a platform-specific location under the project's Saved/Config; a packaged build uses a user-writable platform location rather than the read-only packaged Content directory. Exact paths and available settings vary by platform.

Verify the real product path, not only PIE:

PIE shares editor/process constraints and does not prove resolution changes;
Standalone is closer but still uses a development environment;
packaged builds exercise the real writable config location and platform window/display rules;
consoles/mobile may force or ignore desktop-style window modes; and
command-line, device-profile, frame-pacing, or platform policy can override a requested value.

Read back what the running system accepted and disable unsupported controls with an explanation. A setter existing in Blueprint does not promise that every target platform honors it.

When it fails (and what failure does)¶

Failure	What Blueprint sees	Correct response
Global settings reference unavailable	invalid UObject; later target calls would be `Accessed None`	Validate once, fail the settings screen visibly, and investigate startup/context
Stored config missing or stale	no failure pin from Load; defaults/validation may populate values	Normalize and version custom state; do not overwrite recoverable data silently
Command-line/platform policy wins	requested and live values can differ; dirty/readback exposes mismatch	Keep accepted live state, explain unsupported/overridden choice
Save cannot persist	no Boolean or completion from Save/Apply	Use a project-owned verifiable storage/result path when the product must report success
Wrong custom class configured	cast from Get fails	Configure the Engine class, restart, and keep one global owner
Widget uses GameUserSettings for per-player data	split-screen users overwrite one machine-global object	Put per-local-player input/profile choices in their actual owner

The stock calls do not throw gameplay exceptions, branch to failure, or roll back a partially applied cross-service options transaction.

What these nodes do not do¶

They do not maintain your options widget's draft or Cancel snapshot.
They do not provide one object per Local Player, World, map, or network user.
They do not apply project audio/input/accessibility systems automatically.
They do not report ordinary config write success.
They do not confirm a potentially unsafe display mode for the user.
They do not turn local preferences into replicated game rules.

Lookalikes — which one do I want?¶

Node / owner	Use it for	It does not mean
Load Settings	Refresh requested values from persistent GameUserSettings config	Apply the whole object to the live system
Apply Settings	Make requested engine settings live and save them	Atomically apply every project settings service
Save Settings	Persist current GameUserSettings object values	Make pending renderer/window values live
Reset to Current Settings	Make requested values match the live system	Factory defaults or last saved values
Set to Defaults	Put class defaults into requested state	Apply/save or a project-defined Defaults-button policy
Revert Video Mode	Restore last-confirmed resolution/window request	Reset all quality/audio/input settings
SaveGame	Persist project/profile/playthrough preferences with explicit slot results	Automatic engine graphics application
Enhanced Input User Settings	Per-Local-Player mappable input profiles	Machine-global display settings
GameInstance / subsystem	Coordinate runtime settings across map travel	Disk persistence

Going deeper¶

Options/settings screen architecture — draft, applied, persisted, Apply/Cancel, and per-owner results.
Slider / Check Box / Combo Box String — the presentation events that should edit the draft rather than this object directly.
Game User Settings: resolution, fullscreen, VSync, frame limit, scalability, and benchmark — safe video preview/rollback, resolution scale, quality groups, and Auto benchmark.
Save Game: Create / Save / Load Game to Slot — explicit project/profile persistence and failure behavior.
Game Instance — runtime coordination that survives map travel but is not storage.
Engine source (requires engine access; we do not reproduce it): UGameUserSettings::GetGameUserSettings, LoadSettings, ApplySettings, SaveSettings, ResetToCurrentSettings, IsDirty, PreloadResolutionSettings, and ValidateSettings in Engine/Source/Runtime/Engine/Private/GameUserSettings.cpp, with declarations in Engine/Source/Runtime/Engine/Classes/GameFramework/GameUserSettings.h; and UEngine::GetGameUserSettings, UEngine::GameUserSettings, and UEngine::GameUserSettingsClassName in Engine/Source/Runtime/Engine/Classes/Engine/Engine.h and Engine/Source/Runtime/Engine/Private/UnrealEngine.cpp.