Enjoy a seamless modpack installation process and effortless updates with a user-friendly solution that simplifies management, making your gaming experience a breeze.
Is your feature request related to a problem? Please describe.
I run a headless (as in openjdk-17-jre-headless) server on a machine that I own. This server has no graphical environment available and is configured to automatically restart on failure.
This interacts with automodpack in the following ways:
Automodpack attempts to update itself and its dependencies on start, meaning the server configuration can change randomly.
Automodpack attempts to show a dialog window to tell the user it has finished updating, meaning it crashes in a headless JRE.
Describe the solution you'd like
I'd like two config options, at least on the server side:
update-check: bool: Whether AutoModpack should try to update itself and its dependencies.
show-update-dialog: bool: Whether to display the dialog window.
Describe alternatives you've considered
The second issue can be worked around by letting the server crash and having my recovery configuration kick in to restart it, but that doesn't address the first issue.
Additional context
If it were me, I would probably remove the remote updating functionality altogether.
I am kind of against auto-update on servers as a whole. I get why it exists, and i get why you'd want it for AutoModpack specifically considering the way it works what with protocol changes and all that, but I don't think it's a good idea to implement it inside the mod.
There are multiple reasons for that:
The issue above where the mod breaks itself on some widely deployed java distributions
Server administrators want their environment to be as static as possible
Clients restart more often than servers, which is more likely to lead to version mismatches when one mod updates itself
Most launchers for modded minecraft already come with support for checking for mod updates
Security; I know you update from modrinth now, but there's no real way for me to know if that changes to a malicious link in the future, and no way for me to stop it if it does.
More implementations of updating schemes means a bigger attack surface in every client.
This mod is already very clever. I tend to think that limiting cleverness to where it is necessary makes for better code.
Skidamek
commented
1 year ago
Is your feature request related to a problem? Please describe. I run a headless (as in
openjdk-17-jre-headless) server on a machine that I own. This server has no graphical environment available and is configured to automatically restart on failure.This interacts with automodpack in the following ways:
Describe the solution you'd like I'd like two config options, at least on the server side:
update-check: bool: Whether AutoModpack should try to update itself and its dependencies.show-update-dialog: bool: Whether to display the dialog window.Describe alternatives you've considered The second issue can be worked around by letting the server crash and having my recovery configuration kick in to restart it, but that doesn't address the first issue.
Additional context If it were me, I would probably remove the remote updating functionality altogether.
I am kind of against auto-update on servers as a whole. I get why it exists, and i get why you'd want it for AutoModpack specifically considering the way it works what with protocol changes and all that, but I don't think it's a good idea to implement it inside the mod. There are multiple reasons for that:
This mod is already very clever. I tend to think that limiting cleverness to where it is necessary makes for better code.