LethalModDataLib

LethalModDataLib

A library for mod data saving & loading.

What is this?

This library provides a standardised way to save and load persistent data for mods. It is designed to be easy to use and

flexible, offering multiple different ways to interact with the system, depending on your needs.

Data is saved in.moddata files, which are stored in the same location as the vanilla save files. Instead of having a

single file, or a file per mod, the library has a file for each save file, and a file for general data - essentially

mimicking the vanilla save system. This ensures that mods do not pollute the vanilla save files. The library makes use

of ES3 to handle the actual saving and loading of the data, which should be compatible with most Unity types.

When saving and loading data through the library, keys are automatically generated based on your mod's GUID and assembly

information (depending on the approach used - see below). This ensures that your data does not conflict with other mods'

data, and that it is easy to find and debug.

File structure

ZeekerssRBLX

└── Lethal Company

├── LCGeneralSaveData

├── LCGeneralSaveData.moddata

├── LCSaveFile1

├── LCSaveFile1.moddata

├── LCSaveFile2

├── LCSaveFile2.moddata

├── LCSaveFile3

└── LCSaveFile3.moddata

As you can see, there is a.moddata file for each vanilla save file, including the general save file. Mods do not

have individual.moddata files, and do not touch the vanilla save files.

Supported types

See Easy Save 3's documentation for a list of

supported types. In general, most Unity types are supported, as well as custom classes and structs that are

serializable.

Usage

There are 3 ways to use this library. They can all be used in the same project, with some caveats.

• Using the ModData attribute

This is the easiest and most automated way to use the library. Unless you need to manually handle saving and loading,

this is the way to go. Note that this method still allows you to manually handle saving and/or loading if you need to,

so you are not limited to the automated part.

Depending on the attribute configuration, the library will take care of saving and loading data for you, in a way that

is seamless and "invisible" / does not require you to add any additional code beyond the attribute.

The ModData attribute can be used to mark fields & properties that should be saved and loaded through the handler's

event hooks. When applied to static fields or properties, the attribute will automatically register the class with

the ModDataHandler, and the data will be saved and loaded depending on the attribute's parameters. When applied to

non-static fields or properties, the attribute will be ignored unless you register the class' instance with the

ModDataHandler through the RegisterInstance method.

The ModData handler will save the original value of your field or property, and use this when no mod data exists

when loading a save file. This ensures you don't need to manually reset a value whenever a player would switch saves,

or when a new save is created. If you wish to reset a value when a game over happens, you can use the ResetWhen

parameter.

This is the attribute's constructor signature:

public ModDataAttribute(SaveWhen saveWhen, LoadWhen loadWhen, SaveLocation saveLocation, string? baseKey = null)

These are options for its 4 parameters:

• SaveWhen (enum) - When the data should be saved
• Manual - Manually handled by you, the modder
• OnAutoSave - When the game is autosaved (= Whenever the ship returns to orbit)
• OnSave - When the game is saved (Most frequent - also called by autosaves)
• LoadWhen (enum) - When the data should be loaded
• Manual - Manually handled by you, the modder
• OnLoad - When a save file is loaded, right after all vanilla loading is done
• OnRegister - When the attribute is registered, as soon as possible
• SaveLocation (enum) - Where the data should be saved
• GeneralSave - In a.moddata file that fulfills the same purpose as vanilla's