Server starter / Pack updates

[Chikage0o0]

For practical use, would it not be more convenient to integrate the start-server directly into the program。It will allow you to run on more systems

[nothub]

You mean installing and starting the modpack-server all in one command? I am not sure this is helpful for many people tho because running the server as a service (e.g. systemd unit service) is usually better because of handling the startup etc. But thats just my use-case.

This could be added to the root command as a option flag as --start or --start-server or something simmilar.

[nothub]

Maybe it would also be a good feature to have another option flag to generate a systemd service unit file simmilar to this one.

[Chikage0o0]

For example, you can run mrpack-install run to start the server and download jre according to the system, adding the --install-service flag will install this command to the system service at the same time, this will result in better cross-platform compatibility

About the installation and management service https://github.com/kardianos/service

Now that the installer is ready, why not make it a server launcher?

[Chikage0o0]

After thinking about it for a while, this feature is not necessary.

[Chikage0o0]

For automatic updates, do you think there is a need for development? We can record the file name and its corresponding Hash value during the first installation, compare it during the update, add or delete to the mod file according to the file record, and overwrite (merge) only the modified files after judging the configuration file according to the Hash value

[nothub]

After thinking about it for a while, this feature is not necessary.

I think the idea of having all steps of the deployment done by the tool is good. The --start-server flag for start after installation and a subcommand systemd for generating the service unit file will go on the todo list.

[nothub]

For automatic updates, do you think there is a need for development?

Yeah this would be a nice feature to have.

We can record the file name and its corresponding Hash value during the first installation, compare it during the update, add or delete to the mod file according to the file record, and overwrite (merge) only the modified files after judging the configuration file according to the Hash value

I think the problem with comparing hashes is, that it is not required for override files to be declared in the index file. Some mod packs distribute mod jar files as overrides in their mrpack. It will be very hard to cover all mrpack use cases for the updates.

In the labrinth api, there is an endpoint to get file information from a hash value, so we could take a hashsum of each file in the mods/ directory and call the endpoint https://api.modrinth.com/v2/version_file/{hash} -> example. If the files detected mod is present in the up-to-date index, we can delete the old file.

Whatever we do, I would prefer to not save a state for the tool to refer to at all, to keep it simple.

// edit: I just realized that will also only work for files published on Modrinth :thinking:

[Chikage0o0]

// edit: I just realized that will also only work for files published on Modrinth 🤔

The best I can think of is to record the file structure from the last installation and then incrementally update the installation directory

[nothub]

Could we also achieve the same by comparing the old and the new modrinth.index.json?

The process i am thinking of is the following:

Step 1: Delete the set of mod files that are declared in the old index but not present in the new index. Step 2: Download the set of mods files that are declared in the new index but not present in the old index. Step 3: Extract new overrides but do not override existing files.

This would require to store the mrpack file with the server deployment (we do this already). To solve the problem of ordering the archive files (inconsistent naming, bad timestamps possible). I would suggest to only keep the currently installed mrpack archive. At the end of an update process, the old mrpack file should be deleted or marked to be not used for update comparsion anymore.

What do you think about this? This should be fine to use to do an update to the next consecutive version but also to skip multiple version updates in between.

[Chikage0o0]

The biggest problem with modrinth.index.json is that modrinth.index.json only contains information about the files that need to be downloaded, which does not include information about the files in the overrides.

[nothub]

Yes you are right. When handling overrides i can only see 2 possibilities; either overwriting all old override files with new ones or skipping all existing files.

If someone chooses to include mods as override files and later updates also via override files, that will be an issue. Also it will be hard to decide to keep old override files or use new files (or delete files that were removed from the overrides) if the files are changed by the server at runtime.

We could however ask the user for confirmation in a dialog to either keep or delete the file. Maybe with an additional flag --silent / --force.

[Chikage0o0]

Yes, we can tell the user what actions the program will do at the end of the analysis, and he can agree to each or all of them.

[nothub]

update feature was implemented in #8 :ok_hand: