Quick Nav

Back To Top
Note
Definitions
Preface
Explanation
Dependencies
Balance and Progression
Why Only Mine
Mod Design
Why I Care
Special Permissions
What You Can Do

Note

This was written a long time ago, before ChromatiCraft was developed, and as such almost exclusively focuses on RotaryCraft and its addons. Additionally, when it was written, my mods were far more widely used than they are now and there were a great many more "non-knowledgable" people running servers and packs with it. Nowadays, my userbase consists much more exclusively of people who are more familiar with or at least interested in the mod, making this less widespread of a problem than before. The arguments still apply, but problematic modifications are now less common than they are described here. Finally, despite the focus on RotaryCraft, these arguments also apply to ChromatiCraft (though that mod's built-in progression system neutralizes a few of the "you can shortcut X or Y" concerns).

Definitions


Preface

Many, many rumors and falsehoods are circulating about the stance I take on third-party modifications. Common (blatantly false) claims are that you cannot install Minetweaker in the same pack as RotaryCraft, or that it I will crash the game if I detect it.
High-level managers of the Resonant Rise pack spreading this rumor.

Also common are claims that I disallow modifications because of a "do things my way" attitude, not for any legitimate reasons.
Another less-common claim is that I do not even permit changing of my configs, something that is simply false.

Explanation

It is true that I do not allow third-party modification to RotaryCraft (and, by extension, its addons) or ChromatiCraft when in modpacks or on servers. However, this is done because of how those mods are balanced and designed. Unlike the vast majority of mods, those mods, rather than making later-game items progressively more expensive, use a strict tiering system. I will focus mainly on RotaryCraft because it is more popular and older (and thus more well-known) than the others.
RotaryCraft did not always forbid modification; that is a comparatively recent rule that was introduced to curb the undesirable effects, which are as follows:

Dependencies

In RotaryCraft, every item and machine is gated behind another, in a progressive system of "you need A to get B, and B to get C, and both A and C to get D or E". A late-game machine or item may not look expensive - some cost less than twenty raw units of material - but it requires, either in its recipe, in power cost, or some other required component, another material or item that can only be obtained from the previous tier.

What this then means is twofold. One, removing any one of these core "stepping stone" machines or items makes everything after it inaccessible. Two, changing a recipe with the intention of making it more expensive, and inadvertently removing the gating item opens up the tier to entry-level access. The first is obviously a problem because of the fact that a large fraction of the mod content is now unreachable, and the second is a problem because a player can immediately shortcut to the given tier, severely upsetting the balance of both RotaryCraft and the rest of the pack.

The rebuttal to this is that a sensible pack developer will foresee this and balance it accordingly, either filling in the gaps created by a machine's removal or ensuring not to remove gating materials or other requirements.

Some modpack authors certainly will. However, many, possibly most, will not. For one, many pack authors, try as they may, will fail to either grasp the sheer complexity of the tiering system or find an acceptable alternative. Even the most competent and well-intentioned modpack creator has a limit to their patience and time, and for a mod where it often takes players days to grasp the requirements, it is not unreasonable for this to elude them. Additionally, many modpack authors do not put in that kind of effort. Just like in real life, a great many people are lazy, impatient or incompetent and will make rash decisions based on poor research, and for whom the idea of spending several hours testing, tweaking and retesting is an unreasonable and excessive demand, something they will not hesitate to make loudly and aggressively clear.

Additionally, my rules are actually more concerned with server owners, many of whom go beyond the changes added by the modpack and attempt to "rebalance" it for their server. For one, unlike modpack-level changes, these changes are far less intricate and usually consist of flatly disabling items. Second, a great many server owners are not owners because of any special skill on their part, but because they happen to have the money, hardware, or time to do so. For many server admins, the "research" conducted on a mod to determine if it is balanced for the server consists of a small amount of testing in creative mode, with perhaps some checking in NEI, a wiki, or a mod spotlight. None of these provide a decent indication of the kind of tiering RotaryCraft has, and as a result most server admins take one look at RotaryCraft and assume it is extremely overpowered, and try to modify it accordingly. The problem is worsened by the fact such judgements are often made while using out-of-date mod versions.

Historically, the vast majority - over 90% - of the changes to RotaryCraft were some combination of the following: The first two were far and away the most common, outnumbering the others put together. These may sound reasonable, especially to someone unfamiliar with RotaryCraft. Here is what happens instead:

Now you cannot get tungsten flakes, which are an Extractor byproduct, so you cannot get tungsten. Therefore, you can no longer make a bedrock breaker, and thus cannot get bedrock. Due to the lack of tungsten, you also can no longer make a jet engine, so you cannot use anything that requires more power than 4 microturbines (8MW) can generate (shaft junctions cap at 4 engines), or, with the lack of bedrock, more than a certain amount of torque or speed (diamond load limit because of no bedrock gears, and no CVT or high-ratio gear as those need bedrock).

Again because of the lack of bedrock, you also lose the compactor, which, if you have ReactorCraft, means you lose the fusion reactor, as well as the uranium centrifuge; losing the uranium centrifuge means you also lose the fission reactors, which also prevents you from getting breeder or again fusion reactors.

ElectriCraft, if you have it, also suffers; the lack of tungsten throttles your available battery types, and superconducting (lossless) wires are also uncraftable, as are any of the high-capacity RF cables and batteries.

And these effects propagate; many more machines are either impossible to create or impossible to run, and most of those are also dependencies for yet others. All in all, about 40% of RotaryCraft, 90% of ReactorCraft, and 50% of ElectriCraft becomes impossible.

Depressingly, it gets worse: A not-insignificant portion of the people making changes do things like making the bedrock breaker recipe require bedrock (?!) whose effects should be obvious and which shows how little effort they put into their research.

Balance and Progression

On the flip side, another common occurrence was to replace the bedrock breaker's recipe with something that seemed more expensive, but removed the tungsten ingot from the recipe. Now, the bedrock breaker is no longer gated at the end of the RotaryCraft techtree, and thus players can obtain it and bedrock items - most popularly tools and armor - much earlier than would otherwise be possible. The efforts of the pack creator/server admin have backfired dramatically, and their server suffers as a result.

This is doubly true because the RotaryCraft progression goes beyond balance; Every step of the techtree requires more than just making and using machines. Every step is additionally gated behind some key level of problem-solving, something like obtaining a specific temperature, or understanding torque/speed mechanics, or dynamic transmission engineering. When a player obtains access to a machine without the prerequisite progression, they lack the knowledge and understanding that is assumed and expected of them. This then manifests itself as them failing to do things properly. In all likelihood, in addition to many players simply being unable to perform what would normally at that point be simple tasks, there will be machine failures, fires, explosions, and if ReactorCraft is involved, potentially biome-killing radiation.

"What about other mods? Why do they not care about this?"

Most mod authors do not care about their mods' recipes being tweaked because they have no real progression to speak of; most often, later-game items require more resources, but could be used as an entry point to the mod if resources were not an issue. (This, by the way, is the primary argument used against the Extractor's 5x ore multiplication, that those mods become inherently unbalanced). Thus the consequences described above do not exist.

Some mods have some progression, like ThaumCraft or Tinker's Construct with the three crafting tiers, but here is the major catch: Everyone is already familiar with those mods, being far older and far more popular, so no pack dev or server admin would turn off or circumvent any of the tiers, and even if they did, the changes would be immediately obvious. Additionally, the progression in mods like ThaumCraft or Tinker's Construct is comparatively small and can be completed in a matter of a couple hours or so, and is much less complex than that of RotaryCraft, making unintended consequences much less likely. Finally, if it was a common problem, and the reputation of mods like ThaumCraft started to suffer because too many people were breaking them, I find it very likely that their devs would respond.

The only other Forge mod I know of that has major progression is GregTech, and he stopped caring what people do to it long ago. His mod is a special case; for the most part, it is only used by a core group of fans, and he stays out of the more general community. This means that he will experience fewer cases of bad editing and less reaction from the cases that do happen. Furthermore, for many people, his reputation is already irreparably tarnished, so he likely feels that people editing GregTech cannot do any further damage.

Mod Design

RotaryCraft and ReactorCraft are designed to be as realistic as is reasonably possible to implement and play. This is core to their design. This means that every process, design, or machine approximates a real-world design as best as possible, and this includes things like recipe ingredients, power requirements, temperature requirements, and so on. Changing any of the way things work - such as by substituting recipe items, or more systemic changes - destroys that and RotaryCraft very quickly turns into a Frankenstein of its former self. For a mod that is based around a given theme, and where for the vast majority of the players, core to its appeal, this is severely problematic. It is also something of an insult to the developer, as it throws out hours upon hours of research and careful tweaking and disregards everything their content was designed to be.

Why I Care

There are several reasons why I care when people damage the way RotaryCraft works through poorly thought-out modifications.

The altruistic answer is that I do want my content to be enjoyed by the users; I want them to have fun playing RC and not spend time getting upset because of a problem that should have never happened, be it from them getting frustrated because they do not have prerequisite knowledge or suffered as a result, or because half the mod is kept from them because their server admin made a rash decision.

