Bug Found. Shift layer is wiped on save/reload if the profile is still active when PadForge closes

[brawler14801]

I've encountered what I assume to be a bug when it comes down to saving any layer created on a profile.

Summary

Layers created on a profile appear to be lost after closing and reopening PadForge — but only if that profile is still the active profile at the time of closing. If you switch to a different profile (e.g. the Default profile) before closing, the layer persists correctly.

Versions Tested

• Stable: 4.3.2
• Pre-release: PadForge r3482@387aaa2

Tested on multiple computers, just in case.

Steps to Reproduce

1. Download PadForge to an empty folder (no prior XML).
2. Open PadForge.
3. On the Legacy Driver Cleanup prompt, click Keep (I have ViGEmBus installed and don't want to uninstall it).
4. Skip the tour.
5. Open the Profile menu.
6. Create a new profile, leaving the default name.
7. Load the created profile.
8. Add a controller (tested with Xbox, PS4, and DualSense).
9. Open the Mapping menu.
10. Click + Shift Layer, leaving the default name.
11. Set Activator Input to Gamepad A. Doesn't need to be this Input, just the one used for this example.
12. Save, and confirm the "Settings saved to PadForge.xml" message appears.
13. Go back to the Profile menu.
14. Load the Default profile.
15. Close PadForge.
16. Reopen PadForge.
17. Open the Profile menu and load "New Profile."
18. Check the Mapping menu — "Shift 1" is still there, confirming the layer saved correctly.
19. Now, with "New Profile" still loaded, close PadForge again.
20. Reopen PadForge.
21. Go to the Mapping menu.
22. The shift layer is gone.

Note: switching to the Default profile before closing (steps 13–14) is not required to trigger the bug — it's only included above to show that the layer does save correctly under the right conditions. The bug reproduces even if you skip straight from step 12 to closing PadForge with "New Profile" still loaded.

Expected Behavior

The shift layer should persist regardless of which profile is active when PadForge is closed.

Actual Behavior

The shift layer is wiped if the profile it belongs to is still active/loaded when PadForge closes. Switching away to another profile first avoids the issue.

[hifihedgehog]

@brawler14801 Found, fixed, and shipped today. Issue #376 has the full trace, and the fix is in the next build.

Your repro was exemplary and it reproduced exactly as written, down to the switching-away escape hatch. The mechanism: on startup, PadForge runs a guard that clears mapping data for slots that no longer exist. That guard ran at a moment when the app had restored the DEFAULT profile's slot layout but not yet your active profile's, so with your profile active at close, the slots only it owns looked nonexistent and the guard wiped their mapping sets, shift layers included. The next background save then wrote the wiped state into your stored profile, which is why the layer never came back. Your two observations pinned it: switching away first survives because the restart then judges against the default's own layout, and loading the profile afterward restores its stored copy. The reason the shift layer was the visible victim is that automap quietly rebuilds the mapping rows for a connected controller, and nothing rebuilds a shift layer.

The guard now runs after your active profile's layout is applied, so it judges against the layout that is actually live. Your exact steps are replayed by four automated tests through the real save and load code, the failing one was red before the fix and green after, and the whole flow was also verified end to end with the real app: a file carrying the layer survived a restart with the profile active, a normal close, and a second restart, where the pre-fix build wiped it in one.

One honest note: the bug destroys the stored data, so a layer already lost to it needs re-authoring once. From the fixed build forward it persists no matter which profile is active when you close.

Thanks for the best-written report this tracker has seen, and for the external-control idea last week. You have a knack for finding exactly the seams.

[brawler14801]

Wow. I genuinely cannot be more impressed with the speed and dedication that you tackled these bugs/feature requests. I really want to thank you for everything you're doing. Thank you for implementing the features I requested and for fixing this so quickly. In all three cases from the quick tests I've done they seem to be working perfectly. I cannot stress enough how much I've messed with different remapping programs over the years, even built my own solution for mixing and matching things like Steam + reWASD, reWASD + JoyShockMapper, etc. And I genuinely believe this program will become the golden standard. So once again, thank you for everything you're doing.