The difference is that Mojang can filter old bugs and has a team paid developers to attend to reporting.
Reika's Update Checker
- Thread starter TomeWyrm
- 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
- Status
I can't tell. I stopped reporting stuff to them long ago. It either goes completely ignored or closed with zero resolution.
That does nothing to prove your point, as it provides even more evidence that Mojang suffers little if at all from the problem of people reporting old bugs.
Also, my point about modpacks is still going unanswered, despite being mentioned in nearly every post, and I know people are reading this thread because of the replies and "likes" appearing, so I am going to put it in the form of a poll:
Question: Of the two options, which is preferable?
- The update checker as currently agreed to: the closeable popup that can be disabled until the next major version with a command, which will have a config to make it so that only the pack maker can see it, until the pack is determined to have been abandoned (or at least has ceased being updated)
- Modpacks get no support at all. Period. End of story.
Any replies that dispute the merits of the version checker yet that do not pick an answer, or at the very least address the question, will be taken as intentionally skipping the question to avoid having to answer it.
Additionally, if you are going to dispute the merits of the "abandonment" timeout, then you must address the question of "what about packs that stop being maintained without having been planned to do so". Like above, failing to acknowledge the question will be seen as intentionally skipping it.
Apologies for all the bold, but I fail to see how to make this more clear.
Last edited:
This is some pretty faulty logic. Could you imagine if everyone shared the same idea? Nothing would ever be reported.
It's easy to assume that if you hear nothing, that you're being ignored. With how large the playerbase is for Minecraft, could you imagine the people and time required to respond to every single one of them?
Seeing if there's a resolution to the reported bug is fairly easy since they release a change log for every update. So they don't need to respond to a bug report to prove if it's being solved or ignored.
Option two. It's excessively rare that modpacks have the newest versions anyways and when I encounter an issue with any of my modpacks the first thing I do is test again with the newer mod versions in a private instance to see if it still persists. That's a step that should always be taken before escalating issues to modmakers anyways, honestly.
I've been avoiding this thread, but since I've been quoted I feel obliged to clarify my position. I apologize if anything I say has already been said, but I'm not going to take the time to read 8 pages of arguing.
Strictly from a developers perspective, an update checker is always a good thing. Practically all of their time associated with the mod is spent either reading bug reports or fixing them. I'm thoroughly impressed with someone like Reika who spends so much time doing that and still manages to add lots of new content. They have little incentive, aside from user pressure which I'll talk about below, to encourage people to play older versions of their mods. As Reika says, he gets lots of bug reports and complaints about old versions. Which, for obvious reasons, he ends up wasting lots of time trying to fix. So the update checker helps the dev.
Now from the users perspective. In this context there are three types of users. First, the average player. Whether playing an established modpack in single player, or playing on either a custom pack or an established pack on multiplayer, he has very little incentive to want to update a mod. In that first case, they are unlikely to want to spend the time or trouble to modify the established pack. Either they are a casual user who doesn't the expertise to find the correct download, replace the correct file, debug any potential conflicts and crashes, or simply doesn't want to spend the time. In the second and third cases, they don't have the control to update, since they don't run the server. In the fourth potential case, that of it being a custom modpack in singleplayer, they do control the modpack and slight incentive to update, more on the slight bit later.
Still from the users perspective, but now as a server owner. If they are running an established pack, they cannot manually update any mods. Doing so would require users to also manually update, which turns off the majority of users and defeats the point of having a unified pack. An update checker could provide incentive to update to a newer version of the pack, but again, more on that later. Second, if they are running their own custom pack, an update checker would potentially be helpful for them to see, if they were unaware of the update and were experiencing bugs that were fixed.
Lastly, from the pack makers perspective. Ideally, the pack maker knows as soon as an update is out. I can't speak for the Monster days, since I wasn't very involved in pack making back then, but now there's a constant stream of comments in our internal chats about mods updating. We know when a mod updates, what it fixes, what the potential conflicts are, oftentimes from the mod dev before it even comes out. As an aside, curseforge really helps with this. It lets you follow mods and receive an email when they update. It's an unobtrusive, opt-in system that's extremely useful for pack devs. Back to the topic, even though we know when an update comes out, we oftentimes can't update promptly. First, we have a release cycle. We release a non-recommended version, then usually a couple patches as we find bugs. Once the version has been stable for a week, we move it to recommended. The process from first release to recommended usually takes 2 weeks, but can run longer. That whole time, there are lots of people playing the previous recommended version, which itself was already 2 weeks out of date at the beginning, and is now 4 weeks out of date. This is a bit of an extreme example, FTB is large enough to have big enough bug trackers and user bases that we can justifiably wait that long, since not only do we know we can find most of the bugs, but the potential consequences of having to release a patch for a game breaking bug outside the normal release cycle. Like I said, a bit of an extreme example, most pack devs won't wait nearly that long. Potentially all during that time, mods would be informing users of an available update, which due to other factors, the pack devs cannot update to yet. This is not only potentially confusing, but can reflect unfairly on the pack author.
So we've established there are groups of people who could benefit from knowing an update is available, but there are also large groups of people who can have no benefit from knowing that, and in fact can be considerably annoyed by having it thrown in their faces all the time via an update checker. I have two more points to make, one of which is what a mod author can do to address the first group while not annoying the second, but first, a few comments on incentive to update.
Update checkers serve two purposes. The first, and obvious, is to let a user know an update is available. This can be useful both so the user knows to update, when applicable, but also to help prevent them from submitting bug reports for out of date versions. The checker's purpose should end there, but in a lot of cases it doesn't. If it continually prompts the user, it's providing incentive in and of itself. IE, annoying the user into submission, this is the second purpose. This is a universal problem in the software world, that companies have learned to avoid. It almost universally lends a bad reputation, for a non-obvious reason to most devs. That is, most people who have your software installed don't actually use it. Bolded that part because it's really important. This might seem a bit presumptuous on my part, but it's nonetheless true. A big modpack has a lot of content. I could play for weeks and still not touch half the mods. In fact, most users end up doing something like that, though it would be a different half each time. I likely don't care in the slightest about updating a mod in that half. It's bugs don't affect me, new content doesn't really interest me. Prompting me to update it does nothing more than, as I said, annoying me into submission.
On to my last point now, what a mod author can do about it. If your intention is to annoy the user in to updating, I can't help you. If instead, you only want to make sure people know an update is available, I have a few suggestions. The most obvious is to go the path of other mods. Have the checker on by default, but allow someone a config option to permanently disable it. Since I can understand you being opposed to that, here are a few other ideas. Only display the update to moderators on a server and everyone in single player. Only display the message if the version is a certain amount of time out of date, ie, a few weeks. Only display the message if the user is on a non-recommended version.
For bug reports, I would highly recommend a robust tracking and reporting software. Something that aggregates bug reports serves two exceedingly useful functions. First, it gives each bug a single place for gathering information, you can mark new reports as duplicates and refer people to the main report, instead of relying on people reading many pages of a thread, often on topics unrelated to the bug. Second, it gives closure, instead of just saying a bug has been fixed, you can point people to the issue, giving all the details of the bug, when it was fixed, what version they need to update to to get the fix, etc.
Again, I apologize if any of this has already been talked about, or even implemented by Reika. I also tried to write it as a general comment on update checkers and intentionally not specifically directed at Reika.
Tl;DR I have yet to find an update checker that actually serves it's intended purpose of informing only relevant people of useful update information. Both learning about updates and addressing bug reports for out of date versions should be addressed in alternate ways.
Edit: Started writing this post about 3 hours ago, so I'll also address this question now.
Strictly from a developers perspective, an update checker is always a good thing. Practically all of their time associated with the mod is spent either reading bug reports or fixing them. I'm thoroughly impressed with someone like Reika who spends so much time doing that and still manages to add lots of new content. They have little incentive, aside from user pressure which I'll talk about below, to encourage people to play older versions of their mods. As Reika says, he gets lots of bug reports and complaints about old versions. Which, for obvious reasons, he ends up wasting lots of time trying to fix. So the update checker helps the dev.
Now from the users perspective. In this context there are three types of users. First, the average player. Whether playing an established modpack in single player, or playing on either a custom pack or an established pack on multiplayer, he has very little incentive to want to update a mod. In that first case, they are unlikely to want to spend the time or trouble to modify the established pack. Either they are a casual user who doesn't the expertise to find the correct download, replace the correct file, debug any potential conflicts and crashes, or simply doesn't want to spend the time. In the second and third cases, they don't have the control to update, since they don't run the server. In the fourth potential case, that of it being a custom modpack in singleplayer, they do control the modpack and slight incentive to update, more on the slight bit later.
Still from the users perspective, but now as a server owner. If they are running an established pack, they cannot manually update any mods. Doing so would require users to also manually update, which turns off the majority of users and defeats the point of having a unified pack. An update checker could provide incentive to update to a newer version of the pack, but again, more on that later. Second, if they are running their own custom pack, an update checker would potentially be helpful for them to see, if they were unaware of the update and were experiencing bugs that were fixed.
Lastly, from the pack makers perspective. Ideally, the pack maker knows as soon as an update is out. I can't speak for the Monster days, since I wasn't very involved in pack making back then, but now there's a constant stream of comments in our internal chats about mods updating. We know when a mod updates, what it fixes, what the potential conflicts are, oftentimes from the mod dev before it even comes out. As an aside, curseforge really helps with this. It lets you follow mods and receive an email when they update. It's an unobtrusive, opt-in system that's extremely useful for pack devs. Back to the topic, even though we know when an update comes out, we oftentimes can't update promptly. First, we have a release cycle. We release a non-recommended version, then usually a couple patches as we find bugs. Once the version has been stable for a week, we move it to recommended. The process from first release to recommended usually takes 2 weeks, but can run longer. That whole time, there are lots of people playing the previous recommended version, which itself was already 2 weeks out of date at the beginning, and is now 4 weeks out of date. This is a bit of an extreme example, FTB is large enough to have big enough bug trackers and user bases that we can justifiably wait that long, since not only do we know we can find most of the bugs, but the potential consequences of having to release a patch for a game breaking bug outside the normal release cycle. Like I said, a bit of an extreme example, most pack devs won't wait nearly that long. Potentially all during that time, mods would be informing users of an available update, which due to other factors, the pack devs cannot update to yet. This is not only potentially confusing, but can reflect unfairly on the pack author.
So we've established there are groups of people who could benefit from knowing an update is available, but there are also large groups of people who can have no benefit from knowing that, and in fact can be considerably annoyed by having it thrown in their faces all the time via an update checker. I have two more points to make, one of which is what a mod author can do to address the first group while not annoying the second, but first, a few comments on incentive to update.
Update checkers serve two purposes. The first, and obvious, is to let a user know an update is available. This can be useful both so the user knows to update, when applicable, but also to help prevent them from submitting bug reports for out of date versions. The checker's purpose should end there, but in a lot of cases it doesn't. If it continually prompts the user, it's providing incentive in and of itself. IE, annoying the user into submission, this is the second purpose. This is a universal problem in the software world, that companies have learned to avoid. It almost universally lends a bad reputation, for a non-obvious reason to most devs. That is, most people who have your software installed don't actually use it. Bolded that part because it's really important. This might seem a bit presumptuous on my part, but it's nonetheless true. A big modpack has a lot of content. I could play for weeks and still not touch half the mods. In fact, most users end up doing something like that, though it would be a different half each time. I likely don't care in the slightest about updating a mod in that half. It's bugs don't affect me, new content doesn't really interest me. Prompting me to update it does nothing more than, as I said, annoying me into submission.
On to my last point now, what a mod author can do about it. If your intention is to annoy the user in to updating, I can't help you. If instead, you only want to make sure people know an update is available, I have a few suggestions. The most obvious is to go the path of other mods. Have the checker on by default, but allow someone a config option to permanently disable it. Since I can understand you being opposed to that, here are a few other ideas. Only display the update to moderators on a server and everyone in single player. Only display the message if the version is a certain amount of time out of date, ie, a few weeks. Only display the message if the user is on a non-recommended version.
For bug reports, I would highly recommend a robust tracking and reporting software. Something that aggregates bug reports serves two exceedingly useful functions. First, it gives each bug a single place for gathering information, you can mark new reports as duplicates and refer people to the main report, instead of relying on people reading many pages of a thread, often on topics unrelated to the bug. Second, it gives closure, instead of just saying a bug has been fixed, you can point people to the issue, giving all the details of the bug, when it was fixed, what version they need to update to to get the fix, etc.
Again, I apologize if any of this has already been talked about, or even implemented by Reika. I also tried to write it as a general comment on update checkers and intentionally not specifically directed at Reika.
Tl;DR I have yet to find an update checker that actually serves it's intended purpose of informing only relevant people of useful update information. Both learning about updates and addressing bug reports for out of date versions should be addressed in alternate ways.
Edit: Started writing this post about 3 hours ago, so I'll also address this question now.
2, always 2. The burden of responsibility should ALWAYS be on the modpack author to address and replicate bugs before reporting them to the mod author. I would contend this also applies to your third party modifications policy, but that's another topic.
Last edited:
In reply to the above post which I have deleted. I'm reading this thread now. Personal attacks will not be tolerated. Keep it civil.
I will admit people's selection of option two takes me by very large surprise.
Now,
A dedicated "form" system via Google Forms was in the works, but was unfortunately cancelled due to it only providing the results in an Analytics format which is worthless for me.
I also got some heat from users who saw the system as too impersonal: "If you can't even treat us like people and deal with us directly, you're telling us we're not worth your time. So you're not worth mine. Uninstalling your mods now."
Now,
I am willing and able to implement (A) and (B) - and they are sufficient to me to justify still providing support to packs; B sort of already exists. (C) is sort of nonapplicable because all my updates turn into the only recommended version, though it is true some updates (like going from v19 to v20 or v24 to v25z for 1.6.4) are a higher priority due to specific fixes.
I have been working on this so far without luck. I am hesitant to use services like GitHub because they lack the moderation forums do and thus actually have far more - my estimates peg it at over ten times - in the way of PEBKACs and hate mail. The 24 hour window my RC issue tracker opened saw the following issues:
- Machine doesn't work - insufficient power
- Something broke - no mention of issue
- What the hell? - hate mail regarding griefing capability of Borer
- Are you for real? - hate mail regarding some things I said on a forum (regarding not approving of plug and play design)
- How elitist can you be? - similar to the above
- Is mod for 1.8? - User asking mod to be updated to 1.8
- My stuff broke - Nuclear reactor meltdown due to lack of water
- Why does your stuff lag so much? - User spammed 370 hydrokinetics
- Can't power machines - user tried RF conduits to power bedrock breaker
- Can't work ore doubler - Extractor not working due to only meeting stage 1 requirements
- What the f***? - Hate mail regarding anti-monetization rules
- You will be sorry - Threats regarding anti-monetization rules
- Tutorial is wrong? - User using outdated tutorial with newer mod versions
- Help please! - User had no idea how to do basic math
- Can I make copy? - User asked to make custom version of RC for friends
- What the hell is your problem - Hate mail regarding some statements I made about 50% of users being unable to use RC
- f*** you! - Hate mail regarding user's inability to progress beyond the DC engine
- f***ing f*g - Hate mail of personal nature
- f***ing furries ruining everything - Hate mail of personal nature
- Weird bug with rendering - Actual bug regarding pipe rendering
- I crashed - ID conflict
- Why don't your mods work? - Installation error (user using 1.6 DragonAPI with 1.7 mod)
- Who the hell pissed in your cereal? - Hate mail regarding a political statement I made
- This is all your fault! - User was upset that a coil exploded and took out some of their base
- Can't you do anything right? - Hate mail regarding a bug I fixed in v23
- WTF is up with your mods lagging? - Lag complaint about machines, no justification, screenshots, or evidence provided
- Who taught you how to code? - Hate mail regarding my coding style?
- So is this socially acceptable now? - Hate mail of a personal nature
- Does everyone need to know you suck d**k? - Hate mail of a personal nature
- I got crash! - NullPointer in BiomesOPlenty
- You made a big mistake - Threats regarding my anti-monetization code
- Who told you you could do this? - Hate mail regarding my anti-monetization code
- PLEASE HELP - Incomprehensible babbling
- Why does it crash? - No crash log provided
- Is a bug? - Actual bug regarding a machine not working
- Is some what to protect or? - Asking for way to protect player from VDG bolts, added in v16
- F***ing furry - Hate mail of a personal nature
- Death to f*gs! - Hate mail of a personal nature
- Why did you corrupt my save? - Accusations of world corruption; actually an ID conflict
- Try that in a real world - Claims I was beholden to real-world coding styles in the mods, and that I should obey customer service practices
- Your lucky your anomynous [sic] - Statements that if they knew who I was they would harm me
- Is fixed yet? - Demand for a bugfix for a bug I never even heard of before
- 1.7 please - Asking for 1.7 mod to be ported to 1.7
- Modding team? - Request for being on a modding team
- Cool idea - half-baked idea for a Star wars mod
- WHAT DID YOU DO - screenshot of a hole in a house without context; User error, likely via industrial coil assumed
- LOL - Hate mail regarding my diction
- You call yourself an engineer? - Hate mail regarding my engineering skills
- Why do you hate us? - Accusations I deliberately shut out 95% of the modding community
- Can't stop me - Claims he is making an improved RC "without lag or bugs". Still waiting.
- Are you thaumcraft? - Asking if I am Azanor
- Fix please - RailCraft hidden block crash
- HELP - Possible bug, but grammar too poor to parse
- gran problema - bug report in Spanish(?)
- Fix now - Demand for a fixed copy of v16
- What now? - Asking how to rotate a shaft
- You will fix - Demand for a hotfix for an issue I fixed in v20
- laggy mod - Hate mail and lag accusation
- s****y mod - Hate mail
- Where for go? - User asking what happened to a MeteorCraft meteor that disappeared (likely entered loaded chunk)
- I hate you - Hate mail regarding user's inability to understand the mod
- Ugly! - Hate mail regarding GeoStrata
- Pointless much - Hate mail regarding DyeTrees
- So what's with the OP - Accusations of overpoweredness, demand for config to turn off Extractor
- Not working - RF conduit attempted as power supply to Extractor
A dedicated "form" system via Google Forms was in the works, but was unfortunately cancelled due to it only providing the results in an Analytics format which is worthless for me.
I also got some heat from users who saw the system as too impersonal: "If you can't even treat us like people and deal with us directly, you're telling us we're not worth your time. So you're not worth mine. Uninstalling your mods now."
Last edited:
I'd be picking option 1 myself, by the way. Packs are where you're going to get all your bug reports from, disallowing them for support means you're going to piss off even more people than the conservative updaters that don't like the merest possibility of their users being nagged, even if only after some time when the pack is effectively abandoned.
All I see coming out of "no pack support" is something like "What do you mean I can't report bugs from NewPackFromFTB? I have to download your mods into a fresh install? But it's a bug with Mod X and your mod! THE ****?! You are literoly <insert dictator here>". Especially when most of your bug reports come from random users, not pack devs.
All I see coming out of "no pack support" is something like "What do you mean I can't report bugs from NewPackFromFTB? I have to download your mods into a fresh install? But it's a bug with Mod X and your mod! THE ****?! You are literoly <insert dictator here>". Especially when most of your bug reports come from random users, not pack devs.
I would actually say that's one of the major problems here. If you never have fully stable updates, people are always going to be scrambling to keep up to date.
A solution to this is to have two branches on git. One for bugfixes and one for new features. When you fix a bug, you can do it in the bugfix branch, release a new build with only bugfixes and no new features, which have a higher potential to introduce new bugs. Then you can merge the bugfix branch into the dev one. While this is an industry standard for larger projects, it is a fair bit more work, so I can totally understand you not wanting to do something like that. Just a suggestion.
Github lets you easily block and report users. I'm sure you'll see a spike for the first few days until you can block all the obvious haters, but I really think it's worth the effort. Having a centralized conversation for each individual bug makes a huge difference, for the developer, but more importantly for the end user.
You can also just close something as "not a bug" if applicable.
Edit:
I can't speak for other packs, but FTB always requests users submit bug reports to our issue trackers where we will assess and report to mod devs.
That's not how software development works. There will always be updates, because the requirements change and because bugs get fixed.
Most of my haters are "hit and run"; I see very few repeat offendors (and the ones that are are not so much random hate but people trying to spread rumors, which is usually done through platforms like twitter), so I doubt they will ever taper off, making this a full-time job, not to mention depressing.
Yes, but reading through it still takes time.
I know (although is this still maintained for abandoned packs like Monster?), but how many users actually listen? Experience tells me something like half.
Actually it is. It's entirely possible to get a piece of software to a state where bugs are unnoticeable.
Take a look at Thaumcraft. While it might not have quite as many features as Reika's mods, it certainly has a decent percentage. It hasn't updated in 2 months. And yet it's stable and supports a large suite of addons.
I think by stable updates he means without bugs, which is what the bug-fixes branch would be for
That's when it's helpful to delegate. If you have some experienced users, you can give them access to tag and close bug reports. Trying to take on the world by yourself is always going to be hard. I contend it's better than the current situation where people just yell at each other in your thread and you wait for the mods over there to clean it up.
Monster, like all 1.6 packs, are past their support lifecycle. We would ignore bug reports and tell users to play a current and supported pack.
You have to pick a stand and stick with it. Either you still support the 1.6 versions of your mods and address bug reports, or universally ignore them. I don't see why you keep bringing that point up.
- Status