I have a question: is it possible with FTB or at least with some other launcher to keep certain mods installed and updated automatically? If I have a similar or larger amount of mods than the DW20 pack it's quite a hassle to keep checking every single mod if it's updated. At the very least I'd like a way to be informed if there's an update and not just for the couple mods that have built in notifications
Keeping mods updated
- Thread starter Unit88
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Well, if I make the mods I've chosen work, then if any incompatibilities rise up there would probably be a log about what was updated last and then I'll know what's the problem. But as I've said a way to keep me notified of the new versions would be enough, but only some mods do that.
There have been mod updates in the past requiring a new version of Forge, which consequently broke other mods that didn't get updated. On that same note you don't want to update Forge for no reason because you don't know what will break if you do. Then there are updates that cause inter-mod failures where you won't be able to tell what existing mod is having an issue.
You will want to update one mod at a time and then test thoroughly before calling it good.
You will want to update one mod at a time and then test thoroughly before calling it good.
Your reply is basically the same as the other b0bst3r's so my reply will also be the same.
No. This is a problem that has been solved, but not for MC mods. The tools already exist to handle tracking installed versions, cleanly adding, removing, resolving dependencies, and even resolving conflicts between packages, however the community has not collectively acted to decide on a standard and utilize either a pre-existing solution or develop a specialized one. There are no significant technical barriers to this, only political ones.
Edit:
Also per-mod version checkers are a hideously inelegant workaround for lacking a proper package management system.
Edit:
Also per-mod version checkers are a hideously inelegant workaround for lacking a proper package management system.
Don't update your pack super often and just go through by hand, some mods have config options to notify you about updates. Other than that I update a few at a time and it isn't that bad. IK this isn't what you want but it's important to keep track of mods and there version or else something might break and you will have no idea how to fix it.
Aww, man, I was really hoping there was one. It's one of the big reasons why I don't di my modding manually anymore. The other is the fact that ihave to find every single mod.
The problem is that I have to check every single mod's page to see if there's an update.
Yeah, it sucks, but not much you can do. I use a combo of Version Checker, and manually checking CurseForge/NotEnoughMods for my personal pack.
I... don't think you entirely understand the problems inherent in your request.
Version compatibility is a thing which does not currently exist, most particularly cross-mod version compatibility checking does not in the least bit exist, and making it would require a fundamental change in how things are done by the devs, and it would have to be a universally accepted practice for it to be even marginally useful. Maybe if Forge demanded it, then it would work, but even then there would be too many problems that simply cannot be checked automatically which would cause the system to return a false positive (or false negative) for it to really work.
Let's take a single example out of the hundreds I have available, just in my very small private mod pack (about a quarter of the mods included that exist in most FTB type mod packs).
Mekanism 8. There's several dozen examples of this just in this one update, but let's focus specifically on the Mek8/EnderIO 2.2 compatibility problem. To summarize, the gas conduits from EnderIO didn't work with Mek8. In fact, they threw a whole bunch of world-corrupting errors. And it was never fixed in EnderIO2.2. It is fixed in the alpha-dev versions of EnderIO2.3, but that hasn't been officially released. There's a version on their Jenkins that works, but as with ANY alpha build, it may have several OTHER negative interactions because they're still developing it, which is WHY they haven't released it yet.
So, let's say your hypothetical automatic version updater saw that Mek updated to Mek8 and updated it automatically, without updating EnderIO to the alpha build (and if it could update to alpha builds, that would crash you so often that you'd never get anything to work), it would not only crash you but have a good chance of corrupting your world file. Good job.
And this is one of literally hundreds of issues I've experienced doing updates in a relatively small mod pack that only contains perhaps a dozen or so 'primary' mods and maybe a couple dozen addon or core or cross-compatibility mods. Now increase that size to a couple HUNDRED mods that some of the FTB packs do, and you increase the amount of problems GEOMETRICALLY. Actually, it would more probably describe a log curve, at least a base 10 if not more. For every mod you add, you add on (number of mods before you added it) number of potential conflicts, so yea... that's an exponential problem.
Maybe now you can grasp the fundamental impossibility of your request?
Version compatibility is a thing which does not currently exist, most particularly cross-mod version compatibility checking does not in the least bit exist, and making it would require a fundamental change in how things are done by the devs, and it would have to be a universally accepted practice for it to be even marginally useful. Maybe if Forge demanded it, then it would work, but even then there would be too many problems that simply cannot be checked automatically which would cause the system to return a false positive (or false negative) for it to really work.
Let's take a single example out of the hundreds I have available, just in my very small private mod pack (about a quarter of the mods included that exist in most FTB type mod packs).
Mekanism 8. There's several dozen examples of this just in this one update, but let's focus specifically on the Mek8/EnderIO 2.2 compatibility problem. To summarize, the gas conduits from EnderIO didn't work with Mek8. In fact, they threw a whole bunch of world-corrupting errors. And it was never fixed in EnderIO2.2. It is fixed in the alpha-dev versions of EnderIO2.3, but that hasn't been officially released. There's a version on their Jenkins that works, but as with ANY alpha build, it may have several OTHER negative interactions because they're still developing it, which is WHY they haven't released it yet.
So, let's say your hypothetical automatic version updater saw that Mek updated to Mek8 and updated it automatically, without updating EnderIO to the alpha build (and if it could update to alpha builds, that would crash you so often that you'd never get anything to work), it would not only crash you but have a good chance of corrupting your world file. Good job.
And this is one of literally hundreds of issues I've experienced doing updates in a relatively small mod pack that only contains perhaps a dozen or so 'primary' mods and maybe a couple dozen addon or core or cross-compatibility mods. Now increase that size to a couple HUNDRED mods that some of the FTB packs do, and you increase the amount of problems GEOMETRICALLY. Actually, it would more probably describe a log curve, at least a base 10 if not more. For every mod you add, you add on (number of mods before you added it) number of potential conflicts, so yea... that's an exponential problem.
Maybe now you can grasp the fundamental impossibility of your request?
The possible mod-mod checks would be on the order of N^2, specifically N(N-1)/2. Obviously higher orders interactions increase this dramtically (ie: an issue between mod A and B that only occurs in the presence of mod C). However, there is no need for exhaustive checks. A system to flag known issues (reported and verified by users) would catch common ones quickly and those would be tagged as problematic and warn the user that there are reported problems with given mod versions being installed together before it would update them. Considering the number of packages installed on the average Linux system (easily on the same OOM, if not higher) we can verify that checking every possibility is unneeded for a "good enough" solution. We certainly wouldn't be any worse off than now, where you have to manually check for updates, perform the update, and then check for issues -- a package manager would make doing all of the above far more laborious. A good package manager would allow you to roll back any changes and restore it to a prior state cleanly, so that when an issue pops up the user can easily roll back to prior versions.
I am not claiming that a package manager would make the issues go away, it simply would make handling them (and many other tasks) far easier.
I am not claiming that a package manager would make the issues go away, it simply would make handling them (and many other tasks) far easier.
You're overcomplicating it a lot. I was simply talking about updating mods. Dealing with incompatibilities is not something that it should resolve, but something users should be prepared to do. Obviously if there was something that could do what I asked it would at the very least notify the user, or better yet ask if they really want to update it. Whenever people are using huge amounts of mods like I usually do, unless it's a official modpack (or sometimes even then) incompatibilities will happen, and the user has to deal with it in some way. Also, anyone who doesn't backup their worlds when using at least moderate amount of mods is simple dumb.
You said devs would have to change things fundamentally, but I really don't think so. If we're talking about checking mod versions internally I don't think it would be too hard, to add a single variable to a mod that tells the program what version the mod is. But that's not needed either. What I think would be the easiest is to have an online database that keeps track of mod versions where any dev could upload their mod, and the program could simply use that database to check if there's a newer version or not. It could maybe use CurseForge as a database even, although I don't know how possible that could be. The database could even store info on what mods are incompatible with what and then the program could warn you.
Also, my proposed system wouldn't be like "Windows update" it wouldn't automatically install/update anything. It would only automatically update it's listing, and potentially inform the user that there are newer versions of mods they have installed. Either, especially the latter, could also be manually invoked only.
Actually performing any changes would require a specific act on the users part. It would handle downloading (and caching locally) the mod files, making backups of the config files should things need to be rolled back, and then removing the old mod and installing the newer version. It preforms the "dumb" drudgery and leaves the executive decisions to the user. Let the human do what the human is good at, and let the computer do what it is good at. Right now humans are stuck doing both. A package manager is a tool to facilitate the user's goals.
Yes, this would require some coordination on the part of modders, but very little in the scheme of things. You could leave it to hosts like Curse to handle what they host (at least as far as keeping an accurate listing of mods, versions, where to get them, and other metadata like that). I think updating a list of releases is not a particularly great imposition, nor would it be that much more work for them to add notations regarding dependencies or conflicts they are personally aware of. In fact such tools would probably lower the support requests from users who install mods and ignore or miss dependencies or conflict notes that modders already post now.
Actually performing any changes would require a specific act on the users part. It would handle downloading (and caching locally) the mod files, making backups of the config files should things need to be rolled back, and then removing the old mod and installing the newer version. It preforms the "dumb" drudgery and leaves the executive decisions to the user. Let the human do what the human is good at, and let the computer do what it is good at. Right now humans are stuck doing both. A package manager is a tool to facilitate the user's goals.
Yes, this would require some coordination on the part of modders, but very little in the scheme of things. You could leave it to hosts like Curse to handle what they host (at least as far as keeping an accurate listing of mods, versions, where to get them, and other metadata like that). I think updating a list of releases is not a particularly great imposition, nor would it be that much more work for them to add notations regarding dependencies or conflicts they are personally aware of. In fact such tools would probably lower the support requests from users who install mods and ignore or miss dependencies or conflict notes that modders already post now.
You don't even have to go to the EnderIO Mek8 issues - going from Mek 7 to Mek 8 alone is a whole nest full of wasps.
And this is why it's not been done, probably never will be done and why mod pack makers (myself inc) would never use an automated update system like the one you are suggesting.
And this is why it's not been done, probably never will be done and why mod pack makers (myself inc) would never use an automated update system like the one you are suggesting.
WUT?
Ummm... no. Attempting to rely on a USER to do something intelligent is the antithesis of good programming. Furthermore, it is the pack dev's job to do this, not the end user. The whole point of a mod pack is to let someone ELSE take care of these incompatibilities so you don't HAVE to. Half the time, the reason a pack has decided to not update is specifically to AVOID these complications because he knows there will be a problem. Why bother pestering you with a mod update that will crash you?
If anything, I am dramatically oversimplifying the problem. Having done coding work and having published a mod pack, perhaps I have a somewhat more realistic appraisal of what it is you are attempting.
Why notify the user of an update that can crash him? That is a Bad Idea, from the mod dev's position, from the pack dev's position, and from the poor sucker of an end-user's perspective who suddenly got himself crashed with no notion of how or why. This causes a flurry of ill-defined bug reports to angrily swarm around the dev who is probably either already aware of the problem or needs something like an actual log post to figure out what is going on, which helps nobody and frustrates the people actually creating the stuff the end user enjoys. This has caused more than one dev to quit, and probably will continue to be a major source of headaches sufficient to cause other devs to walk away from it.
So wait... a full-up searchable real-time database of every single one of the hundreds of mods out there and what version they are on and the ability to tell you when one of your mods is outdated compared to its list is simple Really?
Ummm... I'm not really sure how to respond to that. All I can say is that my experience would disagree with you in the most profound and fundamental way.
Just keeping the versions up to date and keeping those two variables (name of mod and version of mod) current and searchable would be non-trivial. Trying to make some kind of cross-mod compatibility checker is just... flat impossible. Seriously.
Look Buddy, there is a reason not everyone runs a modpack if you don't have the finger clicking energy to do it then maybe running a modpack isn't your thing.
I use the Curse Client right now.. it notifies me when mods update.. I click the mod click the changelog tab read it.. install and run. If it works I move onto the next mod in the list. Super easy if you use CurseForge mods only.