Reika's Update Checker

[GreenZombie]

Given that these is the FTB forums, mod authors on this thread have to be receptive to the idea that their mods are incorporated into FTB mod packs.

As such, please just start a discussion amongst yourselves and the FTB team to figure out what kind of notification strategy would work best.

In my ideal world, as an FTB user, there would be a separate version mod that is included in a pack, that would intercept all per-mod version checking, and replace it with a single "This FTB pack needs updating", perhaps with a severity indicator "FriendlyPuppy20 1.0.1 contains at least one mod with a critical update. Update the pack to the recommended version now or it might be corrupted".

That should be the usual experience for (almost) everyone reading this thread.

 

[Strikingwolf]

Given that these is the FTB forums, mod authors on this thread have to be receptive to the idea that their mods are incorporated into FTB mod packs.

As such, please just start a discussion amongst yourselves and the FTB team to figure out what kind of notification strategy would work best.

In my ideal world, as an FTB user, there would be a separate version mod that is included in a pack, that would intercept all per-mod version checking, and replace it with a single "This FTB pack needs updating", perhaps with a severity indicator "FriendlyPuppy20 1.0.1 contains at least one mod with a critical update. Update the pack to the recommended version now or it might be corrupted".

That should be the usual experience for (almost) everyone reading this thread.

Doing it launcher-side is fairly impossible for us modders.

 

[TomeWyrm]

Note: Never start a forum thread and then go to sleep sick. I was completely not expecting 6 pages of replies and I have NO idea why not.

Tomewyrm, you're a frequent flier on Reika's forum, can you provide the details (neutrally) of the update checker?

In its current form? Oh hell I'll just give the cliffs notes version on what I remember about most of them.

The first checker I noticed anything about was the ticker/banner. It had a command to disable per mod AND version for two weeks. Each command only worked for say, DragonAPIv6b. If v6c came out while you were still on v6a it would trigger the banner again even if it had been less than two weeks. Note: Not personal observation. My pack has been in config limbo for a while now, and I usually update before I actually boot the instance up while I'm in testing. I've only seen the update banner twice in-game, and in screenshots... and I just updated immediately so I can't comment on the annoyance factor. I actually did precisely what Reika wants us to do, and would have with a notification in VersionChecker, a text message, or probably even some output to the console log.

