mintopia/blur
Watch
1
0
Fork
You've already forked blur
 0
Code Issues Pull requests Projects Releases 1 Packages 1 Wiki Activity Actions

Persist the mod loadout and restore it on launch #12

New issue
Closed
opened 2026-10-17 22:27:00 +00:00 by mintopia · 3 comments
mintopia commented 2026-10-17 22:27:00 +00:00
Owner
Copy link

What to build

The player picks a mod loadout, quits, relaunches, and the same loadout is selected. Use the approach recommended in #11.

Acceptance criteria

  • Loadout chosen in one session is restored on the next launch
  • Covers every loadout slot the game exposes, in single player and multiplayer
  • Missing or invalid stored mods fall back to the game default without a crash
  • Verified in-game on BLUR_ENGINE=recomp
  • No game-derived files committed

Blocked by

## What to build The player picks a mod loadout, quits, relaunches, and the same loadout is selected. Use the approach recommended in #11. ## Acceptance criteria - [ ] Loadout chosen in one session is restored on the next launch - [ ] Covers every loadout slot the game exposes, in single player and multiplayer - [ ] Missing or invalid stored mods fall back to the game default without a crash - [ ] Verified in-game on `BLUR_ENGINE=recomp` - [ ] No game-derived files committed ## Blocked by - #11
mintopia commented 2026-10-18 00:32:54 +00:00
Author
Owner
Copy link

Implemented #11 recommendation: blur-online storage service 10 tasks 1 (uploadFile), 4 (getFileByID), 5 (listFilesByOwner). One file per (owner,name), overwrite on re-upload, stable IDs, 64 KB cap, persisted to -storage (default storage.json; /data/storage.json in image). Missing/invalid file -> 1000 not found / empty list, so game falls back to default profile; no crash path. Unit test covers upload/overwrite/list/get/reload-from-disk. NOT verified in-game on recomp: no unattended access to the MP loadout screen, and bdFileInfo/upload result layouts follow spec §4.12 (inferred). First live run: use BLUR_DWLOG=1, change a loadout, relaunch; fix layouts if the game re-uploads every login. No game-derived files committed.

Implemented #11 recommendation: blur-online storage service 10 tasks 1 (uploadFile), 4 (getFileByID), 5 (listFilesByOwner). One file per (owner,name), overwrite on re-upload, stable IDs, 64 KB cap, persisted to `-storage` (default storage.json; /data/storage.json in image). Missing/invalid file -> 1000 not found / empty list, so game falls back to default profile; no crash path. Unit test covers upload/overwrite/list/get/reload-from-disk. NOT verified in-game on recomp: no unattended access to the MP loadout screen, and bdFileInfo/upload result layouts follow spec §4.12 (inferred). First live run: use BLUR_DWLOG=1, change a loadout, relaunch; fix layouts if the game re-uploads every login. No game-derived files committed.
mintopia removed their assignment 2026-10-18 00:34:42 +00:00
mintopia commented 2026-10-18 10:08:00 +00:00
Author
Owner
Copy link

Reworked as requested: the loadout is now stored locally (no multiplayer account needed). It works in LAN.

Reverted the server storage commits (981101f, 17b647a).

Implementation (aaaed38, 561ae63; ADR 0014):

  • New Host.store(key[, string]). It persists strings in <save dir>/store/<key>, added to ADR 0008.
  • patches/Screens/MpGUIBank.post.lua wraps Multiplayer.SetAbilityLoadout and SetCurrentLoadOutType. After each change it saves the whole set.
  • The game has two sets: profile (inLobby false) and lobby (true, used by LAN and online lobbies). Each set is 4 loadouts x 3 mod slots plus the selected loadout. The sets are stored as loadouts_profile and loadouts_lobby.
  • The MpLobby and MpModShop post patches restore before the screen reads them. The lobby then sends the restored loadout to peers (NetRace.ChangeLocalPlayerLoadout).
  • Fallback: a slot is only applied if its type exists in that slot's ability pack, the loadout is usable, and the mod is unlocked (profile set or online). Otherwise the game default stays. Missing or garbage files change nothing.
  • Single player and split-screen have no selectable loadout. Their scripts only show fixed boss mods, so multiplayer is the only place it applies.

