RC/ReC/ElC/CC Policy Changes

Reika

RotaryCraft Dev
FTB Mod Dev
Sep 3, 2013
5,079
5,331
550
Toronto, Canada
sites.google.com
But this is the same argument people make when they're opposed to interracial/gay/etc marriage.
Not even remotely, as the reasons for that usually boil down to either "eew", "my 4000 year old book said so", or "because that is how my parents indoctrinated me". Also, though I doubt you intended to group the two together, you nonetheless have effectively said - especially for any third-party reader who is unfamiliar with your stances or the larger context here - "resisting community control is like being homophobic".


The worst case scenario is that the other version becomes way more popular than your version, and that's not a disaster, that's evolution.
Tell that to the mod developer who just had their mod pulled out from under them because the new version is more popular and they were sufficiently disliked that the community was willing to tolerate (or worse, openly embraced) it. I feel I fit into this category, because I have been repeatedly told as much and have seen hints of it myself. I feel that, for example, were someone to fork RC, turn it into an RF mod, and re-release it - especially if they did so under an Open-Source license - it would both be far more popular than the original (replacing me, because from then on, the "official" RotaryCraft would no longer be under my input or design, and the userbase of the original would eventually dwindle to zero) and that enough people in this community, some in high places, hate me enough that they would embrace and publicly support it.

Much like others have said already, be careful with policies like that. There are extreme consequences to choosing hardline stances, be sure that you're willing to deal with those. Policies like that are reasonably defensible (if generally disliked) for complex mods like Reika's, especially when people repeatedly prove they won't put in the required time/effort into not breaking the mods and then come running to berate him about how his stuff broke when it's actually their fault. But if you're making a more simple mod? People are going to dislike the policy even more.

The other thing is finding volunteers/help is much MUCH easier with open source, getting exposure is MUCH easier with open permissions, and you're also probably not going to upset the community by doing either of those things. Which are all reasonable benefits to consider in the pro/con column. Also you won't be able to use Reika's rules if you upload your mod to curse... well... sorta? If it's a curse pack (which are becoming swiftly more common), you can't restrict people's ability to include your mod. It's in the license agreement.
All of this is true.
 

Pyure

Not Totally Useless
Aug 14, 2013
8,334
7,191
383
Waterloo, Ontario
Not even remotely, as the reasons for that usually boil down to either "eew", "my 4000 year old book said so", or "because that is how my parents indoctrinated me". Also, though I doubt you intended to group the two together, you nonetheless have effectively said - especially for any third-party reader who is unfamiliar with your stances or the larger context here - "resisting community control is like being homophobic".
You straw-manned at the end there, and knee-jerked at the beginning without reading what I was referring to. I directly replied to a single sentence: "One man's improvement is another man's disaster waiting to happen."
There is no scenario where this isn't misleading when it comes to modding except insofar as the other person perceives it as a disaster due to their own personal problems. Therefore my analogy was spot on. Resisting community control is fine. Resisting community control and expecting everyone to be perfectly fine with it is questionable. Resisting community control because of various personal grounds can be foolish and fully deserving of flames.

None of that pertains to you explicitly. Don't take it as such.
Tell that to the mod developer who just had their mod pulled out from under them because the new version is more popular and they were sufficiently disliked that the community was willing to tolerate (or worse, openly embraced) it.
How many times do I need to explain that this is good and fine and wonderful? That's how improvement actually happens.

If I make a mod and someone takes my idea and makes it better, too effing bad for me. That's life. I can either roll with it and be happy that I initiated something that became fantastic and huge, or I can fight it on whatever sketchy grounds I can think of. If people want a mod, and I'm not giving it to them, they have every single right in the universe to make it themselves.

You cannot ethically put a choke-hold on ideas. Half the games we play today wouldn't be possible if this happened. Yes this even applies to seizing 99% of your grand design. I know it can suck as the developer, but the fact of the matter is you don't always help your own case here. Scenario time!

