Scope Discussion

[Maximilian-Nesslauer]

We should agree on the scope of what we are actually building.
Everything below is genuinely open. What comes out of this thread becomes RFC 0001.

Please reference the numbers so the thread stays followable, and feel free to answer only the ones you care about.

1. Mods only, or published content in general?

Mods are obviously in. The open part is everything else that gets published and passed around.

A published vehicle is mechanically a file plus some metadata that somebody downloads and drops into place, and therefore not that different from a mod. Saves and modpacks are the same shape.

All of it lives under the same Constants.DocumentsFolderPath root as mods do, so a tool that touches that tree at all is already halfway there, and we would have an easy opportunity to manage other things too.

• What transfers: file placement, install and uninstall, tracking what came from where, and the whole instance question. That work is shared.
• Dependencies transfer too. A vehicle built with modded parts needs those mods installed, so it has a dependency on them in exactly the sense a mod does. If anything this makes the case for handling them together rather than against it.
• What it costs: every additional content type adds to the metadata format, the index, the publishing workflow and the UI. I think that we should be careful of having a too large scope.

2. Where does the catalogue come from?

A manager needs to know what mods exist, where to download them, and what they work with. I think it is important not to rely on any additional costly S3 storage or VMs. Four sources exist today:

• SpaceDock's API. Where most KSA mods already are. No notion of a mod id in our sense, no dependency data etc.
• Something close to the existing KSA CKAN index at KSAModding/KSA-CKAN-meta. Public, machine readable, CC0, one JSON file per mod release, plus a builds.json game version list that updates itself hourly from the master server through a GitHub Action, so it costs nothing to run. We could build an equivalent, or just read it.
• Nothing that exists, and we define our own.

3. The loader: external dependency, specified interface, or our own?

Every KSA code mod needs StarMap. The game has no concept of a code mod at all: mod.toml declares assets, and nothing in ModLibrary loads an assembly. See research/starmap.md.

A. Treat StarMap as an external dependency. Install it like any other mod and declare it as a dependency of code mods. This is what the CKAN fork does today and it works. Cost: we inherit its release cadence, packaging and roadmap, and it installs and behaves differently from a normal mod.

B. Build or absorb a loader. Cost: ModAssemblyLoadContext and its resolution order, Harmony orchestration, and the per-mod assembly isolation that lets two mods ship different versions of the same library. StarMap already does all of that, is MIT, and works. Rebuilding it splits the only working loader in the ecosystem.

One live example makes this concrete. StarMapLoader/StarMap#80 adds -InstancePath and INSTANCE_PATH through a Harmony prefix on the getter of KSA.Constants.DocumentsFolderPath. If it lands, it is the first mechanism by which two KSA setups can hold different mod sets, because that one property roots everything user writable: mods, the manifest, saves, settings, vehicles, screenshots. If it does not land, instancing as currently imagined does not exist. Our design would depend on a decision in someone else's repository.

4. What is this repository, and where does the implementation live?

This repository exists to design the client, not to produce a specification for its own sake. What gets decided here is what gets built.

Where does the implementation live? Borea is the Mod loader furthest along by a distance, it is the only implementation with current momentum, and it is structured well for this. Its author @MrJeranimo is a steward here. Several other attempts exist and have not seen a commit in months.

The options:

• Borea is it, where it is. It stays in @MrJeranimo's repository.
• Borea is it, but moved into the KSAModding org. Same thing, but with more people able to maintain it. That matters for a project that should still work in many years, because it means there is always someone who can keep it alive. Entirely @MrJeranimo 's call.
• We start fresh and Borea continues separately.

Edit: @MrJeranimo has approved the move of Borea to the KSAModding org.

5. What should this explicitly not do?

• hosting mod files ourselves,
• anything that needs a service somebody has to keep running and paying.

Push back on any of these, and add the ones I have missed.

[PlazmaBoltz]

we should include modpack and vehicle downloading with any future mod loader

[MrJeranimo]

1. Mods only, or published content in general?

I think for a full sized Mod Manager it should be most published content, mods, mod packs, vehicles, game saves, etc. This would make the most sense as it would make it so there doesn't need to be multiple pieces of software for each (CKAN, KerbalX, etc.).

It would also make dependency resolution for modded vehicles, save games, even multiplayer servers when that gets created, much easier as the Mod Manager (or KSA Content Manager now) can check the vehicle save metadata for which mods are required and automatically let the user know and/or download them for the user.

2. Where does the catalogue come from?

From my experience with trying to make Borea connect to SpaceDock's API, I would say either something like CKAN, or perferably, Something entirely different so we can make more design decisions.

If for #1 we decide to have more than mods and mod packs, I think the best decision would be to design our own. We can still use CKAN as a good reference, since it's worked for over a decade now.

Why not SpaceDock

1. SpaceDock doesn't take in ModIds and thus doesn't guarantee unique ModIds. A ModId is the name/id you put in the manifest.toml, mod.toml, and the folder name of the mod in \mods, thus it needs to be unique. SpaceDock uses its own internal Id system but since there is no way to truly check ModIds unless you download the mod and read mod.toml it will make dependency resolution much harder.
2. SpaceDock doesn't take in Mod Dependencies. Currently the only way to list dependencies on SpaceDock is in the description which also makes it extremely difficult/annoying to check for dependencies as you also need the creator to list the dependencies by their ModId rather than their display name. The only way to check dependencies through SpaceDock currently is through the mod.toml (once again requiring the mod to be downloaded), but that only works if the mod is made for StarMap and the creator remebered to list the dependencies in the mod.toml following StarMap's format.
3. SpaceDock doesn't take in the Mod Loader the mod is built for. The only way to currently list which mod loader to use is through the mod's description, once again making it difficult and annoying to check the mod loader.

These reason are just the main reasons why I do not want to use SpaceDock as the permanent Mod/Content indexer.

3. The loader: external dependency, specified interface, or our own?

Personally, external dependency. I only say this since Borea is planning to support multiple mod loaders (only if that ever becomes a thing) and it makes sure that the whole modding ecosystem doesn't collapse if the one mod loader doesn't get support.

Also allows us to automatically change to the official KSA mod API/loader once/if that comes out.

4. What is this repository, and where does the implementation live?

I am completely open to moving Borea to KSA Modding as long as there is a credit that it originally lived under my repository (or that I was the original creator). Sorry, but I plan to use it in my resume for job applications. :)

5. What should this explicitly not do?

Nothing to add.

[Maximilian-Nesslauer]

On 1:
Agreed on the direction, with one split I want to make:
the content type should be a first-class, required field of the metadata format from day one, but the implementation order stays mods and mod packs first.
Widening the format early should be nearly free.

One assumption in your comment we should check before building on it: "check the vehicle save metadata for which mods are required" presumes a vehicle file records which mods its parts come from. I do not know that it does, and if it does not, dependency resolution for vehicles needs the publisher to declare them and we should note that in a spec somewhere.

On 4: Done as of yesterday, the repo is in the org, your credit is in the README, and the license PR is open. Thanks for bringing Borea in :)

[Maximilian-Nesslauer]

Settled by RFC 0025: a content manager covering mods, mod packs, vehicles, and saves, an index of our own definition, StarMap as an external dependency, and Borea as the implementation. The repository is renamed to content-manager-design accordingly. The follow-up threads are #15 and #16 for the metadata format, #27 for the index, and #20 for the loader boundary.