Remember outdated mods or force update

[SmallPepperZ]

Is your feature request related to a problem? Please describe.

There is no way to track mods that have not yet updated to a specific version and install them when they release.

Describe the solution you'd like

There are two solutions I have considered, the first one is preferrable for me, but either would be great

1. Make mcman update with a version flag (or potentially an additional force flag) rename mods that aren't compatible with the specified version to <modfilename>.disabled (for consistency with multimc. If mcman update is run again, and a mod that was previously disabled for being outdated now has an updated version, download the new version and remove the mod.jar.disabled file
2. Store mods that have not yet updated to the specified version in the database, and check if they have updated to the requested version when mcman update is run, and if so, download that version.

Describe alternatives you've considered

I have considered storing them in a separate directory and running mcman update occasionally in that directory to see if they update, but it would be more convenient to have it all in one directory

[Senth]

Hi! Awesome suggestion! 😃 I prefer the first approach as well. This ties into #75 and #76 as well

I have also been thinking of making the version command mandatory mcman update 1.17 since it generally doesn't make sense to update mods to different versions. But I also like the ability to "store" what version the mods should be updated to locally. That is something that will come with the GUI release in 2.0.0, which also will require some changes to the CLI.

Blocked by #75

[Senth]

An Idea I got is that before applying all the changes, mcman can ask the user if they want to apply the change. This would list all the updates, what would be updated, disabled, and enabled. But this should probably be split into another issue.

[Senth]

After starting to think more in-depth about v2 of this app which includes a GUI, I actually think the second approach is better since it's actually two different behaviors.

Scenario that highlights the problem with the first approach

1. I install a mod that I only occasionally want to use
2. I temporarily disable the mod in MultiMC. It now has .disabled.
3. A new update to the disabled mod is released.
4. Mod is updated and enabled by default.

I could always check the disabled mod and see if it actually was compatible with the existing MC version to see that it should not be enabled (but maybe still updated?)

A slightly more complex scenario

1. I install a mod that I only occasionally want to use
2. I temporary disable the mod in MultiMC
3. I now update MC to a newer version
4. A new version has already been released.
5. When I run mcman update it updates the mod and enables it. Because the old mod version was incompatible with the MC version therefore it thought that it was only disabled because there was no update.

Therefore I think it's best to separate the concerns. Only only handles the enabled/disable of the mod, and should do it in the same manner as MultiMC like in #75

A second option should be to mark a mod as incompatible. This can be done in various ways.

Options

1. Add .disabled to the filename and mark it incompatible in the DB
2. Add .incompatible to the filename
3. Remove the file completely, but mark it as incompatible in the DB.

Discussion

I dislike option 1 because it mixes two different things, incompatibility and disabled. Meaning you can accidentally enable a mod in MultiMC even though it's incompatible.

Option 2 doesn't interfere with disabled mods, and you cannot accidentally enable a mod in MultiMC. However, MultiMC will still see the file. It's also consistent with MultiMC (appending a file ending).

The setting carries across devices (if you for example sync folders between computers). In v2 of the app there will be one central DB for all instances, and no addition of a minecraft-mod-manager.db in each mods directory. There will be other settings that can't be synced.

Option 3 does have its merit though. It declutters the mods folder and you don't have to see incompatible mods in MultiMC. There's one drawback though, it's if you want to move, copy, or export the mods folder. The incompatible mods will be lost.

Decision

Go with option 2. Append .incompatible to the file