Skip to content

A shared store of static mod files, linked into instances #84

Description

@Maximilian-Nesslauer

Where this stands today

#72 installs a release by unpacking the archive into the instance's mods folder.
A mod used in three instances is on disk three times, and every instance that updates downloads and unpacks the archive again.

The plan as described

Keep instancing.
Keep the static files of a mod version once, under something like Borea\Static Mod Files\<Mod>\<Version>.
Link Instances\<Instance>\mods\<Mod> into it: a junction on Windows when both sit on the same drive, a symlink on Linux, macOS, and on Windows across drives.
Junctions because creating a symlink on Windows might cause more issues.
Let a mod opt out of being static, because some mods write into their own folder: an in-game part maker can mark its meshes and textures as non-static, since they can change.

What it should be instead

Today Should be
One copy per instance. One copy per mod version in the store, and instances link to it.
An update downloads again. An update to a version another instance already holds is a link and no download.
Every folder is treated the same. A mod that writes into its own folder is copied, not linked. How a mod says so is open: a field in the index would be an RFC, a list inside Borea is a stopgap.
Uninstall deletes the folder. Uninstall removes the link, and a version nobody links any more is removed from the store.

Open questions

  • Whether the game follows a junction or a symlink in the mods folder is unverified. ModLibrary.AddMods enumerates the subfolders and Mod.MakeUsing takes the id from the folder name, and both need a test with a linked folder before anything is built on it.
  • Symlinks across drives on Windows, and what a user without developer mode gets.
  • A shared folder that one instance's mod writes into is a folder every instance sees, which is the reason for the opt-out and also its test.

Not in scope

Any field in the index, and mods that are not installed through Borea (#52).

Depends on

#6, which #72 implements.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:coreBorea.Core, the domain modelarea:storageBorea.Storage, persistence and TOML

    Projects

    • Status
      Backlog

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions