Modpacks

[SaculRennorb]

The general idea is a manifest describing mods and overrides / configs to apply.

A large part of this will have to be in the game itself, the moddb just needs to host the manifest and provide a mod type for it (maybe).

It might already be possible to use a blank mod with just dependencies as a modpack.

[Lueken]

I'm building a launcher for Vintage Story with modpacks as a core goal, so this direction is very welcome. The manifest-describing-mods-plus-overrides shape matches how I'm designing it: a pack references its member mods on ModDB and the client resolves and applies them at install time, so nothing gets re-hosted and every download and stat stays with the authors on ModDB.

The "blank mod with only dependencies as a modpack" idea reads really cleanly once #117's required-relations land. A modpack becomes a normal ModDB entry whose required relations are its members, discoverable through the same search as everything else, and the launcher takes care of the overrides and configs. That keeps the hosting burden on your side small (a manifest and a mod type) and puts the applying-it half where you already expect it to live, in the launcher.

Happy to be a client-side sounding board or an early test consumer for whatever manifest or mod-type shape you settle on. The "large part in the game/launcher" piece is exactly what I'm building.

[SaculRennorb]

Since you are apparently already looking into this topic a bit more deeply, would you mind briefly going over why a "blank mod with only dependencies as a modpack" doesn't already work on the technical side?
We would want a bit more ui decoration around this, but I don't see anything that would be missing on the game mod laoder side of the equation, nor should it be a problem to host such a mod on the db already.

[Lueken]

Fair challenge, and mostly you're right. I don't think anything is actually blocking it. A blank mod with only dependencies uploads fine today and the loader resolves and orders it, so "can you do this at all" is yes.

Where it gets thin is that a dependency is not a pin. ModDependency.Version is documented as the minimum version, and the check passes whenever the installed version is greater than or equal to the requested one, with empty or * matching anything. So a dependency list describes a floor rather than a set. Two people installing the same pack a month apart can both pass validation and end up with different mods, which is usually the opposite of what a pack author wants.

The other two gaps are smaller and both land on the launcher side rather than yours: configs and overrides have nowhere to live in a dependency list (you named those in the original post), and the list is additive only, so there's no way to say a pack dropped a member on update.

None of that argues against the blank-mod approach. It covers the common case and it works now. I'd frame it as: the eventual mod type probably wants "exactly this set" semantics that the dependency field deliberately doesn't have.

[SaculRennorb]

I agree taht the dependency resolution is the main issue that needs to be addressed for this this approach to be viable, but i don't see why overrides and configs cannot live in the modpack 'mod' itself? mods can override other mods after all.

so there's no way to say a pack dropped a member on update.

I am not sure what you mean by this