Verified on recomp with the same save dir across launches:

  • Run 1: LAN host. Edited loadout 1 slot 1 to Battering Ram and selected Loadout 3.
  • Run 2: after relaunch, the lobby shows "Loadout 3". Log: cur=2 sets=7,13,20;7,13,20;6,14,20;7,13,19, and GetCurrentLoadout type=2.
  • A corrupt store file: defaults kept, no crash.
  • ctest 22/22, including the new loadout_patch test (fake Multiplayer API).

Not done / not verified

  • Loadout names are not saved: SetNameOfLoadOut reads the keyboard result natively.
  • The online profile set path is not verified live (no reachable online profile). It uses the same code as LAN.
  • The test runs on the host's lua (5.4+), not 5.1. The patch uses only 5.1 constructs.
  • No game-derived files committed.
Reworked as requested: the loadout is now stored **locally** (no multiplayer account needed). It works in LAN. **Reverted** the server storage commits (981101f, 17b647a). **Implementation** (aaaed38, 561ae63; ADR 0014): - New `Host.store(key[, string])`. It persists strings in `<save dir>/store/<key>`, added to ADR 0008. - `patches/Screens/MpGUIBank.post.lua` wraps `Multiplayer.SetAbilityLoadout` and `SetCurrentLoadOutType`. After each change it saves the whole set. - The game has two sets: profile (`inLobby` false) and lobby (`true`, used by LAN and online lobbies). Each set is 4 loadouts x 3 mod slots plus the selected loadout. The sets are stored as `loadouts_profile` and `loadouts_lobby`. - The `MpLobby` and `MpModShop` post patches restore before the screen reads them. The lobby then sends the restored loadout to peers (`NetRace.ChangeLocalPlayerLoadout`). - Fallback: a slot is only applied if its type exists in that slot's ability pack, the loadout is usable, and the mod is unlocked (profile set or online). Otherwise the game default stays. Missing or garbage files change nothing. - Single player and split-screen have no selectable loadout. Their scripts only show fixed boss mods, so multiplayer is the only place it applies. **Verified on recomp** with the same save dir across launches: - Run 1: LAN host. Edited loadout 1 slot 1 to Battering Ram and selected Loadout 3. - Run 2: after relaunch, the lobby shows "Loadout 3". Log: `cur=2 sets=7,13,20;7,13,20;6,14,20;7,13,19`, and `GetCurrentLoadout` type=2. - A corrupt store file: defaults kept, no crash. - ctest 22/22, including the new `loadout_patch` test (fake Multiplayer API). **Not done / not verified** - Loadout names are not saved: `SetNameOfLoadOut` reads the keyboard result natively. - The online profile set path is not verified live (no reachable online profile). It uses the same code as LAN. - The test runs on the host's `lua` (5.4+), not 5.1. The patch uses only 5.1 constructs. - No game-derived files committed.
mintopia commented 2026-10-18 10:08:39 +00:00
Author
Owner
Copy link

Completed and merged by Harmonic (task 11).

Completed and merged by Harmonic (task 11).
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
develop
main
v0.1.0
Labels
Clear labels   
needs-info
Waiting on reporter for more information

  
needs-triage
Maintainer needs to evaluate this issue

  
ready-for-agent
Fully specified, ready for an AFK agent

  
ready-for-human
Requires human implementation

  
wontfix
Will not be actioned

No labels
needs-info
needs-triage
ready-for-agent
ready-for-human
wontfix
Milestone
Clear milestone
No items
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
mintopia
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Depends on
#11 Find where the mod loadout lives and why it is lost between launches
mintopia/blur
Reference
mintopia/blur#12
No description provided.