In one scenario, I create a mod with a specific balance curve and expect everyone to play it like that. Someone re-creates my mod with configuration options that allow integration into multiple modpacks...e.g. cfg_wussmode_reactors_cannot_destroy_my_shit_0=1... obviously everyone plays that mod instead.

Alternative scenario, I make my preferred curve the default but allow those configuration options. Suddenly 50% of the people who were thinking of rebuilding my mod no longer have a reason to do so and my own play is completely unaffected. Note I'm allowing there's always a possibility you're going to get boned anyway, but its a numbers game: reducing the chance is important if you're really concerned about keeping the niche to yourself.

Big Reactors is genius for handling the above scenarios so well.
 

Reika

RotaryCraft Dev
FTB Mod Dev
Sep 3, 2013
5,079
5,331
550
Toronto, Canada
sites.google.com
How many times do I need to explain that this is good and fine and wonderful? That's how improvement actually happens.

If I make a mod and someone takes my idea and makes it better, too effing bad for me. That's life. I can either roll with it and be happy that I initiated something that became fantastic and huge, or I can fight it on whatever sketchy grounds I can think of. If people want a mod, and I'm not giving it to them, they have every single right in the universe to make it themselves.
You can make any kind of mod you want. But if you steal another mod's code, assets, or identity (as my example did), that is neither necessary nor ethical. There is a huge difference between "Let's make a mod that others want" and "let's change this mod to be what others want". In my case, there is a huge difference between someone writing the "Easy Shaft Power" or the "Shaft Power or RF" mod and someone taking RotaryCraft, making some changes, rereleasing it under the same or very obviously derivative name, and intending to replace the original.

Big Reactors is genius for handling the above scenarios so well.
Not really. Yes, it has configs, but those are purely numerical. It has no configs to substantially change the design of the mod - even the old turbine explosion config was never implemented due to community backlash.

Indeed, the mod is firmly enough set in its design niche that it regularly gets criticized for the gameplay and design it has.


Also, I forgot to ask:
@SynfulChaot: Did you ever see the revisions I made to point #1 (the first post now contains a link to them)? That was the biggest part of your criticism and I do not recall seeing a response from you. I ask because you are probably the most vocal reasonable critic I have.
 
  • Like
Reactions: Plasmasnake

SynfulChaot

New Member
Jul 29, 2019
599
0
0
Also, I forgot to ask:
@SynfulChaot: Did you ever see the revisions I made to point #1 (the first post now contains a link to them)? That was the biggest part of your criticism and I do not recall seeing a response from you. I ask because you are probably the most vocal reasonable critic I have.

I did and my stance remains the same. It's progress but is still too restrictive and requires jumping through too many hoops. I understand *why* you choose the stances that you do, but they're ones I still can't agree with. And I'm glad that many are still enjoying the changes and that it might open up to more modpacks including your mods, which is a good thing, IMHO.

As for why I didn't respond on that before now, others have said the exact same thing and I didn't think one more voice in that category would change a thing. I've mostly backed off to mostly just watching the discussions enfold instead of being an active participant, which frees me up to do more productive things with my time.
 
  • Like
Reactions: Lethosos and ljfa

Strikingwolf

New Member
Jul 29, 2019
3,709
-26
1
How many times do I need to explain that this is good and fine and wonderful? That's how improvement actually happens.

If I make a mod and someone takes my idea and makes it better, too effing bad for me. That's life. I can either roll with it and be happy that I initiated something that became fantastic and huge, or I can fight it on whatever sketchy grounds I can think of. If people want a mod, and I'm not giving it to them, they have every single right in the universe to make it themselves.

You cannot ethically put a choke-hold on ideas. Half the games we play today wouldn't be possible if this happened. Yes this even applies to seizing 99% of your grand design. I know it can suck as the developer, but the fact of the matter is you don't always help your own case here. Scenario time!

In one scenario, I create a mod with a specific balance curve and expect everyone to play it like that. Someone re-creates my mod with configuration options that allow integration into multiple modpacks...e.g. cfg_wussmode_reactors_cannot_destroy_my_shit_0=1... obviously everyone plays that mod instead.

Alternative scenario, I make my preferred curve the default but allow those configuration options. Suddenly 50% of the people who were thinking of rebuilding my mod no longer have a reason to do so and my own play is completely unaffected. Note I'm allowing there's always a possibility you're going to get boned anyway, but its a numbers game: reducing the chance is important if you're really concerned about keeping the niche to yourself.

Big Reactors is genius for handling the above scenarios so well.
Best Case Scenario: The person re-creating your mod instead forks it and submits a pull request to your mod.
  • You don't get your feet pulled from under you
  • If configs exist for the old mode and the new people can choose the experience they want (in Reika's case RF-compat or no RF)
  • Your ideas are allowed to evolve because of the community
  • Everybody gets a better product
To me that's a win-win situation. And I think that any reasonable person would be willing to let you use their work, hell if yall wanted to yall could develop the seperate "branches" of the mod by yourselves. Each piece could be re-incorporated into the other branch if it fit the design.

However, the majority of people who would want to re-create an RF ReC either aren't reasonable or have personal things against you. Therefore I fully understand why you don't have an open license, but if you had started with one these problems wouldn't exist.

I also realize that the primary concern you have with open licenses is that people will come to you because they broke your mod. Simple solution, license is open, but any modifications mean that you don't have to deal with the bug reports. Then a simple delete button is your friend for any that come in. This obviously can build hate from a lot of people resulting in the worst-case scenario. But the key is that these people would not be the people most likely to re-create your mod. These people are not the kind that would be able to create a mod on a scale as large as yours because they broke your mod with whatever. Therefore their re-creation would probably be below average and never catch on.
Edit: you means Reika in this case :p
 

Pyure

Not Totally Useless
Aug 14, 2013
8,334
7,191
383
Waterloo, Ontario
You can make any kind of mod you want. But if you steal another mod's code, assets, or identity (as my example did), that is neither necessary nor ethical. There is a huge difference between "Let's make a mod that others want" and "let's change this mod to be what others want". In my case, there is a huge difference between someone writing the "Easy Shaft Power" or the "Shaft Power or RF" mod and someone taking RotaryCraft, making some changes, rereleasing it under the same or very obviously derivative name, and intending to replace the original.
Don't expect you to remember but we've discussed this previously. Nobody is talking about stealing assets. Nobody is talking about recycling the name as a total dick move ( I don't consider, say, Blue Power to be a vindictive recycling so much as drawing a correlation)

Blue Power is actually a good example of what I'm discussing here purely in terms of content (not in terms of scenario). It can be horribly upsetting to the hypothetical original dev if that dev is the kind of person who gets upset about that sort of thing. But if the new mod is functionally more appealing to the community, then there was obviously something missing (the features that make the new mod better), and that cloning was a good thing.

Not really. Yes, it has configs, but those are purely numerical. It has no configs to substantially change the design of the mod - even the old turbine explosion config was never implemented due to community backlash.

Indeed, the mod is firmly enough set in its design niche that it regularly gets criticized for the gameplay and design it has.
Uh I've never seen any such criticisms. Ever. And I see ReC criticisms every week. And if there's no significant demand for a feature such as explosions, then its hard to justify devoting time to them. Given E_beef's record, its pretty obvious that if there was a significant demand for explosions, he'd implement them. This is in fact a self-proving scenario: people use that mod in droves because they overwhelmingly (!) prefer it to alternatives. (As a side-note: recall that I've always been a strong proponent of ReC, have initiated my own reactor design threads, and am still active in every single ReC thread that comes up on this forum. I'm no pro-BR, anti-ReC fanboy by any stretch)

And I'm not really talking about "substantially changing" the design of the mod, notwithstanding that its such a ridiculously subjective term that its sort of dumb to argue about it. You'll argue that "explosions" are a significant design element, whereas power output and fuel consumption are somehow lesser? There's zero difference from a game-design perspective. They each justify configuration options. Prerogative of your design goes to you, prerogative of a more flexible implementation goes to other devs.
 
  • Like
Reactions: SynfulChaot

Pyure

Not Totally Useless
Aug 14, 2013
8,334
7,191
383
Waterloo, Ontario
Best Case Scenario: The person re-creating your mod instead forks it and submits a pull request to your mod.
  • You don't get your feet pulled from under you
  • If configs exist for the old mode and the new people can choose the experience they want (in Reika's case RF-compat or no RF)
  • Your ideas are allowed to evolve because of the community
  • Everybody gets a better product
To me that's a win-win situation. And I think that any reasonable person would be willing to let you use their work, hell if yall wanted to yall could develop the seperate "branches" of the mod by yourselves. Each piece could be re-incorporated into the other branch if it fit the design.
I love this reply but only because its so clever :) In a perfect world, this really is the perfect answer. Except the world isn't perfect, and the gatekeeper has no interest in my perfect solutions.

My counter arguments
1) You're leaving up to the original dev to decide what is most popular to the masses. That should be left up to the masses. (This is not about bending to the masses. That's a different discussion and I agree with Reika on the matter in principal.)
2) Why should I develop something that may never have any time whatsoever in the spotlight, if my pull request is rejected?
3) If Reika has already said no to disabling explosions via configs, why would I have any hope of getting a pull request through on the matter?
4) I'm guessing wildly here, so correct me if I'm wrong, but I can't imagine Reika being super excited about people publishing branches.
 

Strikingwolf

New Member
Jul 29, 2019
3,709
-26
1
I love this reply but only because its so clever :) In a perfect world, this really is the perfect answer. Except the world isn't perfect, and the gatekeeper has no interest in my perfect solutions.
Thank you for thinking my reply is clever :p

There will always be friction, but identifying the perfect solution and striving for it is how progress is made ;)
1) You're leaving up to the original dev to decide what is most popular to the masses. That should be left up to the masses. (This is not about bending to the masses.)
2) Why should I develop something that may never have any time whatsoever in the spotlight, if my pull request is reject?
3) If Reika has already said no to disabling explosions via configs, why would I have any hope of getting a pull request through on the matter?
4) I'm guessing wildly here, so correct me if I'm wrong, but I can't imagine Reika being super excited about people publishing branches.
  1. This is actually the hardest to answer. The first solution would be a re-design of the config system to set defaults to what is most widely used and not what the dev's choice is. But because 95% of people don't change defaults you have to be more sneaky. So instead whenever a pull request is initiated with config options you could open a strawpoll to decide defaults. I don't have a better solution unfortunately
  2. In that scenario you can revert to the 2nd scenario, since this is presumably an open license forks are okay. That isn't best-case, but it is an option
  3. This system obviously requires some trust between the person doing the request and the developer. The dev should be able to recognize this is what people want, and that it can be something optional
  4. I didn't mean branches in the traditional sense (hence the quotes). I meant you have a config option for say rf or no. Then one dev could do all the code pertaining to the 'yes' option, and the other could do all the code pertaining to the 'no' option. EDIT: This would usually only be for the biggest and best of the config options. Anything big or different enough it should be developed by two different people
 
  • Like
Reactions: Pyure

Padfoote

Brick Thrower
Forum Moderator
Dec 11, 2013
5,140
5,898
563
And if there's no significant demand for a feature such as explosions, then its hard to justify devoting time to them. Given E_beef's record, its pretty obvious that if there was a significant demand for explosions, he'd implement them.

He is planning on adding explosions, and has been for a while, IIRC.
 

Pyure

Not Totally Useless
Aug 14, 2013
8,334
7,191
383
Waterloo, Ontario
Thank you for thinking my reply is clever :p

There will always be friction, but identifying the perfect solution and striving for it is how progress is made ;)

  1. This is actually the hardest to answer. The first solution would be a re-design of the config system to set defaults to what is most widely used and not what the dev's choice is. But because 95% of people don't change defaults you have to be more sneaky. So instead whenever a pull request is initiated with config options you could open a strawpoll to decide defaults. I don't have a better solution unfortunately
  2. In that scenario you can revert to the 2nd scenario, since this is presumably an open license forks are okay. That isn't best-case, but it is an option
  3. This system obviously requires some trust between the person doing the request and the developer. The dev should be able to recognize this is what people want, and that it can be something optional
  4. I didn't mean branches in the traditional sense (hence the quotes). I meant you have a config option for say rf or no. Then one dev could do all the code pertaining to the 'yes' option, and the other could do all the code pertaining to the 'no' option. EDIT: This would usually only be for the biggest and best of the config options. Anything big or different enough it should be developed by two different people
1) The defaults should be whatever Reika wants them to be. I'm not interested in the people who can't find them or have no interest in changing them. The issue is whether the dev decides to implement the config option itself at all (whether he decides the config would be sufficiently popular)
2. Fair nuff.
3. In the current scenario, the dev explicitly doesn't believe or doesn't care that flexible configs are what people want.
4. I thiiiink I sort of follow what you're saying, but if you've ever tried something similar in a real environment, it gets pretty broken on day2 when Reika starts adding features that belong in both versions :) (Also it wouldn't be super appealing to either dev really)

Also, don't mention the RF thing. You get fair number of sillier kids asking for it but it makes no sense from a design perspective. Even I don't recommend it as a configurable option :p
 

Strikingwolf

New Member
Jul 29, 2019
3,709
-26
1
1) The defaults should be whatever Reika wants them to be. I'm not interested in the people who can't find them or have no interest in changing them. The issue is whether the dev decides to implement the config option itself at all (whether he decides the config would be sufficiently popular)
2. In the current scenario, the dev explicitly doesn't believe or doesn't care that flexible configs are what people want.
3. I thiiiink I sort of follow what you're saying, but if you've ever tried something similar in a real environment, it gets pretty broken on day2 when Reika starts adding features that belong in both versions :) (Also it wouldn't be super appealing to either dev really)
  1. I misinterpreted your counter-argument. I thought you were talking about defaults, not about PRs being pulled. I also agree defaults are best in the hands of devs. I think PRs could be given a voting mechanism where once it reaches a certain amount it is automatically pulled in. The problem is that large numbers of malicious users could force a pr. Therefore a PR would need to be checked before it goes in that it is not malicious. Ofc this puts the power into the author's hands over what is malicious, but it does allow them a little leeway for making sure no one is completely breaking everything and just brute-forcing the vote
  2. I know that. But I'm saying this is the ideal scenario for the community and if all goes well the modder also. If he doesn't care about what the people wants, then let him hold that opinion.
  3. Features that belong in both versions don't have to be co-developed. Something like explosions for machines would stay mostly the same for both cases and thus would not need to be co-developed. As far as not being appealing I beg to differ because there are many projects with many people working on separate modules
Also, don't mention the RF thing. You get fair number of sillier kids asking for it but it makes no sense from a design perspective. Even I don't recommend it as a configurable option :p
Oh I wouldn't do that either, I just think it is a good one to use as an example case :p
 
  • Like
Reactions: Pyure

Reika

RotaryCraft Dev
FTB Mod Dev
Sep 3, 2013
5,079
5,331
550
Toronto, Canada
sites.google.com
I did and my stance remains the same. It's progress but is still too restrictive and requires jumping through too many hoops. I understand *why* you choose the stances that you do, but they're ones I still can't agree with. And I'm glad that many are still enjoying the changes and that it might open up to more modpacks including your mods, which is a good thing, IMHO.
I am curious as to what you would have deemed sufficient, as this new set is heavily based on that long discussion of ours on reddit.

Don't expect you to remember but we've discussed this previously. Nobody is talking about stealing assets. Nobody is talking about recycling the name as a total dick move ( I don't consider, say, Blue Power to be a vindictive recycling so much as drawing a correlation)

Blue Power is actually a good example of what I'm discussing here purely in terms of content (not in terms of scenario). It can be horribly upsetting to the hypothetical original dev if that dev is the kind of person who gets upset about that sort of thing. But if the new mod is functionally more appealing to the community, then there was obviously something missing (the features that make the new mod better), and that cloning was a good thing.
I remember, and as we discussed, BluePower and Project Red are fundamentally different in that they were recreating an abandoned mod. I am talking about if someone made something akin to "ThaumCraft without X", while TC is still active. This is doubly problematic because a good portion of the things people complain about RC do not actually exist - that is, an alleged far-higher-than-normal FPS/TPS impact, and as a result any such derivative may actually be identical, even if claimed to be better.

Uh I've never seen any such criticisms. Ever.
Spend 5 minutes on the subreddit. Or on google.

Hell, I have criticized it myself several times, because I see it to be the most influential in fostering the "how dare you punish the player for doing X"/"Making it not work unless built correctly is too grindy" mentality that is becoming increasingly prevalent, increasingly aggressive, and, judging from some threads I am seeing, is potentially threatening a wholesale community split on the topic of mod design.

And I'm not really talking about "substantially changing" the design of the mod, notwithstanding that its such a ridiculously subjective term that its sort of dumb to argue about it. You'll argue that "explosions" are a significant design element, whereas power output and fuel consumption are somehow lesser? There's zero difference from a game-design perspective. They each justify configuration options. Prerogative of your design goes to you, prerogative of a more flexible implementation goes to other devs.
Numbers mean different things to different mods. To most mods, especially RF mods, the numbers are purely a balance tweak. They have no greater significance. Presumably the defaults were picked with some reasoning in mind, but even that is not guaranteed.
To a mod like RC/ReC, however, the numbers actually do mean something. For one, it is much more deeply involved in the balance process - imagine the techtree problems even a 1.5x multiplier could cause - but more importantly is part of the overarching design principle of realism.

You get fair number of sillier kids asking for it but it makes no sense from a design perspective. Even I don't recommend it as a configurable option :p
It does not make sense from a design perspective no.

However, it is the most common demand I get in terms of stylistic changes, making up more than half of them. On top of that, many people, including Watchful himself, have said that they think that A) an RF version would eclipse the original one and B) if the community desires it then it, as Watchful put it, "should be an indicator of the design the mod should have". That is why I keep bringing it up.

I also realize that the primary concern you have with open licenses is that people will come to you because they broke your mod. Simple solution, license is open, but any modifications mean that you don't have to deal with the bug reports. Then a simple delete button is your friend for any that come in. This obviously can build hate from a lot of people resulting in the worst-case scenario. But the key is that these people would not be the people most likely to re-create your mod. These people are not the kind that would be able to create a mod on a scale as large as yours because they broke your mod with whatever. Therefore their re-creation would probably be below average and never catch on.
Edit: you means Reika in this case :p
They themselves, no. But someone creating it on their behalf (as I can think of a few people who would)? Not as unlikely.

Also, this does not address the other half of my concern. As happened last time I had more open permissions, this does nothing to stop the rumor mill.
 
Last edited:

Strikingwolf

New Member
Jul 29, 2019
3,709
-26
1
They themselves, no. But someone creating it on their behalf (as I can think of a few people who would)? Not as unlikely.
That is addressed at the top in that those problems of people not liking you would most likely not have existed if you had started with an open license. I myself do not know how to form a union of the two approaches if we take a look at the past.
Also, this does not address the other half of my concern. As happened last time I had more open permissions, this does nothing to stop the rumor mill.
That is probably the hardest thing to solve with open permissions. Primarily because of what opposing groups do when they get big

I don't have a solution for it, and I don't know if one exists. I am of course describing in my contributions ideal scenarios. Which given the past and the already existing anger people have toward you would probably not work out without fudging the details a bit
 

Reika

RotaryCraft Dev
FTB Mod Dev
Sep 3, 2013
5,079
5,331
550
Toronto, Canada
sites.google.com
That is addressed at the top in that those problems of people not liking you would most likely not have existed if you had started with an open license. I myself do not know how to form a union of the two approaches if we take a look at the past.
Even if I accept this at face value, the fact remains the past is set and that I did not start with (well, I did start with, but did not continue with) an open license. Any solution or advice I am to seriously consider needs to be built with that in mind, and any solution in the "would have worked if the past was different" category is neither valid nor something I should be pressured into.
 

