Optimizing overwrites the user's own GameLoop settings, with no warning

[umarabdullah23]

Reported by UnknownX4T (the same person who posts as 4t_talha, see #12) in a direct message to the owner on 2026-08-14 (02:10).

Verbatim:

"at first i was playing self optimized like only setings but it lagged during intense matches — so i downloaded this optimizer but it reverted them and no better performance"

He had hand-tuned GameLoop himself, installed the optimizer, and found his own settings replaced. He was never told that would happen. This is a different complaint from "it didn't help" — it is about the tool silently discarding a user's own configuration.

Confirmed: we do overwrite them, and we never say so

Two separate paths change GameLoop's own settings.

1. "Apply all recommended" on the GameLoop Settings page rewrites 13 settings in one click — VM RAM, VM CPU cores, screen rendering mode, FXAA, VSync, rendering cache, global shader cache, rendering optimization, discrete-GPU priority, ADB debugging, root authority, VM resolution and VM DPI. Each is written unconditionally: the current value is never read, never compared, and a setting the user deliberately chose is never skipped.

The button fires immediately. There is no confirmation and no "this will replace your current settings" wording anywhere on that page — the card only lists what will be written. For contrast, the uninstall flow in the same app requires a preview, two opt-in checkboxes, typing a word, and a confirm. None of that care was extended here.

2. A plain one-click / Run All Safe also changes GameLoop settings, which is much less obvious. The GameLoop group is part of the standard batch, so a normal optimize resets VM RAM to 8 GB, VM CPU cores (two tweaks write this in sequence, 6 then 8), and FXAA to Off. On installs where we cannot detect which renderer GameLoop is using, the renderer-specific tweaks also fire, because that check deliberately fails open — so the render mode can change too.

So a user who never opened the GameLoop Settings page can still have his GameLoop configuration rewritten by the main button.

A backup IS taken — but the restore story does not hold up

The good news first: every one of those writes snapshots the previous value to disk before it changes it, so this is not destructive by design. The problem is that the snapshot is mostly unreachable, and in two cases actively wrong.

• Only 3 of the 13 settings have a working restore (VM RAM, VM CPU, FXAA). The other ten are backed up and then never read by anything — no button, no code path, nothing. The backup file exists and cannot be used.
• "Restore all GameLoop settings" does not restore all GameLoop settings. The button is always offered and its own description promises a full rollback, but it can only reach those same three. VSync, both caches, rendering optimization, discrete-GPU priority, render mode, ADB debugging, root authority, resolution and DPI are never rolled back.
• Two per-row restore buttons restore the wrong setting. The two render-mode rows each show a restore arrow, and each one restores a different setting from the one that row changed. Clicking it appears to work and does not undo what you just did.
• Re-running destroys the original. The backup is overwritten on every apply with no "only if absent" check, so a second Apply-All snapshots the already-optimized value as "the original" and restore becomes a no-op. This exact failure mode is already documented and worked around elsewhere in the codebase for a different setting — the workaround was never applied here.
• Worse, one Run All Safe can do that to itself. Two tweaks in the same batch both write the VM CPU core count, and they run in an order that writes one value first and the other second. The user's real original is captured, then immediately replaced by our own intermediate value. Restoring afterwards gives the user our number, not his.

Net effect for this user: even if he had found the restore, most of what we changed could not be put back, and re-running would have erased the record of what he had.

Honest status

Confirmed ours. The overwrite is real, the silence about it is real, and the restore gaps are verified. What is not established is whether the overwrite is why his performance got worse — that is #12's question, and his own settings may well have been better tuned for his machine than our fixed table.

Suggested direction

1. Say it before doing it. Any path that rewrites GameLoop's own settings should state plainly that it will replace the user's current values, and show what is about to change. This is the minimum fix and it is cheap.
2. Do not touch a setting the user already chose without asking — read the current value first and, where it differs from ours, treat that as a decision rather than a default.
3. Make the restore true. Either every changed setting gets a working restore, or the "Restore all" copy stops promising one. A restore button that silently covers 3 of 13 is worse than no button.
4. Never overwrite an existing backup with an already-optimized value, and make sure two tweaks in one batch cannot write the same setting.
5. Consider whether the fixed recommended values should be clamped to the machine at all (8 GB of VM RAM on an 8 GB PC is the whole machine).

[umarabdullah23]

Restore is now real: 15 of 15 GameLoop settings, verified by reading the value back

Fixed the restore side of this ticket. The overwrite itself is unchanged; what changed is that undoing it now works.

Before → after

	before	after
Settings-page rows with a working undo	3 of 15	15 of 15, in both the dev app and the shipped client
"Restore all GameLoop settings"	always offered, reached 3 of 15	offered only when we hold a saved original, and its confirm + result state the real number ("Restored 13 of 15; 2 had no saved original")
The two wrong per-row restores	ForceDirectX row restored EnableVulkan; Config.ini renderer row restored the registry RendererEngine — both reported success	each row restores exactly what it writes
Backups	overwritten on every apply, so a second run recorded our value as "the original"	first-write-wins — the first capture is the user's own setting and is never replaced
Verification	none	every target is read back after the write; a restore that did not take is reported as FAILED, not success

Why the wrong mappings can't come back. They existed because the undo side was a separate hand-kept list that nothing forced to agree with the apply side. That list is deleted. One shared-engine table (GAMELOOP_SETTING_TARGETS) now maps each row key to the registry values / Config.ini keys that row's own setter writes, and a test asserts the two are 1:1 and that each restore target literally appears in the method that writes it.

Honesty rule. A row with no saved original is refused — "nothing to restore — this app never recorded an original value for it". Nothing writes a hardcoded default and calls it the user's value.

The duplicate write (point 4). Scanned the whole catalog rather than just the reported pair, by grouping batchable specs by the restore action they share. Four collisions:

• tencent_set_cpu_6 + tencent_set_cpu_8 — same Safe batch. _cpu_6 is now batchable=False, matching how tencent_set_fxaa_balanced already sits next to tencent_set_fxaa_off. It stays available as a per-tweak toggle; a single Run All Safe can no longer apply "VM CPU 6" and "VM CPU 8" in one go.
• amd_gaming_power_profile_zen3 + amd_gaming_power_profile — same Safe batch on any Zen 3 box, and the zen3 one is a literal duplicate (identical call, different label). Also batchable=False; provably cannot change the final state.
• AppMarket priority and the Ultimate power plan pair across the Safe/Aggressive batches — outcome is coherent, only the backup was broken, so both stay and the backup is fixed. The power-plan one was the nastiest: applying Ultimate twice recorded Ultimate as "the plan you had before", making "Restore previous power plan" a permanent no-op.

A test now enforces the general rule: no two batchable settings in the same mode may share a restore action.

Also fixed along the way: choosing "Auto" for the render mode deletes the registry value and took no backup at all, so it was permanently unundoable; the hardware-decoding restore wrote the whole backed-up Config.ini over the live one, silently reverting every other Config.ini setting made since; and "Restore everything" skipped GameLoop settings entirely (it walks spec.restore_action, and this page writes through core methods, not ActionSpecs).

On point 1 ("say it before doing it"). The GameLoop page now states the replacement before you press — "This replaces your current GameLoop settings — we save the originals first, so Restore all can put them back" — plus a live line showing how much is recoverable. I did not add a confirmation to the plain one-click, deliberately: that button is intentionally frictionless, and the real failure here was that the undo didn't work. The recommendation instead is a post-run line ("we also changed 3 of your GameLoop settings — restore them") which informs without blocking; that needs an owner call and is written up, not built.

Points 2 (skip a setting the user already chose) and 5 (clamp VM RAM to the host) are not done — both are separate product decisions, both noted in the write-up.

Verified by real execution, not inspection: 18 headless regression cases run the full apply → re-apply → restore → read-back cycle against an in-memory registry and a temp Config.ini (developer_app/tests/test_gameloop_restore.py), plus the renderer driven in a real browser against the mock. This is a Linux dev box — nothing is Windows-verified. The list of what still needs a real Windows + GameLoop box (real registry value kinds, a real UTF-16 Config.ini, and whether GameLoop itself picks the restored values up) is in the write-up: docs/issues/issue-32-restore-fixes.md.

[umarabdullah23]

This is now genuinely fixed for the vast majority of cases: all 15 GameLoop settings on the Settings page have working, read-back-verified restore (previously only 3 of 15 actually restored anything, and 2 rows were silently restoring the wrong setting). We also fixed backups being silently overwritten by a second run, which was destroying the very backup "Restore" needed. This is a big change, and while it's covered by 18 automated tests against a simulated registry, it hasn't yet been run against a real Windows machine with real GameLoop installed — that verification (real registry types, real Config.ini format, confirming GameLoop itself picks up a restored value) is the remaining step. Keeping this open until that's done; will comment again once verified.