On the topic of self hosted .mrpack drawbacks

[local-interloper]

Enhancement Type

Improve an existing feature

Describe the enhancement

From what I've noticed (and it could me being blind), there seems to be no clean way of updating a modpack when providing a url to your self hosted .mrpack. I tried bumping the version but it didn't catch on. So far best solution I've found is to jump into the container and remove the existing .mrpack. Preferably the container would check for an existing .mrpack and compare versions and names, if the name+version don't match, redownload the mods.

[itzg]

For efficiency of avoiding a redownload it only compares the URL previously provided. My assumption was that you would change the filename at the URL to reflect a change in version.

I can have it download the file and check the versionId within the manifest, but that would require a redownload of the whole modpack on every startup. Would that be acceptable?

I could also have it save off the last update time and use https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since but not all web servers are compliant with that.

[local-interloper]

For efficiency of avoiding a redownload it only compares the URL previously provided. My assumption was that you would change the filename at the URL to reflect a change in version.

I can have it download the file and check the versionId within the manifest, but that would require a redownload of the whole modpack on every startup. Would that be acceptable?

I could also have it save off the last update time and use https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since but not all web servers are compliant with that.

Perhaps having it redownload the whole thing every time the server is started might even be a preferable option since having to change the url each time on both the server and the container is less than optimal administration wise.

Primarily because the user does not restart the server that often(?) and if they do for memory reasons it could be done in off hours.

I have an another proposal, adding a MODRINTH_FORCE_REDOWNLOAD_MODPACK env var that can be set for the frature to be enabled. Or if it's going to be a cross type feature we could omit the modrinth prefix. Or even shorten it further, it's already a mouthful.

[itzg]

I have had to provide support for many users with terrible network connectivity, so redownloading is not necessarily a trivial matter. With that said, I like the suggestion to accept an option to request such redownload.

I'll give this some more thought.

[local-interloper]

That's interesting cause I expected most ppl running it off a VPS like I do but they could also be running a bigger modpack.

Do you have any cleaner idea on how to address this instead of changing the url or dropping into a shell and nuking the pack from within the container?

That being said, thnx for a quick reply and support, much appreciated <3

[itzg]

Those are the only two approaches I can think of for now. Again the expectation in current implementation is that URLs would be formatted like https://example.com/yours-1.5.2.mrpack

[local-interloper]

Does the url itself get checked for a semver tho?

[itzg]

No, it's just checking for any difference.

[local-interloper]

I went with the URL method and strangely enough I had issues getting it to detect a different URL too. To be 100% clear, I host my .mrpack at for e.g. https://whatever-files.com/modpacks/modpack-1.0.0.mrpack and then switch the version number to smth like https://whatever-files.com/modpacks/modpack-1.1.0.mrpack and restart the server to no effect. It could be a me specific issue since the URL is passed as an env-var from portainer but also might not be.