Thunderstore accessibility

[otDan]

We need to provide some changes to have thunderstore support our loader and godot games in general.
Currently we want:

• then mods path that can be provided as a cli argument
• a config folder that can be provided as a cli argument

---

Edit by @ithinkandicode to add checklist:

• CLI arg for mods path -- Add cli argument for mod folder path #28
• CLI arg for configs path -- Config JSON #31
• Tightly couple mod ID to package ID -- Remove id meta tag and validate mod ID #51
• A standard way for mods to handle configs, tied to mod ID -- Config JSON #31
• Move non-Thunderstore metadata keys under their own object -- Update manifest key validation to match Thunderstore requirements #27

[KANAjetzt]

From the Thunderstore Discord discussion:

Mythic — Today at 10:24
so yeah I guess primary concerns summed up:

• tightly coupling the mod ID to package ID end to end would be great (so making them match with Thunderstore IDs to benefit from the ecosystem guarantees)
• a standard way for mods to handle configs, which are somehow tied to the ID scheme to prevent cross-mod conflicts
• packaging seems like it might end up being error prone and/or cumbersome the way it's currently, it'd be good to solve either with a tool for building packages, or an intelligent loader (the preferred option based on my experience)

[KANAjetzt]

CLI Tool for building Thunderstore packages

Mythic — Today at 10:24
so we have this CLI tool meant to be for building Thunderstore packages: https://github.com/thunderstore-io/thunderstore-cli/wiki
if you'd like, we could add first party support for building packages for your mod loader with it
right now it doesn't do anything complex but we've been meaning to eventually add integrations to specific loaders/game engines/etc
adding @aaron since he's developing the cli atm
something to note regarding the CLI is that it's designed to be callable from other software too

[KANAjetzt]

_meta.json / manifest topic

Mythic — Today at 10:44
ah! one more thing about the manifest now that I still remember, if we're going to re-use the manifest for both the loader and Thunderstore (which would be the efficient solution if it's possible), I'd suggest moving the non-thunderstore supported metadata keys under their own object of some kind
so assuming we don't add new fields to our current scheme (which we will do), it could be something like this:

{
    "name": "Invasion",
    "version": "0.6.0",
    "description": "Adds content from Space Gladiators",
    "website_url": "https://github.com/BrotatoMods/Brotato-Invasion-Mod",
    "dependencies": [
        "Dami-ContentLoader",
        "Darkly77-BFX"
    ],
    "extra": {
        "godot": {
            "id": "Darkly77-Invasion",
            "incompatibilities": [],
            "authors": ["Darkly77"],
            "compatible_game_version": ["0.6.1.6"],
        }
    }
}

the reasoning being that we will eventually validate that there are no extra fields at the root level of the manifest
right now that is not validated for but it would become a backwards-incompatibility for you when we do add that validation
so we could already agree on what the root-level key is for unformatted data, and you could use that for anything you want to add that we can't or don't yet support
that said, from the set of fields you have that we don't, we can add at least authors directly already

---

Mythic — Today at 10:51
so basically we want to move all non-validated data under a single key in the manifest
which allows all fields outside of those to be trusted as validated
eventually it'd be nice to allow ecosystem content to provide their own set of validation rules for their custom metadata, but that's a bit more than what we can reasonably do for this timeframe 😛
would be a great candidate for the game version validation for example

[otDan]

this is a bigger thing than what we started with, probably best for everyone to work on it

[ithinkandicode]

_meta.json / manifest topic

Reference: https://thunderstore.io/package/create/docs/ - Package Format Docs

[MythicManiac]

Tightly couple mod ID to package ID

Does this account for how Thunderstore expects the manifest.json to be located at the zip root, whereas (at least a prior version of) the mod loader expects it to be in a sub directory?

There are a few options how that could be solved, my recommendation is making the loader slightly intelligent and have it do special handling that makes it possible to use a single manifest at the root which is shared by Thunderstore and the loader, but there are many ways that could be achieved.

CLI arg for configs path

This can be made a separate CLI arg or it could be shared with the mods path CLI arg. Has that option been considered?

Specifically, it would be possible to have one CLI arg that points to a directory with a standard, such as:

mods/
configs/

Not that having multiple CLI args would be any trouble, in fact, I believe it'd be more versatile. Just wondering if this was considered yet.

A benefit of the "single argument" approach would be that you can use the directory it points to for any potential future needs that needs to be isolated on a mod profile level (such as mod-specific save data) without any extra work.

[otDan]

I would consider this issue resolved, what do you think @KANAjetzt @ithinkandicode @Qubus0?