RC/ReC/ElC/CC Policy Changes

TomeWyrm

New Member
Jul 29, 2019
898
1
1
He's tried that, and those 1% of jerks are really really LOUD jerks that make trouble for Reika and spread vicious rumors. Normally I'd be right there with you, and I DO keep trying to bring the restrictions into more user-friendly and less-offputting territory gradually but persistently. But history shows that if he tried that? It would blow up in his face.
 

lucariomaster2

New Member
Jul 29, 2019
317
0
1
He's tried that, and those 1% of jerks are really really LOUD jerks that make trouble for Reika and spread vicious rumors. Normally I'd be right there with you, and I DO keep trying to bring the restrictions into more user-friendly and less-offputting territory gradually but persistently. But history shows that if he tried that? It would blow up in his face.

This is the problem; because people who like Reika and his mods are satisfied, the people who don't will always make the most noise, even if they're a tiny minority.
 

TomeWyrm

New Member
Jul 29, 2019
898
1
1
And right now with the current kinda adversarial stance? Most of the vocal jerks have shut down.
 

Reika

RotaryCraft Dev
FTB Mod Dev
Sep 3, 2013
5,079
5,331
550
Toronto, Canada
sites.google.com
But from what i understand the pack developers are saying that listing every single change would take to much time
Yes, that has been one of the main points, but I hold that given the time required for balancing my mods properly should you decide to modify them, anyone unable or unwilling to spend a few minutes documenting changes to my mods is not likely to put the necessary effort in elsewhere, either. I also hold that even if they do put in that effort, they are being rather unfair in that they are implicitly saying that 5 minutes of their time is worth more than hours of mine.
 

Mannhood

New Member
Jul 29, 2019
4
0
0
He's tried that, and those 1% of jerks are really really LOUD jerks that make trouble for Reika and spread vicious rumors. Normally I'd be right there with you, and I DO keep trying to bring the restrictions into more user-friendly and less-offputting territory gradually but persistently. But history shows that if he tried that? It would blow up in his face.

I know like i wrote i have used his mods for few years and i have followed the accusations against hin and i have also argued with velo back in the RR days that Reikas mods where stable low cpu usage and awsome.
so im totally supporting Him and i truly feel bad for what has happend.

Yes, that has been one of the main points, but I hold that given the time required for balancing my mods properly should you decide to modify them, anyone unable or unwilling to spend a few minutes documenting changes to my mods is not likely to put the necessary effort in elsewhere, either. I also hold that even if they do put in that effort, they are being rather unfair in that they are implicitly saying that 5 minutes of their time is worth more than hours of mine.

I understand you and your reasons and accept them but i allso read that the pack makers are saying that they also have a principle that they are not willing to part with. So standing here as a fan of your mods I see it like a bridge is being build the pack makers realize that your mods are great and unique and you realize that your fans would love to see mod packs with the mods in them. But now there is only missing 1 segment to complete the bridge but neither side want to put it in :-( this is really frustrating for a fan like me who would love to see someone like Jaded take rotarycraft and make a HQM pack based on it so that even more people will get to enjoy the mod and the rest of us try to play with it in a different way.

To pull in Gregorius from gregtech he sort of even went to "war" for some of his principles then got a big backlash and then he ended up just saying do what ever you want just do no come complain to me if you change stuff and it blows up. The packs i have seen now with GT in them are actually pretty balanced around GT and they sort of make sure GT is played the way Gregorius visioned. My gut feeling is that if you did the same then you would find that 80%+ of the packs would use RC unchanged and most of those that do change stuff will make sure the mod does not break. then there are the exceptions but there will always be exceptions.

I know you might feel abit like im on the pack devs side but trust me im not i just want to play your mods and i know that the pack devs do not have to use your mods so getting them to conform with your current rules is sadly very unlikely. you on the other hand love your mods just like we fans do and you can as a single person make a change that will ensure more people will get a chance to play with your mods. That is why im mostly talking to you here.

But pack makers would it not be fair that you in the description of your pack point out the mods that you have made changes to and ask people to file bug reports/complaints in regards to those mods to you then you can see if you messed up or if there is a bug and then you report that to the mod maker? and if this is the only thing that is asked of you would it not be fair and not take to much time?

Maybe like this:

Welcome to my new awsome mod pack it contains pink stuf and stuff that moves and turns.
To get the pack the way i visioned i have made changes to the following mods: Rotarycraft, Electriccraft, Reactorcraft, Dragon API, Chromanticraft, Expanded redstone and Pink Power ;-) any bugs/complaints/suggestions please report them on my forum and not directly to the mod makers.

I hope/wish that it could be done like this for all mods.
 

RavynousHunter

New Member
Jul 29, 2019
2,784
-3
1
Yes, that has been one of the main points, but I hold that given the time required for balancing my mods properly should you decide to modify them, anyone unable or unwilling to spend a few minutes documenting changes to my mods is not likely to put the necessary effort in elsewhere, either. I also hold that even if they do put in that effort, they are being rather unfair in that they are implicitly saying that 5 minutes of their time is worth more than hours of mine.

Hell, I documented Minetweaker changes I made for a pack that never even saw the light of day. Didn't touch RotaryCraft (mostly touched AE2 because some of its bullshit annoys the crap outta me), but I documented everything, and it couldn't have taken me more than an hour in total, since I documented changes as I made them. Its kind of telling when people piss and moan about saying "Hey, I changed this in Mod X from its normal behaviour, be aware of that." Its basically the same as telling people eating your food that you're using a vegetarian version of a recipe made by Emeril. It takes next to no time, and its courteous.
 

TomeWyrm

New Member
Jul 29, 2019
898
1
1
Welcome to my new awsome mod pack it contains pink stuf and stuff that moves and turns.
To get the pack the way i visioned i have made changes to the following mods: Rotarycraft, Electriccraft, Reactorcraft, Dragon API, Chromanticraft, Expanded redstone and Pink Power ;-) any bugs/complaints/suggestions please report them on my forum and not directly to the mod makers.

If we're not considering mods tweaked with configs that are still easily recognized as themselves at defaults? Like ignoring the disabling of taint biome spawn and labels not being crooked in Thaumcraft4.
That list (for my personal pack) would be... very long. Over 50, probably up near 100 mods. At which point... what's the point? I may as well say "My stuff isn't default" and move on with a list that simple. Which SHOULD be implied simply because it is a modpack, if stuff wasn't default I'd just give you all a mod list and say "go nuts". Mostly because nobody is going to read "Here's my mod list minus like 20 mods". Which isn't the same thing as an enumerated list like Reika's new policy is asking you to do.
 

EyeDeck

