Lets you define content as only for the server or only for the client. Would add new optional fields to modpack.json with the same shape as dependencies (dependencies becomes content installed on both content installed on the client).
Would need to figure out how I want to handle the two other fields during other modpack operations -- right now assumes the modpack you're making is the exact instance on your computer for things like scanning and eventual installing. This would create points where the content defined in the fields is not able to be found on disk.
Maybe we only include a server field, and the user needs to define that list entirely separately even when there is overlap. Then doesn't scan the instance for those files during lockfile operations and rely on hashes, instead makes requests to the api for metadata given the modpack config and version (throws an error if there is no compatible mod with that version -- if installed with the eventual install command, this should already be verified but if the user has added it themselves it could be invalid). Yup, that's a much better idea.
Lets you define content as only for the server
or only for the client. Would add new optional fields tomodpack.jsonwith the same shape asdependencies(dependencies becomescontent installed on bothcontent installed on the client).Would need to figure out how I want to handle the two other fields during other modpack operations -- right now assumes the modpack you're making is the exact instance on your computer for things like scanning and eventual installing. This would create points where the content defined in the fields is not able to be found on disk.Maybe we only include a
serverfield, and the user needs to define that list entirely separately even when there is overlap. Then doesn't scan the instance for those files during lockfile operations and rely on hashes, instead makes requests to the api for metadata given the modpack config and version (throws an error if there is no compatible mod with that version -- if installed with the eventual install command, this should already be verified but if the user has added it themselves it could be invalid). Yup, that's a much better idea.