Strikingwolf

New Member
Jul 29, 2019
3,709
-26
1
Even if I accept this at face value, the fact remains the past is set and that I did not start with (well, I did start with, but did not continue with) an open license. Any solution or advice I am to seriously consider needs to be built with that in mind, and any solution in the "would have worked if the past was different" category is neither valid nor something I should be pressured into.
I'm not saying you should do this, nor should you be pressured into anything, that would just lead to bad blood. I'm saying this is the ideal solution. If a pragmatic solution comes up that can approximate this one that would be what you should go for. This is a skeleton of a system that needs improvement even to be ideal, and needs to be toned down to account for your past.
 

SynfulChaot

New Member
Jul 29, 2019
599
0
0
I did and my stance remains the same. It's progress but is still too restrictive and requires jumping through too many hoops. I understand *why* you choose the stances that you do, but they're ones I still can't agree with. And I'm glad that many are still enjoying the changes and that it might open up to more modpacks including your mods, which is a good thing, IMHO.
I am curious as to what you would have deemed sufficient, as this new set is heavily based on that long discussion of ours on reddit.

Open permissions.

If I need to jump through hoops and get express permission to use and/or modify a mod then I'll be much less likely to consider using it, often to the point of not considering it at all, regardless of how wonderful said mod may be. Doubly so when there are so many great alternatives that offer me no hassle to use and tweak to my heart's delight.

Does this mean I don't respect the careful balance the original mod dev placed in their mod? No. I really do. But a modpack isn't just one mod. It's a collection of mods, each with their own carefully designed sense of balance. And, oftentimes, the point at which each mod is balanced, by default, is at odds with at least one other. When that's the case, which do you balance around? It's my firm belief that, in cases like this, the decision on balance of a modpack should be up to the modpack dev and not the dev of any single one of the constituent mods. I also believe that the modpack dev should be able to make this decision without having to get the approval or consent of every one of the mod devs.

Now if you say that I don't *need* to get the approval or consent of all the mod devs as the others don't ask for it then I'll have to agree. But. If you believe it's all right to require it for *one* mod to ask it then I believe you must also have to agree, logically, that it's all right for *every* mod dev to require the same. And, were that the case, making complex modpacks just became ... well ... not something many would have the time or patience to do anymore. And the less *total* modpacks there are, the less *good* modpacks there are as well.

I understand where you're coming from. Modpack creators making bad balance choices and not informing or correcting the users of said modpack that those balance choices were *theirs* instead of *yours*. But that will happen no matter how hard you try to enforce things. People are people, after all, and remember what I said above about the irrationals? They'll do it anyways, with or without your consent. All this does is creates a lot more hassle for your rational users. Perhaps *too* much hassle. In situations like this all you really *can* do is inform them that the broken things aren't on you and not provide support. The modpack dev should be providing 'front-line' support anyways. And if they're not then they're joining the ranks of the irrationals. It's not your job to support balance decisions you didn't make, after all.

If you're hard set on wanting to approve alterations, be they modpack or add-on mod, then I can think of one way of doing so that isn't much of a hassle to your legit users. A simple one too. 'Sanctioned' mods and modpacks. Ones with the official 'Reika Stamp of Approval'. And that would make support easy for you too. You can say you only support the sanctioned ones whilst letting people have fun running wild with their unsupported and unsanctioned ones. If people want their modpack to grow and go more public then they'll likely come to you *wanting* to get it sanctioned. Which is a good thing. It'll feel more like something they *want* to do rather than something to which they're *forced* to do. There's little *functional* difference between them, but you gotta admit that one feels far more friendly than the other.
 

Pyure

