Silksong.DataManager

[BadMagic100]

Background

The Silksong.DataManager plugin (working title) is our extension of the limited config capabilities in BepInEx.

Requirements

• It should be possible to read and write arbitrary JSON data via this with newtonsoft (shipped with the game)
• It should be possible to handle the following scopes of data:
  • Global user data - any arbitrary files at a path which can be set by the user. This could be used for holding large amounts of data across profiles, e.g. skins
    • Global user data is derived from the following requests:
      • As a user I do not want to have to take additional steps to install skins, or to risk losing skins entirely, when switching mods/profiles
      • As a user I do not want large assets taking up disk space at unconfigurable locations
    • It might be the case that it is more reasonable to defer these problems to Cogfly; if this can be done this can be discarded from scope
  • Profile-scoped mod settings - similar to HK global settings but scoped to a profile
  • Global-scoped mod settings - similar to HK global settings, not scoped to a profile. Synced by steam cloud.
  • Save data - similar to HK local settings, synced by steam cloud.
• It may be desirable to create a mechanism to easily and/or automatically merge profile and global settings (with profile settings taking precedence in conflict so they can be set by modpacks and such).
• When deleting a save, all save data for that save should be deleted
• When loading a save, it should be prevented if the save contains data from a mod that is not installed. Mods should be able to opt out of this behavior by indicating their data is not critical for the save to function.
• With the exception of global user data, all of these types of files are automatically loaded and saved at the appropriate time (e.g. mod settings loaded when game loads and saved when game closes; save data loaded when save loads and saved when game saves).
• The paths of all these types of files should be easily accessible to mods so they can read and write custom data without using the primary DataManager APIs (particularly of interest for the global user data folder). For example, if save data is implemented like HK where a plugin implements an interface that deals in only objects of the SaveData type and the API automatically saves and loads data in that shape, there should still be a way for mods to access Silksong.DataManager.Paths.ModdedSaveDataFolder.

Implementation Idea

What we had in HK was pretty good, using an interface approach. The only thing that's pretty ugly there is the way that mods are notified that save data is being reset from a quitout (by receiving default(T) settings to OnLoadLocal).

Also pasting my initial proposal for reference

Profile settings - tied to a profile, not synced by steam cloud, these live in $Profile/BepInEx/config/pluginguid.json. These serve the same purpose as what bepinex can do but for more complex settings.

User settings - equivalent to HK global settings, synced by steam cloud, living at $Saves/mod-settings/pluginguid.json.dat

Save data - equivalent to HK local settings, synced by steam cloud, living at $Saves/userX-modded/pluginguid.json.dat. We should have some features here that hk mapi is missing such as not allowing you to load a save which has data from a mod that is not installed (unless that mod has explicitly said it is safe beforehand) and allowing modeling some subset of data as immutable to allow mods with larger saves to reduce disk writes

User data - a user configurable path to hold larger data like skins (uses bepinex config to define this path with some sensible default idk)

[Azim]

Why is user data needed at all?
skins now being effectively mods which are installed into profiles, is there any reason for such global folders?

The paths of all these types of files should be easily accessible to mods so they can read and write custom data without using the DataManager APIs (particularly of interest for the global user data folder)

that contradicts itself.
if we make paths user-configurable, then mods need to use an API to retrieve user-configured path

[dpinela]

I'm implementing a part of this - specifically save data - because I need it for one of my own mods.

[dpinela]

I've implemented an interface for save data that only needs to be set once that looks like this:

namespace Silksong.SaveDataManager;

/// Interface for mods that need to store some save data at the start of each new game,
/// but don't need to change it afterwards.
public interface IOnceSaveDataMod<T> : IOnceSaveDataMod where T : class
{
    /// The once-save data for the current file.
    /// SaveDataManager reads and stores its value once at the start of each new game,
    /// after GameManager.StartNewGame completes.
    /// If this property is null at that time, no data are written for that file for the client mod.
    /// Upon loading any existing file, this property is set to the saved data for that file
    /// for the client mod, if any exists.
    /// If no such data exists, or the game is at the title screen, this property is set to null.
    T? OnceSaveData { get; set; }

    System.Type IOnceSaveDataMod.OnceSaveDataType => typeof(T);

    object? IOnceSaveDataMod.UntypedOnceSaveData
    {
        get => OnceSaveData;
        set => OnceSaveData = value == null ? null : (T)value;
    }
}

/// An implementation detail that must be made public due to accessibility rules.
/// Client mods should instead implement IOnceSaveDataMod<T>.
public interface IOnceSaveDataMod
{
    /// The target type to use when deserializing save data for this mod.
    System.Type OnceSaveDataType { get; }

    object? UntypedOnceSaveData { get; set; }
}

I chose to inherit from a non-generic IOnceSaveDataMod to make SaveDataManager's implementation simpler. Also I constrained the save data type to be a reference type so that we can use null as a signal that no save data is present.

[BadMagic100]

I think it would be better from the user's perspective if they didn't have to set the type; if you're doing reflection already anyway working with the generic directly is not especially difficult, the only extra steps are

1. Get the generic base type (to check if it's the interface you want)
2. Get the generic type parameters (to get the value type)

Other than that I like this implementation

[dpinela]

I'm actually not doing reflection, that's the thing - when scanning for client mods I can just do this:

foreach (var (_, mod) in BepInEx.Bootstrap.Chainloader.PluginInfos)
        {
            if (mod.Instance is IOnceSaveDataMod modInstance)
            {

and then work through IOnceSaveDataMod. Simpler than reflection, and also a bit more type-safe.

I'm not sure what you mean by not having to set the type?

[BadMagic100]

I mean that they have to do this
System.Type IOnceSaveDataMod.OnceSaveDataType => typeof(T);

Looking again though having to implement the untyped data is also not great

[dpinela]

They don't, though - IOnceSaveDataMod<T> has default implementations for both of these, so only OnceSaveData needs to actually be defined. I'd even have made the non-generic version of the interface internal, but C# doesn't allow that.

[BadMagic100]

I thought default interface implementations require runtime support and don't work outside .net 6+

[BadMagic100]

Hm, I was only a little right

To utilize this feature, your project must target .NET Core 3.0 or later, or .NET Standard 2.1 or later. This feature is not supported in the .NET Framework, including version 4.8

Neat, good to have in the toolkit assuming it actually works at runtime, unity's mono is not entirely compliant with the standard but if it works it works

[dpinela]

I will check more closely later, but I am actually using this already in another mod so it seems that it indeed works at runtime.