Recommended GameLoop settings contradict the app's own advice (rendering cache)

[umarabdullah23]

Reported by hesham08824 in #🤖│ai-help on 2026-07-22 (08:22 UTC).

Verbatim:

"Why in recommended settings the tool disable rendering cache and force global rendering cache ?"

The same question was asked again, independently, about two and a half hours later in the same channel (10:51 UTC) — "Why in recommended settings the tool disable rendering cache and also disabling "force global rendering cache" ?". Two people reading the same screen and both stopping to ask why is a signal about the screen, not about them.

What we know — the app genuinely contradicts itself

The recommended GameLoop settings the app applies and checks against set both of these to Off:

• Rendering Cache → Off
• Global / Enforce Global Rendering Cache → Off

But the app's own generated advice report tells the user the opposite, in writing:

"Render Cache: keep enabled"
"Enforce Global Render Cache: keep enabled"

So one surface applies Off and another surface recommends On. Whichever value is correct, one of the two is wrong, and a user who reads both has no way to tell which.

For completeness: the AI help assistant also repeatedly tells users "Rendering cache — On", which agrees with the advice text and disagrees with the recommended settings the app actually applies.

What is not known

• Which value is actually right. Neither surface cites a measurement. There is no A/B result in the repo showing the cache off is faster in GameLoop, and none showing it is slower.
• Whether the right answer is hardware-dependent (the advice text is generated per machine, the recommended settings are a fixed table — that may be the origin of the split).

Honest status

Confirmed ours as a contradiction: the two strings are in the product and they disagree. Unknown which one is correct — that needs a measurement, not an opinion.

Suggested direction

1. Decide the value from an actual test, not from either existing string.
2. Make both surfaces read from one source, so they cannot drift apart again.
3. Give the setting a one-line "why" in the UI. Both users asked why, not what — the value without a reason is what made them stop.

[umarabdullah23]

Confirmed, and it was worse than it looked: this value was hand-typed in eight separate places across the app, split six "Off" and two "On", with nothing keeping them in sync. One of the "On" surfaces was a function literally named "recommended profile values". The generated advice report could even print the live value and the opposite advice in the same document.

On which value is actually right, the honest answer is that nobody has measured it. There is no A/B test, no frametime capture and no before/after FPS for this setting anywhere in our research — and our own live audit from July had already filed it under "needs A/B, do not ship blind". So we have deliberately not picked a winner: choosing one now would only make the app consistently wrong instead of visibly contradictory.

What we did instead: there is now a single source of truth in the engine that every surface reads from, and it is explicitly flagged as unverified. The advice report no longer says "keep enabled" — it states the value the app applies, says plainly that it is not yet measured, and gives the rule that actually helps: if you get stutter the first time you enter a match, turn Rendering Cache back On, because that is the exact symptom it controls. The app's behaviour is unchanged; only the contradiction is gone. Our Discord help bot was also telling people "On" and has been corrected.

Both reporters asked why, not what — that was the real gap, and the "why" now travels with the value instead of being separate from it.

Leaving this open to track the measurement itself, which is the part that is still genuinely unknown.

[umarabdullah23]

Note from the #32 restore work — these two settings are now undoable, but the recommendation is still unmeasured

While fixing the restore defects in #32 I confirmed the source of both values from the other direction, so recording it here rather than re-arguing this ticket.

Both "Off" recommendations resolve to a single constant, GAMELOOP_RENDER_CACHE_RECOMMENDATION in developer_app/optimizer/catalog.py, which is explicitly marked "verified": False with an empty "source_ref". It is genuinely the single source of truth — the GameLoop Settings page reads its recommended_label from it, so the page, the engine's verify list and the advice report can no longer disagree — but what it is the single source of truth for is still an unmeasured recommendation. Nothing in the repo A/Bs it.

That matters more than a copy inconsistency, because a plain one-click writes it. Two rendering-cache settings a user may have deliberately chosen are set to Off on a recommendation the constant itself admits is unverified.

What changed in #32 that bounds the harm: the shader_cache and local_shader_cache rows previously wrote a backup that no code path ever read — there was literally no way to undo them. Both now have a working per-row restore and are covered by "Restore all GameLoop settings" and by the global "Restore everything", each verified by reading the value back. So a user who disagrees with the recommendation can now reverse it.

That does not settle which value is right. This ticket's actual ask — measure it, then set "verified": True and fill in source_ref, or change the recommended value — is untouched and still open.

[umarabdullah23]

Found and fixed a real inconsistency: our own recommended-settings advice for the render cache was hand-typed in 8 different places in the code, and it disagreed with itself — 6 said Off, 2 said On. That's now a single source of truth so the app can't contradict itself again. What's still open: nobody has actually run the A/B test to determine which value (On or Off) is genuinely better for FPS — the current single value is our best guess, not a measured result. Leaving this open to track that measurement.