Not Totally Useless
Aug 14, 2013
8,334
7,191
383
Waterloo, Ontario
I am curious as to what you would have deemed sufficient, as this new set is heavily based on that long discussion of ours on reddit.
I remember, and as we discussed, BluePower and Project Red are fundamentally different in that they were recreating an abandoned mod. I am talking about if someone made something akin to "ThaumCraft without X", while TC is still active. This is doubly problematic because a good portion of the things people complain about RC do not actually exist - that is, an alleged far-higher-than-normal FPS/TPS impact, and as a result any such derivative may actually be identical, even if claimed to be better.
There's nothing wrong with someone 100% emulating thaumcraft and then improving some aspect of it. There's nothing wrong with someone actually making a drastic improvement to ReC performance.


Spend 5 minutes on the subreddit. Or on google.
Dude, I've done my homework, don't suggest otherwise. ReC gets more flak per post.

Numbers mean different things to different mods. To most mods, especially RF mods, the numbers are purely a balance tweak. They have no greater significance. Presumably the defaults were picked with some reasoning in mind, but even that is not guaranteed.
To a mod like RC/ReC, however, the numbers actually do mean something. For one, it is much more deeply involved in the balance process - imagine the techtree problems even a 1.5x multiplier could cause - but more importantly is part of the overarching design principle of realism.
Frequently, you're right, the numbers have little design significance. I would argue that ReC's power output numbers are considerably more important than BRs. That said, it has little negative impact to let people screw with them for fun. And configurations for explosions have no real negative impact at all ( I don't consider the types of trolling you'd get for allowing that config to be a problem. Those people are total non-entities.)
 
  • Like
Reactions: SynfulChaot

CapJackH

New Member
Jul 29, 2019
70
0
1
Dude, I've done my homework, don't suggest otherwise. ReC gets more flak per post.

On the ftb subreddit, most people seem to be criticizing BR of its Dump yellorite, Get RF like nature lately. The cheaty multiblocks have finally seemed to getting some traction and popularity in opinion. All the flak for ReC and RC seem to be this giant circlejerk of people whining they can't edit Reika's mods without actually suggesting things they need changed.

To each their own. If your general opinion of the community is rather bad, or if your ideas diverge from what most people would prefer then you're probably fine with doing everything on your own. This will generally result in a different kind of mod than a more community-driven approach.
Both have their place, but if you go for the first kind then you can't be surprised when people complain about wanting something different. The first kind can only be considered successful if you are actually able to produce high-quality content completely on your own.

This is a really good point. Mods don't have to be developed in the open source way academic papers are. Mods developing aren't like knowledge progressing where we have to go with majority rule. This is ultimately Reika's content that he graced us with by posting online. I don't think many users in the community believe that both of those types of development environments are acceptable.
 

Strikingwolf

New Member
Jul 29, 2019
3,709
-26
1
On the ftb subreddit, most people seem to be criticizing BR of its Dump yellorite, Get RF like nature lately. The cheaty multiblocks have finally seemed to getting some traction and popularity in opinion. All the flak for ReC and RC seem to be this giant circlejerk of people whining they can't edit Reika's mods without actually suggesting things they need changed.
I've seen circlejerk situations on both sides. That is honestly one of the saddest things about flamy discussions in the MC community, because it almost always ends up like this, otherwise known as a circlejerk
This is a really good point. Mods don't have to be developed in the open source way academic papers are. Mods developing aren't like knowledge progressing where we have to go with majority rule. This is ultimately Reika's content that he graced us with by posting online.
Definitely. Reika has a right to do whatever he wants. However, that doesn't mean we have to think that is the right course of action.
I don't think many users in the community believe that both of those types of development environments are acceptable.
I disagree. I think that the majority of active/informed users (I'm omitting a vast amount of players here I know, but ultimately they are, as @Pyure said, non-entities) think that both are acceptable, but prefer the open-source variant because of the way modpacks have been developed recently. Compare FTB Ultimate with Agrarian Skies, Running Red, and Material Energy. Those are two completely different experiences. The first is just a collection of mods, the second is a custom-crafted experience, a game in its own right. Because of this many people would like all mods to be open to editing to allow these types of packs to be made for all types of mods.
 
  • Like
Reactions: Pyure