KNULLI settings not saving: choose the right configuration layer

Changed settings after an update: defaults or persistence?

A preference absent after a major update is not the same observation as a newly selected preference reverting on relaunch. The major-update guide explains why the previous system folder should remain outside the new working defaults.

Example: the new frontend starts with a different display preference. Select the desired option and relaunch the same game. If it remains selected, that is a successful new configuration check. If it reverts, investigate ownership and scope. Restoring the old system folder would skip that distinction and could reintroduce obsolete settings.

Keep a short record of the choice you recreated and the result after normal relaunch. A configuration backup is useful for reading previous preferences; it is not proof that every old key belongs in the updated installation.

Choose the smallest useful scope

Auto inherits from the layer above. A specific game choice can therefore differ from a broader preference. Not every emulator supports every exposed setting; a menu option is not a compatibility guarantee.

A repeatable persistence check

1. Record device, KNULLI version, game file, selected emulator and the option's original value at each relevant layer.
2. Change one option in the game's EmulationStation configuration.
3. Launch the same game and inspect a recognizable scene.
4. Exit normally and relaunch that exact file. Check whether the setting remains effective.
5. If you want a broader preference, record or remove the narrow exception deliberately before testing system scope.

This is a proposed diagnostic procedure, not a measured result on an SP, Plus or Brick. Use a backed-up game session and keep cartridge-save verification separate from visual settings.

Still different after relaunch?

Check that you selected the same game entry and emulator, that the option is supported there, and that a more specific value or old customization is not involved. Keep notes instead of changing several scopes together.

The KNULLI game-settings documentation describes advanced overrides, remaps and manual configuration as exceptions to the usual generated workflow. Some features conflict with overrides. Preserve existing customizations before investigating them; do not delete every configuration file.

Changing an emulator is a separate test

KNULLI allows emulator selection at system or game scope. Available settings may differ after a switch. Keep the original selection and a cartridge-save backup, then verify Continue and progress rather than assuming an old state transfers.

For shortcut persistence, use the KNULLI hotkey guide. For absent library entries, use the games-not-showing guide; changing display options will not establish which storage is active.

Reopening a game is not the same as retaining a setting

Record these observations separately: which game reopens after boot, whether its previous scene returns, and whether your selected display or control preference persists. A successful relaunch answers only the first question.

Use the Quick Resume guide for Auto Save/Load support and a full shutdown comparison. Keep the normal cartridge-save Continue check alongside that test. If a resumed game blocks boot, preserve configuration and progress before following the developer's narrow recovery procedure.

After recovering menu access, test one setting in one game scope before restoring more customizations. Retain the original values so you can identify which change affected the behavior.

Worked example: one game ignores a GBA-wide preference

Inspect the exceptional game's Advanced Game Options. A specific value there can explain why changing the broader system preference did not change that game. Auto is inheritance, so checking it means asking which broader value the game will receive, not assuming it is a universal factory reset.

1. Write down value B before changing it.
2. If the game should share the system preference, set that option to Auto at game scope.
3. Relaunch the same entry and compare a familiar scene.
4. If its appearance now follows the system preference, the exception was relevant. If not, verify emulator support and existing customizations.

Changing one layer produces an interpretable result. Changing global, system and game values together may get the desired picture while hiding which setting actually mattered.

Design a persistence test with a visible result

Choose an option whose effect you can recognize in the installed emulator. Record the original and intended result in plain terms, such as a changed border or screen arrangement. Avoid testing several shaders, aspect choices and remaps simultaneously.

Use the same game entry, emulator and scene for the first launch and the relaunch. A different emulator can expose a different set of supported settings, and a different scene can make a subtle display change hard to compare. Keep both conditions in your notes.

A useful test has three outcomes: the preference appears during play, it survives normal exit/relaunch, and unrelated games keep the behavior you intended. The third outcome matters when choosing game scope: fixing one title should not silently become a new preference for the whole library.

Return one experiment to its previous value

Use your record to reverse the exact layer you changed. If you entered a game-specific value, restore the recorded value there rather than resetting every emulator. If the original was Auto, record which system preference the game should inherit afterward.

Then repeat the same launch comparison. If an old override or remap is still involved, identify its intended scope before removing it. Treat advanced customization as a separate investigation, with a copy of the original configuration. A working ordinary setting is not evidence that every existing manual override is harmless.

For controls, distinguish “the button does something” from “the intended action remains after relaunch.” Use the hotkey guide for that second workflow rather than repatching a game.

Choose the setting owner before trying another Save command

Use the symptom to choose a configuration path. A display preference, a Pokémon button assignment and a Function shortcut may all look like “settings”, but fixing one does not automatically fix the others.

The developer's game-settings guide places emulator selection at system or game scope, not global scope. Standalone emulators lack RetroArch integration and can expose different features. Check the selected runtime before deciding that a missing option is a persistence failure.

For button assignments, follow the complete active-remap procedure. That path is an explicit exception to ordinary regenerated emulator configuration; repeatedly saving a general runtime configuration is not the same task.

Two configuration records to compare in one stubborn game

Record the display option at game and system scope. Then inspect the active control remap in that same title. Do not change the already-working display preference just because the button is wrong. Conversely, changing a control remap does not test whether a display option is being inherited.

Choose an acceptance check before editing: “the menu cancels with the intended physical button, while the picture remains unchanged.” Repeat that exact action after a normal relaunch. If the result changes, record the remap name alongside the observed button behavior; that connects the fix to a specific configuration rather than to a vague reset.

When asking for help, include the game entry, selected emulator, setting scope and active remap name. You can omit private paths from a public support message. A screenshot of the option by itself leaves out whether the same runtime and file were used during play.

This owner-selection expansion uses KNULLI documentation checked 7 Oct 2026. It does not refresh unrelated hardware evidence or establish an optimal configuration.

Did the file disappear, or did the next launch change it?

Inspect the path as well as the setting. The network-transfer reference warns that changes outside /userdata do not persist across reboot. SCP/SFTP exposes more of the filesystem than SMB, so seeing an editable file does not establish that it is the persistent owner of a preference.

Example: an SCP client lets you alter a file outside userdata, but reboot returns the previous value. Repeating Save Current Configuration in the emulator does not test that filesystem boundary. Record the exact path and timing first. If the file survives but the game ignores it, investigate launch ownership instead.

The developer points advanced persistent system changes to its patches/overlays documentation. That is a separate customization task, not the starting fix for Pokémon controls. For ordinary options, use this page’s frontend scope procedure; for controls, use the documented remap workflow. This filesystem distinction was checked 8 Oct 2026 and does not establish that a manually copied configuration is supported.

Software scope and sources

TrimUI Brick · RG35XX SP · RG35XX Plus. Follow the installed KNULLI version's menus. This guide does not cover stock firmware or every standalone emulator's private options.

Primary KNULLI documentation checked 6 Oct 2026. Device performance, best settings and a completed physical-unit persistence test have not been verified by Pocket Deal Radar.

Record the setting scope and the relaunch result

Name the setting and where you changed it: global, system or per-game. Write down its previous value, the single new value and the exact game entry you launched. Record the visible result during that launch, then the value shown after returning to the same settings screen. Keep those observations separate so “the setting is listed” does not become “the game used it”.

For example: a global value remains selected, but one game keeps behaving differently. Check the inheritance and per-game scope described above before treating the result as a failed save. If the value itself reverts, record when you first notice it: on leaving the menu, after relaunching the game or after rebooting. That timing helps identify the next comparison without changing several scopes at once.

Use the local GBA session notebook to download a plain-text record of your attempt. Blank fields stay unrecorded; the notebook does not diagnose your setup.