More pragmatically, poor edits cause problems for both parties. In my case, I am often the first to hear about it when a player fails in the operation of some machine, or when something becomes impossible as the result of a bad edit. The following are real messages of this nature: Before I put in place my rules against modification, I averaged 5 or so such messages a day, which is a waste of time and is incredibly demotivating. Additionally, most were rather longer than these, sometimes enough to fill several pages, and I spent 30 to 120 minutes a day responding and dealing with them.

Additionally, when it repeats often enough, problems caused by this tend to manifest themselves as a bad reputation for the mod itself, that the mod is bugged or poorly balanced.
Finally, if a machine is modified so that it no longer works the way the documentation and I claim it does, I start getting bug reports that something does not work, and I waste hours chasing a nonexistent glitch. Despite what some people claim, most players do not include what modpack they are using when making a report, nor are they even aware of any changes made to how they behave.

It is true that many pack makers will tell players to pose questions and bug reports and complaints to them first. However, many players - especially the kind of players who leave messages like the above - will ignore such requests, and that does nothing to stop either pack makers who do not make such requests - of which there are a great many, with an example below - or cases like the above where the ones complaining are the pack makers and server admins.

It is commonly argued that this is not a serious problem because such reports and abuse are easily ignored. This is simply false. Not only are the false bug reports visually indistinguishable from real bug reports, but even the people spouting abuse do it through the same channels that are designed to receive legitimate bug reports, including forums, GitHub, and even email. Moreover, if one simply ignores and does not reply to their post, they tend to repeat it until they receive a response, especially if their post contained a question.

Special Permissions

A commonly proposed solution to the above problems is to adopt a policy of allowing certain sanctioned modifications, ones that I would screen beforehand to ensure they are reasonable so that modpack authors could make reasonable changes. In a perfect world, this would be a good idea.

Unfortunately, as it happens, I tried this. And it blew up in my face.
One, many pack creators took it very negatively. A great many painted the new exceptions as my stepping even further on their toes, portraying it as "we used to be able to do as we pleased, but now we are being forced to ask him", when that was simply false. The more unscrupulous ones even took it as an opportunity to claim I was targeting specific packs and authors for alleged personal reasons. One even accused me of bribery.
Two, even worse was how many mod developers reacted. Many openly stated that I had no right to choose who can and cannot make modifications, with several claiming I was playing favorites, and more than one claiming I was implementing DRM code in my mods. Several smeared me on places like reddit and twitter - the effects of which still persist in the form of rumors and some nasty opinions a year later - and a couple of mods put code in their mod to warn players and threaten me with further actions.
A commit from Tinker's Construct soon after I tried this.

[2013-11-21 17:47:02] [SEVERE] [TConstruct] [Environment Checks] DragonAPI detected. Currently this just logs a warning, however if Reika continues his plan to implement DRM-like
[2013-11-21 17:47:02] [SEVERE] [TConstruct] [Environment Checks] code in his mod then it may become marked as fully unsupported. This is just a warning at this stage.

Because of the fact that many people - including players, pack makers, and mod developers - conflated giving permission for certain reasonable edits with giving certain people blanket permission and denying others, and because of how they reacted, I am not willing to implement such a policy, as I am reasonably certain its only outcome will be further suffering on my part.

What You Can Do

If you do need to be able to change something in how RotaryCraft behaves, and you do not currently have the ability to do this without using a third-party modification, come to me.
If you can present a valid use case, and the change does not cause significant side effects, your request may be added as a config option which you are then free to modify. Several config options that currently exist are examples of this, including the ability to disable block damage, the ability to disable several non-core machines, the ability to make the Borer and Extractor require maintenance, the ability to disable automining, and the ability to disable flight with the jetpacks.
Under no circumstances am I obligated to include anything suggested. If I do reject your idea, I will explain my reasons for doing so, but do not get aggressive or pushy. Suggestions which go against the four main tenets of the RC mod design - realism, extremely powerful endgame, advanced rendering, and learning over grinding - are almost certainly going to be rejected without your providing a very good justification. Again, however, you will be informed of this.
Any request with no real purpose ("I want an option for engines to play music sounds"/"Please add an option to make the blast furnace also craftable from diamond blocks"), or whose effects are crippling, such as by making progression impossible ("I want an option to turn off all the required worldgen"/"Can I have an option to disable engines?"), have no chance of being implemented.

Also, if you are playing singleplayer, you can make whatever kind of changes you like, as long as noone but you is playing that version. You are even permitted to make custom builds of the code, so long as you never share it. The only caveat is that such modified versions are ineligible for tech support.