Launcher
Launcher copied to clipboard
MultiMC
Feature Request: Managed Instances
Hello! I run a semi-large Minecraft community where everyone uses MultiMC to play. We have a server that changes mods, versions, features, etc. fairly often. Right now, the process to update one's instance to connect to our server after a feature change look like this:
- I make a new instance in MultiMC with the required settings, mods, and version.
- I export the instance as a ZIP file.
- I send the ZIP file to a discord server where the players then download it
- The players make a new instance from that ZIP file and play.
I think this process could be simplified by implementing a feature I'm calling "Managed Instances." Instead of the process above, it would look something like this:
- I host the zip file somewhere, most likely a web server.
- The player makes a new instance, and selects a new option to have the settings managed by a remote host.
- When the player runs the instance on MultiMC, MultiMC downloads the ZIP file from the web server and checks for changes to the settings or files.
- MultiMC applies the changes and starts the instance.
I think this would be great for communities looking to streamline their custom feature distributions. It would also make it much easier to identify bugs and distribute modpack bug fixes that would affect everyone. Of course the "Managed Instance" wouldn't affect player specific settings like RAM and Credentials.
Let me know what you think! I think this would be pretty feasible to add to the existing program.
I would appreciate constructive criticism and reasons as to why this is not a feature worth adding instead of 👎s, but who am I to judge?
If I had to guess as to why people are wary about this idea, it's because there is a non-zero chance that the remote host could potentially install a malicious instance. I have no clue how an instance could be malicious-- maybe it's as simple as distributing something malicious alongside the actual instance, but there is no denying that it's possible.
What do I know though, that's just my initial reaction and I have no idea how this attack would work. I suppose you could also say that MMC already downloads stuff from remote hosts (see FTB Legacy), but those are one-off installs and isn't some random host somewhere doing whatever it wants.
That is true. I don't know how you would go about checking for malicious content. I guess there could be disclaimers as well warning people to make sure they trust the external host. That OR the distribution could be controlled by MultiMC, and settings/instances could be shared with codes generated in the Application.
Modpack updating would certainly be beneficial, but I think it would be preferable for there to be an Update button rather than the update occurring whenever the pack is started. This conveys the intent of the action of the button better, and means that malicious updates are easier to spot.
It's worth noting that in the scenario @CamJW101 proposes (creating a zip instance every time there is an update and distributing it) there would be the same opportunity for a malicious file to be included in the zip whether it is distributed manually or automatically. It's also worth noting that MultiMC already has functionality for downloading a ZIP instance one-time at creation:
So I think adding a warning message with the option for the user to tick "I trust this source" should be enough to allay any concerns, it's the responsibility of users (and in the case of CraftForge, Curse) to accept the risk for malware concerns. This feature would be extremely useful if implemented and is distinct from #2640 because it's more to do with "user managed" packs rather than those hosted on a third-party service.
Now that Twitch pack search is there, this would be a nice feature to update those modpacks.
Now that Twitch pack search is there, this would be a nice feature to update those modpacks.
#2640 is for the update of "third-party" modpacks. This is more for personal ZIP packs.
What's needed is an API like Technic Solder, but uses Curseforge as it's mod repository. IMO. Then MultiMC could just support it like it already does with the current Solder. Packs could then be created online on the suggested platform and would update on each run by removing/adding mods.
MultiMC does not update Technic Solder packs on each run as of right now either. Besides that, the Technic Platform is generally a mess, IMO.
Even if this was a function end-users had to manually initiate it would still be a great benefit.
I started running a small community server with a custom modpack. My users are smart people, but they are not A+ certified techs. The task of manually maintaining a modpack with around 180+ mods can be daunting for them even while I'm walking them through it.
Some method, any method that would allow server ops and modpack authors a way to provide MultiMC a modpack update and have MultiMC do the technical work of any version changes and mod changes included in the zip is desperately needed. Even if the update zip just contains a change manifest and the mods neccessary to do the work.
MultiMC already allows importing custom modpacks via zip file. A feature to update already imported custom modpacks really shouldn't raise new concerns not already considered when the decision was made to allow importing custom modpacks in the first place.
What about the remote URL is at the instance.cfg? And then can be set at Settings > Miscellaneous
So then can be provided when you share the modpack for the first time. And yes, there is also I trust this source as mentioned above.
Maybe also support git repo?
So then we can choose the branch (just like multimc update channel)
You an achieve something like this with Packwiz, with a little node scripting I can automate adding/removal of mods with it. You then distribute the instance zip with the Packwiz bootstrapper. It will then auto-update on each run. The pack manifest files can be branched to Github pages to be internet accessible.
Still, would be nice for Multi-MC to have it's own implementation. Or maybe bake Pazkwiz in?
I'd love to see the ability to add a custom feed to the list on the left of the new instance screen, complete with options around update options (interval, whether to check or be automatic, etc), signing certificate options, etc.
You an achieve something like this with Packwiz, with a little node scripting I can automate adding/removal of mods with it. You then distribute the instance zip with the Packwiz bootstrapper. It will then auto-update on each run. The pack manifest files > can be branched to Github pages to be internet accessible.
Still, would be nice for Multi-MC to have it's own implementation. Or maybe bake Pazkwiz in?
oh, i dont know packwiz exist. Thanks
This feature would be ideal for private packs. There is already a create instance from URL option. If an update instance feature was included the base implementation could "reimport" the pack, leave files that are already there, minus mods, and replacing files that match. It's the removing if files which is not so easy but that's not all to difficult and could be the second iteration of implementation.
Bit of a necropost at this point, but it really would be useful to have an authoritative instance template in the cloud that users could mirror and download from directly. Only feature I feel is particularly missing from MultiMC. Especially when playing with those less tech-savvy, being able to manage their pack remotely would be a godsend rather than walking them all through how to download mod updates, delete the old files, and tweak config files. Giving them a brand new instance every time works, but that still runs the issue of teaching these players every time how to move over their own configs or what have you. This feature just ticks so many boxes!
I'd like an option to configure a custom "external updater command" for my instance that runs before MultiMC's integrated update checks. The external updater will be responsible for obtaining the new files and validating software signatures. The burden of figuring out the details can thus be delegated to 3rd party projects.
The external updater command would be run with current working directory set to the instance path.
I have some ideas how MultiMC could read progress information from the external updater, but for a start we can make it the external updater's responsibility to create its own window to display progress information.