This first version caused some heat in the community and then @CoolSquid came up with a pretty neat idea of uniquely identifying a pack maker (via file path if I recall correctly) and timestamp, then hashing those and saving it. Then on boot, perform the same action and checks first to see if you're the same person (launching it from the same instance location actually), second if it has been more than X time since the update checker could show you a message (Reika chose two weeks IIRC), and then third if there actually is an update. The implementation used java's inbuilt symmetric encryption (AES? It's one of the official ones baked in with Java.) which prevents easily tampering with the timestamp. If you are the same person and there is an update it would show, if you were a different person and it had been more than two weeks it would show, and obviously it wouldn't show if there's no update .

From there I do believe the next progression is the popup, with the "pack maker" hash check still implemented... but I haven't asked directly and I lapsed on reading the MCF thread.

loss of faith in humanity

See, there's your problem. You still have faith in humanity!
(This is mostly tongue in cheek guys. I'm a misanthrope, attempting a bit of grey/black humor.)

many other developers also have per-login popups and seem to get no hate. Indeed, it was Ichun's mods that gave me the idea.

Wait, he uses a popup? Gods I need to stop being so compulsive about updating so I can see this stuff. All I've ever seen is chat message ones that (I assumed) most of my mods used, which while I personally find them annoying, fade quickly and can be perused at the user's leisure. I've literally never noticed.

I could make it a month, two months, six months - totally destroying the point of an update checker, given my major versions are usually about 1.5 months apart - and you would still complain.

Actually something in the 4-6 week range sounds more reasonable to me personally. I'm on your side of the spectrum for updates, my instance operates on a rolling release schedule, I update something every day when testing/building and generally do "weekly maintenance" on International Patch Day (Tuesday morning) for my server, which is when all those mod updates get stuck in. But I can see where someone dedicated to stability might find two weeks to be insufficient. Which is why I was arguing on Synful's side the last time this came up. While it will almost certainly never affect me personally, I could very easily see quite legitimate issues with the update checker as it WAS implemented.

The "only show if you're a pack maker or if it's been more than the expiration time, and only once per minor update" is the current intended behavior? Personally I don't have a problem with that on paper. The popups give you the instructions on how to turn them off, they go away, they'll only bug you every few weeks unless you're in a reasonable position to update the pack. At this point I personally like the implementation. Wish VersionChecker would quit FUBARing on your mods though. Seeing the updates in NEM that will never detect properly as updated even if I went in to update the bot myself because the mod detects as "gamma" instead of "v6e"... well it gets obnoxious. It only affects some of the mods and I have 0 idea why or why not any particular one.

And now I think I just had the argument with myself that would have spawned the version checker, heh.

You did indeed.

disabled for more than a month with a simple command

I thought the command only worked like the button/hash check in that it alerts you for the next minor... which have occasionally taken over a week to come out. The command goes for MAJOR versions? I still dread having to tell anyone to do that though. It's the age old IT issue of telling your computer-illiterate "customers" something and their eyes glazing over going "I can't understand this so I won't even try, quit trying to teach me anything". Which is a sad state of affairs, but quite literally how the human brain is designed, it really doesn't like not being able to understand things.

That having been said, me personally I like the new popup, just saying again. But conservative/cautious pack authors and server admins did have a point.

I honestly don't think anyone should have an easy time skipping major versions of your mods for any length of time. Ever. For any reason. Those come out rarely enough that you can test just fine in a couple of weeks, and if you can't test the 6-10 mods in that timeframe once every two-to-four months? You really do not have the time to devote to a modpack as a maintainer. Catering to the tail like that is like trying to fix stupid. You're never going to make everyone happy, and in doing so you're just going to piss off either everyone else (like the initial incarnation of the checker) or the creator; generally by defeating the point of the creation's inception or making them waste an inordinate amount of time. If this update checker can allow Monster to happen again, it has defeated the reason it was conceived in the first place. ALWAYS KEEP MONSTER IN MIND! That is the inciting incident and Reika is STILL getting bug reports from Monster's recommended version, which is v19b (1.1.2 which is STILL not recommended is using 23b... not 25z. There are a lot of things I thank FTB for, things I praise them for. Keeping their packs reasonably up to date is not one of them.). That is stupid and unacceptable, nobody should be using v19 anymore. There's a grace period, and then there's Monster.

Been thinking about this for a bit now..

Why don't we have a mod where the sole purpose is to alert users to update mods? It could be something like a splash screen as the user logs in, I've seen similar screens done already. There could be an API for the mod dev to send the version update number, how critical it is, and provide a link or download method with or without instructions on how to install it. You know, have a standardized method of alerting people.

As an average user, I'd love to know when other mods need updating instead of waiting for a new pack or keeping track of 100+ mods.

http://www.minecraftforum.net/forum...81-version-checker-auto-update-mods-and-clean
Already been done, has support for a crapton of mods already, even Reika's... though that's currently broken for some reason. There are also a few dozen other mods that do similar things, but as far as I know, Version Checker is the most used and best supported.

@King Lemming I was unaware that COFH was planning on extending update functionality to all mods. That's pretty neat! Personally prefer a lot about the implementation of Version Checker though. It checks multiple sources as a fallback and it does this in the main menu being the two major ones.

You could make the version checker mod a dependency for dragonAPI. That way players need to have the mod installed to use your mods.

And I'm pleasantly surprised with how this thread turned out. Instead of a massive clusterfrak and several bans, y'all came together on a reasonable solution that satisfies most people.

That was what I was hoping when I made it and specifically told people to keep it focused and clean. The only ways I've ever seen drama wrap up is to forget it, or talk it out with actual information. Luckily most of us here like the information route. Learning is fun!

I have no idea how the mod can know when an update was released

CurseForge. Seriously. With the intention to keep it open for other platforms to use, it is swiftly shaping into the "Nexus" (ala the community mod site for Fallout/The Elder Scrolls and a lot more games besides) for Minecraft mods.

Given that these is the FTB forums, mod authors on this thread have to be receptive to the idea that their mods are incorporated into FTB mod packs.

As such, please just start a discussion amongst yourselves and the FTB team to figure out what kind of notification strategy would work best.

In my ideal world, as an FTB user, there would be a separate version mod that is included in a pack, that would intercept all per-mod version checking, and replace it with a single "This FTB pack needs updating", perhaps with a severity indicator "FriendlyPuppy20 1.0.1 contains at least one mod with a critical update. Update the pack to the recommended version now or it might be corrupted".

That should be the usual experience for (almost) everyone reading this thread.

Doing it launcher-side is fairly impossible for us modders.

CurseForge hosting also solves the FTB launcher problem (they're switching to Curse after it goes out of Beta), and can be used by ATL, and Technic, and anyone else. Seriously, I feel like a broken record praising on the new curse system, but it is THAT GOOD. I've used the launcher off and on for years for my World of Warcraft addons, and their WoW client? It sucks. It's the only option and it does what it is supposed to, but gods if there was a decent option I would be using it right now. I've seen all the insanity like the viruses from hijacked ads, dealt with updating 100+ mods... ONE... AT... A... TIME, waiting for each to download AND INSTALL before clicking the next one because otherwise I might get that stupid "UPGRADE TO PREMIUM! GIVE US MONEY TO STOP NAGGING YOU" popup. I'm in no way shape or form a Curse fanboy. The MCF forums have gone continuously downhill since they took over, I hate gamepedia as a wiki portal/host. Seriously I've got lists that are taller than me and could talk for hours upon hours about the things I don't like about Curse. For anyone that's seen some of my posts, that should come as no surprise (Me? Verbose? <sarcasm> Perish the thought! </sarcasm>). The curse system for MC mods really is that good. They were in talks with FTB and mod authors throughout most of the development process of the launcher beta and curseforge. They are trying to do this right, in a way that the MC community will like and USE. In my estimation? Unless you've got a serious hate-on for Curse? There are basically no real downsides to using the system, or at least none that I've seen excepting possibly the baked-in-permission to be used in uncurated user-submitted Curse Client packs. Which for all the other benefits? Is certainly worth it to me. Also it's a non-exclusive license. You can totally host wherever the crap you want in addition to Curse!

 

[GreenZombie]

Doing it launcher-side is fairly impossible for us modders.

I can see how that might be the interpretation of my statement, but it is entirely not the intent.

With a proposed ftb version jar in the mods folder, the update notification would only arrive after a game has been loaded. But the version check unifying mod would have been configured by the team making the mod, to reflect that the mod pack is out of date, and that the user should exit and apply the update.

 

[Strikingwolf]

With a proposed ftb version jar in the mods folder, the update notification would only arrive after a game has been loaded. But the version check unifying mod would have been configured by the team making the mod, to reflect that the mod pack is out of date, and that the user should exit and apply the update.

Possible, but not really that good because we would have to hardcode it for all the launchers. I like FTB, but if I was going to make this I would want it to work for everything

 

[Reika]

Note: Never start a forum thread and then go to sleep sick. I was completely not expecting 6 pages of replies and I have NO idea why not.


In its current form? Oh hell I'll just give the cliffs notes version on what I remember about most of them.

The first checker I noticed anything about was the ticker/banner. It had a command to disable per mod AND version for two weeks. Each command only worked for say, DragonAPIv6b. If v6c came out while you were still on v6a it would trigger the banner again even if it had been less than two weeks. Note: Not personal observation. My pack has been in config limbo for a while now, and I usually update before I actually boot the instance up while I'm in testing. I've only seen the update banner twice in-game, and in screenshots... and I just updated immediately so I can't comment on the annoyance factor. I actually did precisely what Reika wants us to do, and would have with a notification in VersionChecker, a text message, or probably even some output to the console log.

This first version caused some heat in the community and then @CoolSquid came up with a pretty neat idea of uniquely identifying a pack maker (via file path if I recall correctly) and timestamp, then hashing those and saving it. Then on boot, perform the same action and checks first to see if you're the same person (launching it from the same instance location actually), second if it has been more than X time since the update checker could show you a message (Reika chose two weeks IIRC), and then third if there actually is an update. The implementation used java's inbuilt symmetric encryption (AES? It's one of the official ones baked in with Java.) which prevents easily tampering with the timestamp. If you are the same person and there is an update it would show, if you were a different person and it had been more than two weeks it would show, and obviously it wouldn't show if there's no update .

From there I do believe the next progression is the popup, with the "pack maker" hash check still implemented... but I haven't asked directly and I lapsed on reading the MCF thread.

The "only show if you're a pack maker or if it's been more than the expiration time, and only once per minor update" is the current intended behavior? Personally I don't have a problem with that on paper. The popups give you the instructions on how to turn them off, they go away, they'll only bug you every few weeks unless you're in a reasonable position to update the pack. At this point I personally like the implementation. Wish VersionChecker would quit FUBARing on your mods though. Seeing the updates in NEM that will never detect properly as updated even if I went in to update the bot myself because the mod detects as "gamma" instead of "v6e"... well it gets obnoxious. It only affects some of the mods and I have 0 idea why or why not any particular one.
I thought the command only worked like the button/hash check in that it alerts you for the next minor... which have occasionally taken over a week to come out. The command goes for MAJOR versions? I still dread having to tell anyone to do that though. It's the age old IT issue of telling your computer-illiterate "customers" something and their eyes glazing over going "I can't understand this so I won't even try, quit trying to teach me anything". Which is a sad state of affairs, but quite literally how the human brain is designed, it really doesn't like not being able to understand things.

The intended functionality was as follows:
Default behavior was that everyone sees all messages. Using the command would hide it until the next update, which may have been filtered to the next major version (I do not remember). Using the config would lock it down so that only the pack maker could see it, or it had been two weeks or two major versions. This was under the logic that if it had been more than two weeks, the pack was likely abandoned or poorly maintained, pushing the responsibility of updating onto servers and players, and if two major versions were rapidfired, there was a damn good reason for it.
The command and the config functioned independently.

Now, the packmaker identification appeared not to work, giving both false positives and false negatives, but the above is what was intended.

Actually something in the 4-6 week range sounds more reasonable to me personally. I'm on your side of the spectrum for updates, my instance operates on a rolling release schedule, I update something every day when testing/building and generally do "weekly maintenance" on International Patch Day (Tuesday morning) for my server, which is when all those mod updates get stuck in. But I can see where someone dedicated to stability might find two weeks to be insufficient. Which is why I was arguing on Synful's side the last time this came up. While it will almost certainly never affect me personally, I could very easily see quite legitimate issues with the update checker as it WAS implemented.

Six weeks is pushing up against the major version release separation - which ranges from 4 to 16 weeks - but I can try moving it to three weeks if that will really help. But remember: The longer it gets, the less functionality this code actually has.

I honestly don't think anyone should have an easy time skipping major versions of your mods for any length of time. Ever. For any reason. Those come out rarely enough that you can test just fine in a couple of weeks, and if you can't test the 6-10 mods in that timeframe once every two-to-four months? You really do not have the time to devote to a modpack as a maintainer. Catering to the tail like that is like trying to fix stupid. You're never going to make everyone happy, and in doing so you're just going to piss off either everyone else (like the initial incarnation of the checker) or the creator; generally by defeating the point of the creation's inception or making them waste an inordinate amount of time. If this update checker can allow Monster to happen again, it has defeated the reason it was conceived in the first place. ALWAYS KEEP MONSTER IN MIND! That is the inciting incident and Reika is STILL getting bug reports from Monster's recommended version, which is v19b (1.1.2 which is STILL not recommended is using 23b... not 25z. There are a lot of things I thank FTB for, things I praise them for. Keeping their packs reasonably up to date is not one of them.). That is stupid and unacceptable, nobody should be using v19 anymore. There's a grace period, and then there's Monster.

THANK YOU. This is the point I have been trying (and apparently failing) to drive home. I am saving this page to disk just so I can refer to it and quote it as needed.

CurseForge. Seriously. With the intention to keep it open for other platforms to use, it is swiftly shaping into the "Nexus" (ala the community mod site for Fallout/The Elder Scrolls and a lot more games besides) for Minecraft mods.

How does this help me identify release dates? Is there some database I can read from the code?

 

[CoolSquid]

How does this help me identify release dates? Is there some database I can read from the code?

It says the release date besides the files. A simple BufferedReader should do it.

 

[GreenZombie]

@Reika it's a stupid point that's why.

There are a lot of people still playing mods for 1.4.7 never mind 1.5.2 or more recent versions of minecraft.

Lots of mod makers are quite tardy at updating their mods for new versions of minecraft or drop out of the scene entirely. If such mods require older minecraft versions, have incompatabilities with recent forge versions, or bindings to specific api versions of other mods that can easily lock an entire modpack in stasis.

The owner of a small modded server might have exams or the birth of a child interrupt their ability to keep their server current.

Ffs. Writing RoC is not your job. And I'm sure you dislike players making unreasonable expectations of you.

So grant us the same courtesy. Maintaining mod packs is not our job either so stop trying to force us to do busy work. Especially if it's to cover for low quality code.

 

[SynfulChaot]

Actually something in the 4-6 week range sounds more reasonable to me personally. I'm on your side of the spectrum for updates, my instance operates on a rolling release schedule, I update something every day when testing/building and generally do "weekly maintenance" on International Patch Day (Tuesday morning) for my server, which is when all those mod updates get stuck in. But I can see where someone dedicated to stability might find two weeks to be insufficient. Which is why I was arguing on Synful's side the last time this came up. While it will almost certainly never affect me personally, I could very easily see quite legitimate issues with the update checker as it WAS implemented.

Four to eight weeks is likely more reasonable, though I'll freely admit that if one has the time to devote to it that two weeks is probably more optimal. That being said, we don't live in an optimal world and Minecraft is only a hobby. If I had the time and patience to devote to Minecraft that I do to work then I'd go for optimal. As I don't have that time, instead I go for fewer updates and make sure they're stable.

Regardless of the timeframe on updates, people who play packs on servers never need to be harassed about mod updates as all that affects them is what the server runs. That is why I take the stance that I do. I don't care if x amount of major versions have happened since the version in a modpack. If that's the modpack a server is running then that's what the users are using and they shouldn't be harassed for it.

I honestly don't think anyone should have an easy time skipping major versions of your mods for any length of time. Ever. For any reason. Those come out rarely enough that you can test just fine in a couple of weeks, and if you can't test the 6-10 mods in that timeframe once every two-to-four months? You really do not have the time to devote to a modpack as a maintainer. Catering to the tail like that is like trying to fix stupid. You're never going to make everyone happy, and in doing so you're just going to piss off either everyone else (like the initial incarnation of the checker) or the creator; generally by defeating the point of the creation's inception or making them waste an inordinate amount of time. If this update checker can allow Monster to happen again, it has defeated the reason it was conceived in the first place. ALWAYS KEEP MONSTER IN MIND! That is the inciting incident and Reika is STILL getting bug reports from Monster's recommended version, which is v19b (1.1.2 which is STILL not recommended is using 23b... not 25z. There are a lot of things I thank FTB for, things I praise them for. Keeping their packs reasonably up to date is not one of them.). That is stupid and unacceptable, nobody should be using v19 anymore. There's a grace period, and then there's Monster.

If people want to run an older version, I see no reason they should not be allowed to. Especially if the pack it's in is stable. Again I'll repeat the 'if it ain't broke, don't fix it' mantra. That is a paramount concept in any systems administration. Unless an update is patching an issue that specifically concerns you, or adds functionality you want/need, you often don't grab that update as every update could introduce new issues.

As for your statement of testing 6-10 mods in a 2-4 month period? Have you played on any sizable modpack? In a two week period alone you're often looking at at least 20 mod updates, if not more. And each one requires individual testing as you load them in one at a time for troubleshooting and configuration reasons. I'd say that if everything goes optimal and has no issues, and you have a fast compy, you're looking at at least an hour *just* installing the updates and making sure the configs didn't get borked in the process. That doesn't even count in time to test new functionality or test server-side as well, let alone if any unexpected issues arise.

Packs that don't update weekly, or even monthly, aren't the tail. They're the norm. The fast-updating ones are either early in their inception or are 'LTS' packs administrated by groups like FTB, RR, and those lovely Phoenix peeps or individuals with crazy amounts of time on their hands like the talented Jaded. This isn't a 'tail' situation. This is a bell curve situation. The current and fast updating packs? They're at the upper end. Not at the peak.

As for Monster? That's an old pack at this point. And yes, people will still be running it. Until the people on the servers decide to migrate to a new pack then they will likely still be running it. Until FTB no longer hosts it, that is, forcing the admins to self-host. At that point they're honestly more likely to move onto a new pack than to update it themselves either as it's a hell of a lot easier to point 'standard-user' players to where a pack is hosted on an easy launcher than it is to modify and host it themselves in a manner that is likely a lot less user friendly. Remember that the standard user isn't going to be self-updating mods. That's why launchers like FTB and Curse exist.

If there are version checkers that can be disabled then Monster could happen again. That is true. If there is one that can't be disabled then it's not likely to happen again, but not for the reason you might expect. It won't happen again because few, if any, modpack creators will even deign to include the mod in their packs anymore.

You can't fix stupid, and trying to will only incite people.

THANK YOU. This is the point I have been trying (and apparently failing) to drive home. I am saving this page to disk just so I can refer to it and quote it as needed.

I can say the same of everything I've said to you and others, Reika. What you're arguing isn't 'driving home' to some as those individuals see the inherent flaws and oversights of the simplistic view you hold. Things really aren't that simple.

So grant us the same courtesy. Maintaining mod packs is not our job either so stop trying to force us to do busy work. Especially if it's to cover for low quality code.

Well that was uncalled for. Reika is actually a pretty damn good coder. No matter how good you are, bugs will happen. It's an inevitability. Period. Don't bash modders for bugs if they actually try to fix them when they're found. That isn't cool.

 

[GreenZombie]

I didn't say I expected high quality code. I made it quite clear I understand that modding is a hobby.

And yes. Bugs are inevitable. But software quality can be judged on the frequency of critical patches. So it is not I, but the author, who calls into question the code quality if every update is marked mandatory.

 

[Kotaro]

I didn't say I expected high quality code. I made it quite clear I understand that modding is a hobby.

And yes. Bugs are inevitable. But software quality can be judged on the frequency of critical patches. So it is not I, but the author, who calls into question the code quality if every update is marked mandatory.

Not everyone is the same, and you can't judge the quality of code based on new releases. By that logic, someone who does only major releases is a lot better than someone who releases a ton of updates. It really comes down to personal style. At my job, we have an app that's modified every single day because that is how the coder works, and they're pretty good at what they do. I have a friend who also releases updates to his apps once a month or so and is a terrible coder (everything is in a dictionary).You can't equate personal ethics and choices to the quality of work directly.

Plus, and I admit I might be misunderstanding, but Reika did say that major releases are the ones that are absolutely mandatory.

 

[Reika]

I am going to restate a point that has still not been responded to or even acknowledged:

Regardless of whether the majority of packs update in a reasonable time frame or not, if a pack is not updating reasonably quickly it is utterly ineligible for support. So, with that in mind, these packs have two options. Be totally barred from bug reporting, or update.

Now, if what you say is true in that most packs do not update even every month, then if the version checking is not doing its job, I am basically forced to say that packs in general are ineligible for support, because the majority will be.

It says the release date besides the files. A simple BufferedReader should do it.

It is not that simple. Yes, it says it in the browser window, but the content I will get back reading the page directly will be unreadable HTML/PHP/JS garbage.

 

[CoolSquid]

It is not that simple. Yes, it says it in the browser window, but the content I will get back reading the page directly will be unreadable HTML/PHP/JS garbage.

I know. I use it for my own version checker.

 

[ljfa]

Now, if what you say is true in that most packs do not update even every month, then if the version checking is not doing its job, I am basically forced to say that packs in general are ineligible for support, because the majority will be.

It might be interesting to gather some data about patch intervals of mods or packs. In this case you could maybe avoid leaving behind the majority.

 

[RedBoss]

.

If there are version checkers that can be disabled then Monster could happen again. That is true. If there is one that can't be disabled then it's not likely to happen again, but not for the reason you might expect. It won't happen again because few, if any, modpack creators will even deign to include the mod in their packs anymore.

You can't fix stupid, and trying to will only incite people.



I can say the same of everything I've said to you and others, Reika. What you're arguing isn't 'driving home' to some as those individuals see the inherent flaws and oversights of the simplistic view you hold. Things really aren't that simple.

This.

My only point in following this thread is because I wanted to express that this entire strategy was probably going to lead to less people using the mods. I don't know if that's even a concern at this point. But frankly, this whole situation will be a point of influence going forward. People stop using mods all the time. Some stop mainly due to nerfs. Yes there will be users that don't, but this isn't even about mod content, its about trying to control behavior.

You can't control the behavior of others. Attempting to do so will lead to stress.

Also, just out of curiosity, what's the expected result of these enhanced notifications anyway? Is there some contract formed if people ignore them? If you you as a Dev decide not to offer support on versions X amount of time ago, then declare that on your MCF page and leave it alone. No need to rub noses in it.

I guess I can see the frustrations, but I can also see how this whole thing would invite more stress than its worth. I say this out of concern because I honestly don't use any of your mods Reika. I just like your funny posts and people whom I respect, really like your mods.

I've been in sales of some form most of my life. I know when a policy, no matter how well intentioned, can lead to disaster. I know what its like to talk to people who don't even know how much they don't know. I just hope going forward that whatever you decide to do, will lead to less stress. I wish you well and good luck.

 

[ljfa]

It's intended as a means to reduce stress for Reika, as he doesn't want to have to deal with as many reports for already fixed bugs and other stuff. Some of them from people who aren't even aware that they're using an outdated version.

 

[Reika]

It's intended as a means to reduce stress for Reika, as he doesn't want to have to deal with as many reports for already fixed bugs and other stuff. Some of them from people who aren't even aware that they're using an outdated version.

Correction: Most are from people who have no idea there have been any updates in the...what, year since Monster last updated? Many are not even aware my mods are updated to 1.7.10.

 

[keybounce]

... (Wow, is this the Illudium Q-36 earth shattering kaboom? :0)

I will try to avoid my normal Wall-o-text here.

1. As a user: any update checker that displays a line of text in my chat log will fit right in with a bunch of other update checkers I have. No problem.

Any update checker that does anything more intrusive is a no-no.

2. For anything: Any update checker that only displays its message once per update is worthless. It will be ignored / missed / forgotten the first time. The message has to come back.

3. For servers: Any server may be using a specific version of a mod, and want to keep that version.

Spoiler

A specific example: a modpack using 1.4.7, and mystcraft 0.9.5, specifically to permit Custom Ore Generation to interact with Mystcraft symbols. For that server, I could not update mystcraft to 0.10.0 -- not only did it break aspects of Mystcraft (mystcraft did not get that update finished until 0.10.5, and it was not balanced right until 0.10.7 -- and that's 1.6.4), it broke the ability of COG to detect symbols and alter worldgen.

Another example: My Jampack submission for 1.6.4 was focused on what was at the time, a tech tree bypass. Had I gotten to the point of writing the quests to include RotaryCraft, then I would have had to say "This modpack will NOT update, because the tech bypass that has been removed is the point of this pack". As it turned out, I did not have the time to get that far.

In 1.7.10, there's a recent change to RoC: you can no longer use industrial coils in the early game. They require a significant amount of power before they can be charged, so they are no longer usable as early batteries or "pulse generators". If I had gotten quests written that used that behavior?

Instead, I've decided to make "charging a coil" the end goal. I've also asked Reika to add in low-level coils usable in the early game, with restrictions. So what do I do to my pack/quests if that request is added in v7?

Forge will, on server startup, issue warnings, and tell you to type /fml continue or /fml abort, or add a flag to the startup. That's not a bad idea -- /dragon continue, /dragon abort, or a flag to tell dragon API not to complain about the out of date mods.

4. For any problems, a line can be at the top of the crash reports saying "Update checker disabled" or "Out of date mods", along with "-- Do NOT report this to the forums". That should stop people from ... oh, never mind this one.

5. There are at least two existing update checker mods right now. Please do *NOT* make me install COFH_Core to get another update checker, unless you make sure that COFH_Core does *NOTHING* to my play by default.

Spoiler

As an aside, I am looking at AppleCore / Hunger Overhaul. I wanted a way to use AppleCore to make changes (it's a mod that is not intended to be exposed to end users, but used by other mods). I was told that the features I wanted were added to apple core to support hunger overhaul, and that I could get those features from HO. I was also told that HO was intended to be the user-facing interface to apple core.

All good? Sure. Except that it turned out that HO could not be configured to make no changes at all, and the default config had many changes.

As far as I know, the issue is still open -- there is no way to make H.O. do nothing at all, so you can use it as a way to interface with applecore, and the config file changes needed to minimize the changes that H.O. does make is still not provided with the mod.

 

[Reika]

Forge will, on server startup, issue warnings, and tell you to type /fml continue or /fml abort, or add a flag to the startup. That's not a bad idea -- /dragon continue, /dragon abort, or a flag to tell dragon API not to complain about the out of date mods.

Something tells me that if a closeable popup is unacceptable, so is this.

 

[TomeWyrm]

@Reika it's a stupid point that's why.

There are a lot of people still playing mods for 1.4.7 never mind 1.5.2 or more recent versions of minecraft.

The issue with Monster is NOT that those people are using a version from 1.6.4. The issue with monster is that they're using an OLD version of RoC from 1.6.4.

I don't care if x amount of major versions have happened since the version in a modpack. If that's the modpack a server is running then that's what the users are using and they shouldn't be harassed for it.

Right there I'm going to have to disagree with you. Forever. There's a reasonable grace period that I am perfectly willing to accept, but there are no excuses for running 19b a year later when 25z is both out and stated to be the final 1.6 update. None. In keybounce's cases? That's where you ask the mod author for support. Which he has done with CoG and RoC. That is what startup notification mods are for (I had one a while back, can't remember what it is called)

If you as pack maker can flip a switch that literally 100% permanently turns the update notification off for users? The update checker is no longer doing its originally stated purpose, its raison d'être, the whole reason it was made in the first place. That's precisely what FTB would have done for Monster, and that would not have stopped Monster from happening. I'm going to re-state. Always keep Monster in mind when talking about update checking in regards to Reika's mods. I pop in and catch up from time to time and even I am sick and tired of the complaints that you can't chain hydrokinetics, that magnetostatics don't work, that the tokamak doesn't exist, wondering why the tokamak won't work (it probably needs LN2, and they didn't even know it used to take lubricant), that bedrock can't be obtained with the borer anymore, etc. etc. etc. You can't fix stupid, but when 90% (probably more) of your "bug" reports are fixed by saying "You're using an old version, I fixed that bug 11 months ago"? There's a problem and it's not with the mod or its author.

As for your statement of testing 6-10 mods in a 2-4 month period? Have you played on any sizable modpack? In a two week period alone you're often looking at at least 20 mod updates, if not more. And each one requires individual testing as you load them in one at a time for troubleshooting and configuration reasons. I'd say that if everything goes optimal and has no issues, and you have a fast compy, you're looking at at least an hour *just* installing the updates and making sure the configs didn't get borked in the process. That doesn't even count in time to test new functionality or test server-side as well, let alone if any unexpected issues arise.

I currently play and test/build a THREE HUNDRED PLUS MOD modpack. Don't talk to me about updates being a pain. I get 10 updates (on average) a DAY. Testing boot on server/client and downloading the updates takes less than 30 minutes (even if I wait and let half the pack update), and most of those are waiting for a full boot 4-or-so times. Checking for config changes is what file diff applications are for. If you're using a typical 100-150 mod pack, and it's taking an hour? You've got some pretty big inefficiencies in your process somewhere, or your testing computer is rather underwhelming. Testing for the major issues I look for takes maybe a half hour on top of that. Things like world generator ****ups from added biomes, etc. I use the time while booting up to look at the changelogs, and accept that something is probably going to get through. Striving for perfection is a waste of time, in my opinion.

It will come back repeatedly if the pack is abandoned. That is the POINT of this. Monster was abandoned and STILL causes regular headaches for Reika and his thread.

Nothing that stops/pauses the server boot will ever be acceptable unless it's for critical issues that will break your world, Reika is exactly right.

Oh you know what screw it. I'm done with this disable argument! This will never be permanently disable-able. If that causes people to leave then THEY WERE THE PROBLEM. If you can actually bring up an issue with it like "Two weeks is too short a timeframe" then we might be able to go somewhere. As-is, that argument is a broken record. Please turn off the power to your turntable.

I will report people that bring up permanent disable as an issue from this point forth. I am being deadly serious here. A peace had been reached, and then this crap came back up. I'm regretting even commenting on a thread that I STARTED because my comment apparently provided fuel for this frankly asinine repetitive argument. If you have actual concerns that maybe the time is too short and can provide alternative timeframes with actual examples that aren't completely hypothetical? Bring them up, you're the kind of person that this thing needs. People that brought up actual issues are why this currently is supposed to not nag users every reboot (the implementation had flaws. That happens), why the notification is removable, and why I kept at this discussion instead of reporting it to the mods. I could see the merits of the other side. At this point people bringing up the "turn it off forever" argument are just inciting argument for the sake of argument, or haven't actually been paying attention.

I'm editing the original post to reflect this.

Edit: oh right. Curseforge. There should be a method to get the date of upload of a mod version without having to parse the page. I don't know what it is, but I'll try and find out, or find someone that knows.