Well-Known Member
Apr 16, 2013
236
87
54
Also for providing defence and reducing bug report count, I will be adding a functionality to my handbooks that adds a special config file that allows for a pack author to specify any changes they make, so that any pack-level changes can be documented in the handbook. All of the pack's changes must be documented here.
I would recommend revising this point because many people reading this seem to be missing the context and believing it means that every single change to every mod in a pack containing your (Reika's) mods must be documented in the handbook. I do not believe this to be the case because that would be entirely unreasonable but I do see why it might be interpreted that way.
 

Reika

RotaryCraft Dev
FTB Mod Dev
Sep 3, 2013
5,079
5,331
550
Toronto, Canada
sites.google.com
I understand you and your reasons and accept them but i allso read that the pack makers are saying that they also have a principle that they are not willing to part with.
This may just be me, but I am entirely pragmatic, so, to me, someone saying "I have principle X, and I will not violate it no matter what, even in light of practical losses", is being unreasonable unless X has its own practical reasons for existing, not purely idealistic ones.



I would recommend revising this point because many people reading this seem to be missing the context and believing it means that every single change to every mod in a pack containing your (Reika's) mods must be documented in the handbook. I do not believe this to be the case because that would be entirely unreasonable but I do see why it might be interpreted that way.
I thought the same - and a few people, here and on reddit, went with that interpretation, not all honestly.

How should I phrase it?
 

Mannhood

New Member
Jul 29, 2019
4
0
0
If we're not considering mods tweaked with configs that are still easily recognized as themselves at defaults? Like ignoring the disabling of taint biome spawn and labels not being crooked in Thaumcraft4.
That list (for my personal pack) would be... very long. Over 50, probably up near 100 mods. At which point... what's the point? I may as well say "My stuff isn't default" and move on with a list that simple. Which SHOULD be implied simply because it is a modpack, if stuff wasn't default I'd just give you all a mod list and say "go nuts". Mostly because nobody is going to read "Here's my mod list minus like 20 mods". Which isn't the same thing as an enumerated list like Reika's new policy is asking you to do.

I think you might just have hit the real issue here. All modpacks are in some way teaked and changed from the default settings and people should know and accept this. But i Reikas and some other mod makers case, pack users are blaming them for the sometimes mod breaking changes. When they really should point the finger at the pack maker. I think that Reika's agenda is that in regards to his mods the pack user should be made aware that that version of his mods is not the original. So that he wont get the awful comments and blame he has been getting.

My idea was in a sense to make sure that the pack users are made aware that mod have been changes and that they should tjeck if it is a pack or mod issue before they point the finger at anyone. And if something universal could be agreed on then maybe we could make things better for both mod and pack creators and ofc. my hope is that Reika and maybe other mod makers that share his views would find the solution good enough so that we can see some packs with their mods in them.


Maybe a good line in any case would be "This is a modpack this means mods are tweaked and some even have changed functionality. Please report errors to pack maker and only report directly to mod creator if you have tested that it's not a pack issue"

Maybe adding this in any case to any pack would make more people aware that there is made changes to mods in mod packs and make sure they place blame /credit in the right spot
 

TomeWyrm

New Member
Jul 29, 2019
898
1
1
I think you might just have hit the real issue here. All modpacks are in some way teaked and changed from the default settings and people should know and accept this. But i Reikas and some other mod makers case, pack users are blaming them for the sometimes mod breaking changes. When they really should point the finger at the pack maker. I think that Reika's agenda is that in regards to his mods the pack user should be made aware that that version of his mods is not the original. So that he wont get the awful comments and blame he has been getting.

My idea was in a sense to make sure that the pack users are made aware that mod have been changes and that they should tjeck if it is a pack or mod issue before they point the finger at anyone. And if something universal could be agreed on then maybe we could make things better for both mod and pack creators and ofc. my hope is that Reika and maybe other mod makers that share his views would find the solution good enough so that we can see some packs with their mods in them.


Maybe a good line in any case would be "This is a modpack this means mods are tweaked and some even have changed functionality. Please report errors to pack maker and only report directly to mod creator if you have tested that it's not a pack issue"

Maybe adding this in any case to any pack would make more people aware that there is made changes to mods in mod packs and make sure they place blame /credit in the right spot

Oh definitely. But while I'm firmly of the opinion that no one author has the right to enforce terms based on other terms, or on other properties (someone had a "you must not be in violation of anyone else's Terms" clause for their permissions. In my eyes? While that makes sense, it is an overstepping of your boundaries/authority/rights. Similarly you can't say (in my opinion) "In order to use my mods, you must not have Thaumcraft Taint enabled", or "You must list every form of Mystcraft Instability present and enabled in your pack"), I am also of the opinion that you should be doing that anyway or you shouldn't be making a pack. While no author has the authority to demand I do that or else, I shouldn't NEED to have that demand put on me in the first place... but that's what a whole heaping pile of laws, rules, and regulations are for. Stuff that shouldn't HAVE to be laws, but we need because People are People.

The new wording change should help a bit with the indignity caused by misunderstandings. Also I hope that all the major mods that don't have freely 100% open permissions dictated by their licenses pick up that clause for the betterment of users and modpack authors. Users can have a simple place to look for changes, and authors have centralized documentation of what they messed with. Win/Win!
 

jaredlll08

New Member
Jul 29, 2019
24
0
0
As some are already aware, I have been debating and discussing some potential changes to my third-party modifications policies.

For those not aware (or who wish to be reminded):

Due to the backlash that the rules have generated, and the fact that I have since realized means with which I can permit some 'legitimate' modification without reintroducing all the old problems, I have been working out a new ruleset.

This ruleset would permit the kind of modification most packs want or need while still protecting me against users who break the mod then blame me for the changes, people playing modified versions of the mod then assuming I am responsible for the modifications, and helping me ensure the integrity of the mod.

I have mentioned versions of this idea before, and was met with some support. I have decided that I am going to move ahead with a version of this plan.

Basically, under the new rules, pack authors would now be permitted to make some changes to RotaryCraft, its addons, or ChromatiCraft, within certain restrictions. Server operators, unless making a custom pack (in which case they become pack authors for the purposes of the rules), remain bound by the old rules, and must use the mod 'as is' or 'as the pack set it'.

The new freedoms for pack authors would allow them to do things like change recipes, so long as the following criteria are met:
  • Someone representing the pack (usually the author) must come to me and explain all of the changes they wish to make. This allows me to allows me to inform pack makers that their changes may be detrimental, redundant, or similar, and to ensure the other criteria are met; I will only disallow a change if it violates one of the criteria. Any changes not disclosed to me are assumed to have been kept as such in order to avoid following the rules, and are strictly forbidden.
  • The pack author must have a fairly clear understanding of the effects their changes will have; for example, pack authors may not make changes without even having tried unmodified versions of a mod, or without understanding the system they are modifying.
  • A few specific things will remain disallowed; almost all of these are "sounds like a good idea but really a bad idea" kind of changes. A few examples will be given near the end of this post.
  • All modifications must be in good faith. Any modifications done in bad faith are totally disallowed. Bad faith modifications include but are not limited to:
    • Modifications intended generate headaches for me, such as by spawning bug reports
    • Modifications designed to enable monetization of my content
    • Modifications designed to "justify" taking partial or complete credit for the mods
    • Modifications designed to tarnish my or my mods' reputation, such as by worsening its stability or deliberately unbalancing it
  • The mod's fundamental identity must remain intact. For example, RotaryCraft must not be converted to an RF mod, ChromatiCraft may not be turned into a ThaumCraft addon, and ReactorCraft reactor design may not be subverted. This also means that the resulting product has to make some sort of sense; things like "all RotaryCraft crafting is done as TC infusion" or "all ChromatiCraft items are TF dungeon loot" do not.
  • I will maintain a publicly viewable list all packs that make changes and what changes they make. This serves primarily as a record of who does what, but also provides a defence against people who want to blame me for the changes, as well as filtering out the occasional "I want to make changes that noone knows about" (that I cannot see a legitimate reason for existing).
  • Also for providing defence and reducing bug report count, I will be adding a functionality to my handbooks that adds a special config file that allows for a pack author to specify any changes they make, so that any pack-level changes can be documented in the handbook. All of the pack's changes to my mods must be documented here.
  • The pack developer must make it reasonably clear in their pack description (or its equivalent) that they have made modifications to my mods and have gotten permission to do so, linking to the list mentioned above.
  • If a modification starts spawning rumors, bug reports, harassment, or similar and the pack author makes no attempt to take responsibility or dispel the effects, the modification must be revised so as to try to keep its original purpose but stop causing problems. If this is not possible, or the pack author is unwilling to make that effort, the modification must be reverted.
  • All modifications must be done though accepted tools, such as MineTweaker. Things like ASM or bytecode editing are not permitted, not least because they severely harm stability or carry a strong connotation of subversion.

Any modifications not granted permission through this system remain disallowed.


EDIT: Read through some of my other posts on this thread; that first point has been revised to be a bit more open.
http://forum.feed-the-beast.com/threads/rc-rec-elc-cc-policy-changes.91274/page-7#post-1241637




Sample "sounds like a good idea but actually a bad idea" modifications that will not be granted permission:
  • OreDicting my Sintered Tungsten ingots with those from another mod, especially one directly obtainable from ore; this is a change that sounds like it "promotes intercompatibility and mod harmony", but in actuality allows players to skip to near the end of the RC techtree, something very likely unforeseen to the pack author
  • OreDicting my Bedrock Alloy ingots with ExU bedrockium; similar reason to above, and even more severely unbalancing
  • Unification of my jet fuel with BC fuel; same reason as above
  • Removing the power converter (like magnetostatic) gating systems, either by adding easier recipes for the upgrades, making the T5s craftable directly


These changes will take effect with the release of v7; pack authors must update to v7 to take advantage of the new freedoms.

Ok so, I am the ModTweaker author, and I have a few questions.
You mentioned MineTweaker, but failed to mention ModTweaker, so does that mean that I am allowed to implement crafting handlers for your mod? Since ModTweaker is an official MineTweaker addon.
Secondly, Will you / do you currently provide an easy method to add and remove recipes, preferably not via IMC as that is incompatible with MineTweaker(It loads it's scripts way to late in the game to take advantage of IMC), but I do have some code that could work for IMC messages, not ideal to use, but would get the job done.

Thanks for lifting your ban on modifications!
 

Reika

RotaryCraft Dev
FTB Mod Dev
Sep 3, 2013
5,079
5,331
550
Toronto, Canada
sites.google.com
Ok so, I am the ModTweaker author, and I have a few questions.
You mentioned MineTweaker, but failed to mention ModTweaker, so does that mean that I am allowed to implement crafting handlers for your mod? Since ModTweaker is an official MineTweaker addon.
Secondly, Will you / do you currently provide an easy method to add and remove recipes, preferably not via IMC as that is incompatible with MineTweaker(It loads it's scripts way to late in the game to take advantage of IMC), but I do have some code that could work for IMC messages, not ideal to use, but would get the job done.

Thanks for lifting your ban on modifications!
This is a question(s) with a complex answer.

Whenever I mention Minetweaker, I usually implicitly mean ModTweaker as well, what with it being an extension of the original.

That said, as for hooks, I would very strongly prefer they be a joint effort; for obvious reasons, it is useful to have the ability for ModTweaker to actually call recipe addition/removal code, I would want the call pass through code on my end, rather than going directly into my recipe code. This is mainly for logging and filtering purposes, so that I can do things like check for recipe conflicts (and act accordingly), or filter out those "must ask first" modifications if the pack is not cleared for it.

I also need to rewrite some of the recipe code, as it was explicitly written to be unmodifiable.

It would not need to be IMC-based, no, and indeed, doing it later is definitely better.


As a side note, many of my recipes are more complex than any I can think of, with multiple requirements like temperature, pressure, liquid, items (often in a specific arrangement), catalysts, and more. How do you plan to handle that?
 
  • Like
Reactions: duckfan77 and Pyure

jaredlll08

New Member
Jul 29, 2019
24
0
0
This is a question(s) with a complex answer.

Whenever I mention Minetweaker, I usually implicitly mean ModTweaker as well, what with it being an extension of the original.

That said, as for hooks, I would very strongly prefer they be a joint effort; for obvious reasons, it is useful to have the ability for ModTweaker to actually call recipe addition/removal code, I would want the call pass through code on my end, rather than going directly into my recipe code. This is mainly for logging and filtering purposes, so that I can do things like check for recipe conflicts (and act accordingly), or filter out those "must ask first" modifications if the pack is not cleared for it.

I also need to rewrite some of the recipe code, as it was explicitly written to be unmodifiable.

It would not need to be IMC-based, no, and indeed, doing it later is definitely better.


As a side note, many of my recipes are more complex than any I can think of, with multiple requirements like temperature, pressure, liquid, items (often in a specific arrangement), catalysts, and more. How do you plan to handle that?

I would need to see how you do the code, it will most likely just be an extremely long handler, such as
mods.rotaryCraft.<machine>.addRecipe(<ItemStack output>, <integer temperature>, <integer pressure>, <liquidstack input1>, <ItemStack input2>);
something along those lines.
 

Reika

RotaryCraft Dev
FTB Mod Dev
Sep 3, 2013
5,079
5,331
550
Toronto, Canada
sites.google.com
I would need to see how you do the code, it will most likely just be an extremely long handler, such as
mods.rotaryCraft.<machine>.addRecipe(<ItemStack output>, <integer temperature>, <integer pressure>, <liquidstack input1>, <ItemStack input2>);
something along those lines.

All my recipe code can be found in the /Auxiliary/RecipeManagers in the source. Note that there will be many references to DragonAPI code, especially OneWayCollection and ItemHashMap.

I have some basic support for adding recipes. Nothing for removing them. It also does not seem to work, because calling them from a zs script says the tag was not found.
 

jaredlll08

New Member
Jul 29, 2019
24
0
0
All my recipe code can be found in the /Auxiliary/RecipeManagers in the source. Note that there will be many references to DragonAPI code, especially OneWayCollection and ItemHashMap.


I have some basic support for adding recipes. Nothing for removing them. It also does not seem to work, because calling them from a zs script says the tag was not found.
heh with minetweaker you need to use the annotation AND you need to register them with minetweaker, take a look at how modtweaker does it.