ILoadoutSave interface
Save the setup the player is WEARING into one of their saved in-game loadouts — the game’s own “Save” (its Role Plan AsyncSaveRolePlan), aimed at a loadout other than the worn one. Split from ILoadout (read + switch) so that interface stays within its member budget; reach it through LoadoutSave.
What a save copies. The server stores the LIVE setup — class, gear, modules, skill bar (including the Battle Imagine slots) and talents — into the target loadout, including any edits the player has not saved to the worn loadout yet. The target keeps its own name. The player stays on the worn loadout; nothing switches. Deep-Slumber is not part of a game loadout.
Validation. The game’s own wrapper runs the request, so the server validates it (for example it refuses in combat) and the game shows its own success or refusal tip. This service never bypasses that.
public interface ILoadoutSaveMembers
Section titled “Members”| name | description |
|---|---|
| HasUnsavedChanges { get; } | True when the worn setup differs from the worn loadout’s saved data — the game’s own “unsaved changes” check (the one behind its switch warning). Cached: re-evaluated when the game merges new character data, when the loadout list is re-read, and after a save — never on a timer. False until the first evaluation. Read on the game tick. |
| SaveCurrentToAsync(…) | Saves the worn setup into the loadout identified by index. Completes without sending anything when index is the worn loadout (Rejected), is not a saved loadout (NoSuchLoadout), when the worn loadout is not known yet (GameApiUnavailable), or while a loadout switch or another save is still in flight (Rejected). A refusal from the game itself is Rejected. On Success the framework re-reads the loadout list, so GetSlots and LoadoutsChanged catch up with the saved target shortly after. |
See Also
Section titled “See Also”- namespace Stellar.Abstractions.Services