RC/ReC/ElC/CC Policy Changes

[SynfulChaot]

It makes a really big difference Reika, honestly it does. But there's zero place for area-of-effect explosions or radiation contamination in the scenario I'm attempting to construct. It's just not workable, period. If the blocks vanished or stopped working or turned into something like Lava, I'd totally get it. But one mod cannot destroy all the works the player has done around it.

What is the current radius of effect of a meltdown? I may be misremembering the area of effect, in which case I'd concede the problem isn't as bad as I think.

How about if RoC/ReC implemented some form of containment you could utilize that would buffer the effects to within the contained area? That's the solution that IC2 uses and is, IMHO, far better than simply disabling the mechanic entirely. Especially as that's how reactors in real life are built. That way if people are too brash/prideful to utilize containment then they get what they deserve, but if they take the proper precautions, just like in IRL reactors, they can limit the area of the damages. Fukushima comes to mind ...

Would something akin to this still be too much for your proposed modpack idea, Pyure?

 

[keybounce]

On the issue of config settings:

Something that I don't think most people have considered. When I play, I'm generally trying to entertain others. Playing by myself, building something for myself, is not nearly as fun as playing with others, or showing off what I've done.

Hence, a YouTube channel that focuses on minecraft.

With a very, very radical texture pack: Vanilla. I want people to be able to understand what they are looking at.

With another very radical idea: No alterations to configs, aside from what's needed to define the world I'm in.

To clarify that: Basic operations are going to be the pack normal defaults. Now, maybe I'll have things restricted -- on relaunch for 1710, my world and channel will be based around exploration. No one dimension will have everything. Most will only have a restricted subset of things.

But anything that I build will be based off default behavior.

This isn't such a crazy idea. Is there any difference between "You can use a config file to make X easier", or "You can adjust a config file to make lots of diamonds (or gold, or platinum, or ...) found around Y=40 and just look under the ocean bottom or mineshaft tops"?

At some point, there comes a "What is reasonable?" concern. If a mod maker considered something to be the balanced point, then unless there is a serious problem, that's probably how the mod was meant to be played, and a major tweak/alteration makes people question the effort that went into the build -- and the whole "showing off what I've done" becomes less valuable/interesting.

Could I tweak everything to unrecognizability? Sure. Going to have to, in fact -- many mods with worldgen either assume that they should generate in every dimension, or only in dimension 0 -- either one makes it painful to deal with a world based around multiple dimensions that behave differently. (Incidentally, tracking down all the "I only work in dim 0" mods is my biggest headache).

But there's a difference between "Gee, all these wonderful plants, but none are in this world?" (yes, because that world has every biome, so it would have every plant, so there's no more exploration) and "Gee, this mod is now three times as easy".

So, it's not just "if you don't like it, there is a config". If you are planning on sharing with others, having that default config be reasonable becomes seriously important.

 

[Pyure]

How about if RoC/ReC implemented some form of containment you could utilize that would buffer the effects to within the contained area? That's the solution that IC2 uses and is, IMHO, far better than simply disabling the mechanic entirely. Especially as that's how reactors in real life are built. That way if people are too brash/prideful to utilize containment then they get what they deserve, but if they take the proper precautions, just like in IRL reactors, they can limit the area of the damages. Fukushima comes to mind ...

Would something akin to this still be too much for your proposed modpack idea, Pyure?

That would probably be a more-or-less workable compromise. It depends how much of the reactor itself is salvageable.

There's two things I prefer to encourage in game design:
1) no save-scumming. I don't want players relying on aroma-backup as an actual gameplay element
2) in-game experimentation. I don't want players leaving their game to go into a creative version and tinker there.

Obviously these can't be avoided entirely, but every effort must be made to mitigate the problems.

 

[Reika]

You're talking in a tangle here. We're talking about evaluating user input. Your current stance in these posts appears to be "saying any input is good and worth implementation is a bad idea because it sets a bad precedence." I know that's not your actual stance, so its annoying when you use it as your argument.

Actually, the idea that absolutely any input is worth implementing is invalid, though I doubt this is what you are intending to mean.

I'm not sure how this is even connected to the feasibility and logic of adding trivial configuration.

It was a rebuttal to your rejection of my point that "effective defaults" matter as much as or more than actual defaults.

You've rejected this notion on your RoC suggestions thread. Also, its still not workable in a static map pack where the player has a tiny amount of space to work with. They can't be blowing holes in the walls of their vessel, which is the entire universe, and losing the game because of an experimentation gone wrong.

This is a no-argument scenario where its absolutely critical that the tools available to the player do not create instant-lose scenarios.

It makes a really big difference Reika, honestly it does. But there's zero place for area-of-effect explosions or radiation contamination in the scenario I'm attempting to construct. It's just not workable, period. If the blocks vanished or stopped working or turned into something like Lava, I'd totally get it. But one mod cannot destroy all the works the player has done around it.

What is the current radius of effect of a meltdown? I may be misremembering the area of effect, in which case I'd concede the problem isn't as bad as I think.

One, I turned it down because it was suggested in a different form, a much less acceptable one.
Two, "zero place for AOE explosions"? Then you are also going to come back asking for configs to turn off all the other machine explosions, some of which are much more destructive in terms of explosive force.

As for the radius, the actual explosion crater is usually about 8 blocks across. Radiation is highly randomized and varies strongly on the size of the reactor, the number of melting cores, and other hardware. It can be as small as 16-32 blocks or as large as several hundred. Average is about 50 blocks radius.

He has entire threads supposedly devoted to user input and ideas. How is this any different?

Not all ideas are equal. Some are good and worth implementation or at least consideration. Others are more borderline and may be picked as a "lesser of two evils" or due to necessity. Still others are a bad idea because they risk larger problems. (This config sits in this category). And some are even worse because they are simply ridiculous. I doubt you dispute this.

How about if RoC/ReC implemented some form of containment you could utilize that would buffer the effects to within the contained area? That's the solution that IC2 uses and is, IMHO, far better than simply disabling the mechanic entirely. Especially as that's how reactors in real life are built. That way if people are too brash/prideful to utilize containment then they get what they deserve, but if they take the proper precautions, just like in IRL reactors, they can limit the area of the damages. Fukushima comes to mind ...

Would something akin to this still be too much for your proposed modpack idea, Pyure?

This. I have not implemented something like this because I do not know of any way to do so, but I am open to the idea on its own merit, and if anyone has ideas on implementation, go ahead.

That would probably be a more-or-less workable compromise. It depends how much of the reactor itself is salvageable.

The reactor itself rarely survives a meltdown. Even if the radiation were turned off, the explosion destroys the central area, including much of the auxiliary hardware, and any melting core is turned into corium.

Also, about save scumming: While you do not want people using that as a game mechanic, I strongly suspect most of players you describe - ones unwilling to accept large costs no matter the magnitude of the error on your part, and wanting a more BR-style gameplay but with ReC's power capabilities - will do it the instant they lose anything, be it via meltdown, gearbox overloading, engine failure, or anything else.

 

[Lethosos]

Hardness could be a benchmark to help reduce the spread within a general direction. Just spitballing.

 

[Reika]

Hardness could be a benchmark to help reduce the spread within a general direction. Just spitballing.

Scanning the area around on meltdown is very expensive. Currently the meltdown is coded as follows:

First, the core itself is turned into corium.
Then the surrounding 5x5 or so of non-TileEntity blocks are 'entitized' - that is, turned into falling sand entities - at their position.
Then a moderate-size explosion - usually about 6, the power of a charged creeper - is detonated at the core's original location. This scatters the falling sand entities - and generates the flying blocks - and destroys other blocks in the core area.
Then a number of radiation entities are spawned. Their distribution is utterly random, though their number, size, and max distance are functions of the reactor.


Also, additional "chained" explosions - such as other cores failing a few seconds later, as is somewhat common - vastly worsen the radiation, as radiation has a built-in "spread and intensified by explosions" mechanic.

 

[TomeWyrm]

"what if mod X forbade me from asking permission for mod Y".

I've seen that before.

I do. And even more, again including Watchful, FyberOptic, JoshieJack, and TomeWyrm (though to be fair, TomeWyrm's approval was reduced somewhat when he realized how much of an overhaul it really was), to the RF-ifier mod, which again I keep bringing up because you have repeatedly said that it is not a realistic example in the face of the contradictory experiences I have.

Pretty much. I wanted (and still do) a method to losslessly convert RF to RoC. I didn't care for the rest of the implementation. There are times and places I'd be happy to use shaft for the whole system, but RF is just less tediously annoying to transport. Also that means I can easily power all the OTHER mods machines with RoC... because exponents are fun!

Well magnetostatics are designed so that conversion is non-trivial. In many other cases, conversions are basically made to subvert the target's power generation.

No, most other cases conversions are made bidirectional for ease of design. If I'm using EU all over and there's an EU cable right there, I don't want to build an RF power source to power the one rolling machine or refinery or what have you required for the system. You might look at that as "subverting the mods power generation", but I look at it as "why can't I do this build without using 15 power sources". With the proliferation of RF and EnderIO's multiple-cables-in-a-block? Now I can most of the time. It makes my builds function smoother and look cleaner. Which is a big selling point, and why I STILL use power converters. It's one of the things I adore about Immersive Engineering. It says energy is energy is energy. I can pump an IC2 nuclear reactor into the energy net and power a pulverizer, or use a nether star generator and power a bank of recyclers. If I want to run my base off of a hungry node-powered wither skeleton & chicken farm, power converters, MFR, and Extra Utilities probably makes that possible.

With a very, very radical texture pack: Vanilla. I want people to be able to understand what they are looking at.

Give this person a billion internet points please. I flat-out cannot stand people using unfaithful texture packs for non-creative/artsy worlds. ESPECIALLY when they ask for support. It makes me wish I could revoke their computer privileges for an indeterminate amount of time.

having that default config be reasonable becomes seriously important.

http://blog.codinghorror.com/the-power-of-defaults/
I can't express how important that is, nor my love for @immibis due to the inclusion of a link to that article in his signature.

This. I have not implemented something like this because I do not know of any way to do so, but I am open to the idea on its own merit, and if anyone has ideas on implementation, go ahead.

Make the radiation entities spawn AFTER the explosive event, and respect collision. Reactor Meltdown contained. Just add bedrock or septuple compressed cobble, or obsidian, or something.

 

[Lethosos]

Scanning the area around on meltdown is very expensive.

No more than a Runic Altar does for a Stability check whenever it performs a ritual on command. But I get your point.

 

[TomeWyrm]

I should add that the radiation entites should travel slowly enough that they can be 100% contained by a reasonable wall. None of the MeteorCraft meteors-going-through-shields behavior . But imparting random directions and velocities at spawn should be relatively easy... heck you could make them avoid collisions with blocks that have blast resistance bellow X, which could stick them in walls and stuff... just not through a sufficiently blast resistant containment chamber.

 

[Reika]

I've seen that before.

RF is just less tediously annoying to transport.

I fully agree on this and hence why I use it lategame, but that does not justifying RFifying RC.

Also that means I can easily power all the OTHER mods machines with RoC... because exponents are fun!

You can anyways...

Make the radiation entities spawn AFTER the explosive event

They do.

, and respect collision. Reactor Meltdown contained. Just add bedrock or septuple compressed cobble, or obsidian, or something.

You would literally need a solid cube of it. I suspect you really mean raytrace. That is also very expensive.

EDIT upon seeing reply:
You misunderstood; they are not "fired" out of the core. They are spawned in location. Also, making them collideable is not an option, because then they would be subject to things like being pushed by mobs or dealt knockback when punched.

They are coded as entities to give the TC3-node-style "ambient effect" design.

 

[Pyure]

Actually, the idea that absolutely any input is worth implementing is invalid, though I doubt this is what you are intending to mean.

We're agreed on that, although its not really the point.

It was a rebuttal to your rejection of my point that "effective defaults" matter as much as or more than actual defaults.

It sounds like you're suggesting that your own defaults would be ineffective? Everyone who wants to use them will use them. Some big packs might turn on wuss-mode, although I've never seen a pack do this. Taking IC2 as an example, all wirefires and explosions have always been on by default in major packs.

One, I turned it down because it was suggested in a different form, a much less acceptable one.
Two, "zero place for AOE explosions"? Then you are also going to come back asking for configs to turn off all the other machine explosions, some of which are much more destructive in terms of explosive force.

Don't presume to tell me what I'll ask for next. And don't pretend that one request accepted means that all of them need to be.

As for the radius, the actual explosion crater is usually about 8 blocks across. Radiation is highly randomized and varies strongly on the size of the reactor, the number of melting cores, and other hardware. It can be as small as 16-32 blocks or as large as several hundred. Average is about 50 blocks radius.

Wouldn't work. For serious players in a serious cost/benefit scenario this may be explicable, but not in a more casual game.

Not all ideas are equal. Some are good and worth implementation or at least consideration. Others are more borderline and may be picked as a "lesser of two evils" or due to necessity. Still others are a bad idea because they risk larger problems. (This config sits in this category). And some are even worse because they are simply ridiculous. I doubt you dispute this.

For the first half, goes without saying. For the paranthesis, that's your blind spot. This config is an excellent idea with no downsides except the ones you create in your mind. Yes, you totally fail to comprehend this. I've been trying to explain it to you and you don't get it.

Your failure to understand it isn't really your problem yet, except insofar as you're getting hassled about it and until someone rips off your mod to fill the niche.

There's a demand for emergent nuclear fission with casual, learn-from-your-mistakes-within-the-game type consequences.

The reactor itself rarely survives a meltdown. Even if the radiation were turned off, the explosion destroys the central area, including much of the auxiliary hardware, and any melting core is turned into corium.

Also, about save scumming: While you do not want people using that as a game mechanic, I strongly suspect most of players you describe - ones unwilling to accept large costs no matter the magnitude of the error on your part, and wanting a more BR-style gameplay but with ReC's power capabilities - will do it the instant they lose anything, be it via meltdown, gearbox overloading, engine failure, or anything else.

I can't speak to what everyone does. All I can do is mitigate the problems, and here's a case of two wrongs not making a right.

If I can reduce the amount of save-shenanigans going on, great. I can't fix them all, but here's one with an obvious, simple and strong solution that gives everyone what they want.

 

[Reika]

It sounds like you're suggesting that your own defaults would be ineffective? Everyone who wants to use them will use them. Some big packs might turn on wuss-mode, although I've never seen a pack do this.

I have. Also, yes, that is exactly my point. Big packs have far more influence than I do, and far more exposure than I do. Remember, most of my playerbase, including you, came from Monster and Horizons. Had I had an option (and they turned it on) to make certain changes that damaged the integrity of the mod design, most of my players probably would not be here. Again probably including you.

You keep saying I am making all this up in my head, but I see this as a perfectly reasonable and not at all implausible scenario. I see it happen to other mods, and low-level versions have and do happen(ed) to me.

Don't presume to tell me what I'll ask for next.

Getting (what sounds to be) angry over a logical extension - you complain about one example of X, make it clear that X is unacceptable, and then I say you are probably going to dislike the other Xs - is not reasonable.

And don't pretend that one request accepted means that all of them need to be.

"Need", no. "Be portrayed as the 'right' thing to do"? Probably.

Wouldn't work. For serious players in a serious cost/benefit scenario this may be explicable, but not in a more casual game.

The radiation or the explosion?

Also, my servers and play worlds are as casual as you can get and this has never been an issue.

 

[TomeWyrm]

You would literally need a solid cube of it. I suspect you really mean raytrace. That is also very expensive.

EDIT upon seeing reply:
You misunderstood; they are not "fired" out of the core. They are spawned in location. Also, making them collideable is not an option, because then they would be subject to things like being pushed by mobs or dealt knockback when punched.

They are coded as entities to give the TC3-node-style "ambient effect" design.

Make them collide only with certain kinds of blocks, and then after X timer turn into the current radiation entites? Also yes . My reaction to when I saw that kind of crap too. I have not in many years had to lower my bar for "things to not expect from humanity", nor had occasion to raise it. There are reasons for that, and people that petty are one of them.

Don't presume to tell me what I'll ask for next. And don't pretend that one request accepted means that all of them need to be.

Slippery slope. Also EVERYONE will have a leg to argue from if he accepts a balance change like that (and yes it IS a balance change, removing consequences affects balance). So he's giving more ammunition to people he doesn't want to give debate ammo to, AND incentivizing himself through previous actions to do it again. As much as I agree with you that allowing "wuss mode" is a thing that is trivial to implement and good for certain styles of packs, in this case Reika really does have a point beyond "I'm sticking to my principles". I can provide examples/citations of the effects I'm talking about if you'd like.

 

[Reika]

Make them collide only with certain kinds of blocks, and then after X timer turn into the current radiation entites?

That is not how collision works. That said, a raytrace may not be such a bad idea if - if - I can multithread it.

 

[TomeWyrm]

Eh, it was worth a shot, collision is one of those magical programming thingies to me. Very black box. Could you have it check within the radius for the presence and location of "containment" blocks (which I still say should be based on explosion resistance, just for future-proofing) and not... oh right that'd be ray-tracing. I was going to say not allow the radiation entities to be placed beyond those blocks.

The biggest issue is "Then a number of radiation entities are spawned. Their distribution is utterly random, though their number, size, and max distance are functions of the reactor." Is there a way to give the entities a central spawn location, impart a velocity (which being a vector has direction, yes I noticed that after I posted, no I didn't feel like editing it on the previous post), give it a "friction" which is simply a decay on the magnitude of the velocity, and then tell them that certain blocks are impassable without having to raytrace? Or is the MC collision code an untouchable black-box?

Can you call the explosion code with some kind of "take back" so you just see where an explosion WOULD have removed blocks, and then place radiation entites only there, or would that be worse than just raytracing and checking the cumulative explosion resistance of the blocks in the path of the rays?

 

[TomeWyrm]

OH! Could you give the entities no-clip, a decaying speed, random direction, and a list of blocks that they instantly die inside of? Then when speed = 0 (or after Y ticks) change them to the current radiation entities so they quit checking what block they're in? Or is that worse performance-wise than just ray-tracing?

 

[keybounce]

There's two things I prefer to encourage in game design:
1) no save-scumming. I don't want players relying on aroma-backup as an actual gameplay element
2) in-game experimentation. I don't want players leaving their game to go into a creative version and tinker there.

XCom-like mechanics are hard to balance. You want to make sure that a disaster is survivable; you want to tell people to expect to fail once or twice, minimum.

Basically, you have to make sure that the meta-game is easier than the detail-game. XCom field battles were hard. The geoscape had to be made easy, and the alien's master plan was pathetically weak. (In fairness, they got major cheats on the subvert governments mission -- that is really the only danger facing the XCom people in a long game)

Apparently, the remake didn't get this balance right -- it was easy (I'm told; I don't have a PC to play it on) to get into a situation where you could not win, and at best could only learn for next game. In comparison, the original's only "whoops, you blew it" was that if you did not get a sectoid scout early for the psi-amp, your only way to get one was from a sectoid battleship. But in fairness, you didn't even need it -- I found the oddball room on mars, blew a hole in the roof, sacrificed one guy to scout, and then just sent a bomb up and over. No psi needed. (Guess how I learned about the hole in the game's supplies .

No save scumming means that nothing can be a complete disaster. No bound picks (Blood Magic). No massive earth shattering kaboom (Reactor craft). No "Permanent exile" (mystcraft). Etc.

It is hard. Lots of mods have some sort of disaster awaiting.

No "play in creative mode to learn how things work" has a different problem. If you are experimenting in survival, then the costs have to be "small" -- you are going to have to do it 3 or 4 times, minimum. Worse, it's the *TIME* cost, not the game resource costs. Trying to learn how to set up a complicated redstone device can be massively time consuming. It becomes easier if you can fly around (creative flight), or have no limit on resources (survival inventory vs creative "just grab it"), or just the concerns of mobs hitting you in an area that isn't 100% secure. And working with something that takes time to adjust (hard blocks that don't mine quickly; blocks that affect others when removed; chain reactions of trying to shut X down; etc) -- basically, you need enough documentation that people don't have major surprises (anyone asking for a youtube video is effectively asking for a solved creative mode experiment, and evidence that the docs are lacking), low enough costs that an error won't bankrupt you, fast enough that blocks can be moved/adjusted (no silk touch needed; note that this implies low explosion resistance if the mining hardness is low), and safe enough that getting it set up wrong won't have you save-scumming.

I'll let someone that is current with these in survival say how many of these points are met.

It says energy is energy is energy.

One thing that I love from Gargoyles: in the episode where Oberon decides to attack, and Oden (Puck) helps defend the tower, he says that whether magical or technological, energy is energy. It can change form or be redirected, but not created or destroyed.

Sure, just as potential energy is not the same as kinetic energy or electrical wattage, you can convert between them. It's not hard to think that the 6 different forms in your wand are different with some way to convert between them, or that there are ways to convert physical and magical forms. There are ways to convert steam into motion (turbines) into electricity (generators) into steam (heating coil in water). Maybe some ways more efficient than others (I think what I described is something like 37% if I remember my carnot cycles correctly)

Also, my servers and play worlds are as casual as you can get and this has never been an issue.

You've got the docs; you know what to do.

 

[Pyure]

Slippery slope. Also EVERYONE will have a leg to argue from if he accepts a balance change like that (and yes it IS a balance change, removing consequences affects balance). So he's giving more ammunition to people he doesn't want to give debate ammo to, AND incentivizing himself through previous actions to do it again. As much as I agree with you that allowing "wuss mode" is a thing that is trivial to implement and good for certain styles of packs, in this case Reika really does have a point beyond "I'm sticking to my principles". I can provide examples/citations of the effects I'm talking about if you'd like.

Its not a balance change, its a balance option. And I maintain that he'd get fewer hassles rather than more by providing it.

Options are always good. I'm tired of the weak arguments I'm hearing to the contrary and I've yet to hear a single thought that would make me reconsider 18 years of professional programming experience.

XCom-like mechanics are hard to balance. You want to make sure that a disaster is survivable; you want to tell people to expect to fail once or twice, minimum.

Odd comparison. I was a huge fan of the original game, and the remakes were "OK". The design was clever in that it successfully implemented the premise that you could die a lot and still win.

That said, the game was built for an entirely different type of play-style, and there was actual save-and-reload in-game. Also, the disasters were not only limited but expected: you might lose one to many soldiers on a mission, and they were replaceable. You were actually supposed to die regularly in that game, and it was never a disaster, just part of the game (unless, of course, you lost the game. I hope you don't make the argument that Minecraft-with-ReC should have a you-lose endgame)

Fundamentally, I'm not attempting to appeal to such hardcore gamers as these (as myself, if you will). There's a large number of casual players that have zero interest in a game where your base can meltdown. None of them are ever going to touch reactorcraft as it stands, and why should they? My goal is to give them a reason.

 

[keybounce]

That said, the game was built for an entirely different type of play-style, and there was actual save-and-reload in-game. Also, the disasters were not only limited but expected: you might lose one to many soldiers on a mission, and they were replaceable. You were actually supposed to die regularly in that game, and it was never a disaster, just part of the game (unless, of course, you lost the game. I hope you don't make the argument that Minecraft-with-ReC should have a you-lose endgame)

Not at all.

The worst thing was finding that when I sent a small scouting mission to mars, to see what it was like, and finding out that when it died, I lost the game.

Never mind that I had a big organization, and was more than able to send a second mission.
THAT was when I did a scum-restore.

Other than that, my only "reloads" were when things went bad from bugs.

EDIT:

There's a large number of casual players that have zero interest in a game where your base can meltdown. None of them are ever going to touch reactorcraft as it stands, and why should they?

Until there was a chunk loader in the pack, I had zero interest in checking it out. I'm still very low desire to check it out, just because of the whole "Has to tick every tick, can't really be turned off" nature of the reactors (please tell me if my understanding of this is wrong).

... Seriously, how about a way to tell if the area is currently "outside of active players", and activate a "shutdown reactors" mode -- in other words, a way to tell if chunks are going to be unloaded, and if so, mark all the reactor cores in that area to stop producing fission/fusion entities until the chunks are reloaded again?

EDIT 2: Right now, I just realized, you could have a system to activate the SCRAM if the player goes outside of the activate range. But that would take time for the cores to cool down, and later time for the cores to activate. Doesn't have the "all/nothing" of minecraft.

 

[TomeWyrm]

You've got the docs; you know what to do.

Better than that, he's the sole architect. No documentation can be perfect, but the architect who is also every other role right to the most menial builder, who routinely interacts with his creation? Closest you're going to come to "perfect" documentation.

You can anyways...

I'm aware that RF > Shaft > RF is possible. I'm currently testing to see if my recollections are accurate or not.

Options are always good.

That's the difference you're trying to debate around, the elephant in the room, your stumbling block. Options aren't always good. Someone has said recently (paraphrased, because I can't find it to actually quote) that RF-ifying RoC would be a bad thing. That is a possible option, and I don't think any of us think that's a good one. Choice can be a VERY bad thing, freedom is the antithesis of security, the freedom to choose is the freedom to choose poorly. In this case, the ability to contain reactor explosions would fix your problem. By the point in time a player should be working with reactors, they should easily be capable of containing those reactors, if you're playing a HQM void map the map maker should have provided a reactor room, if you're playing a more open ended skyblock, you should have contained the reactor. At this point in modded history, not doing that is just plain silly. Why should you expect a NUCLEAR REACTOR to be non-dangerous? You (should here shortly) have the blocks available to contain a reactor problem, if you don't do that then IMHO Darwin (Jungle Rule, Survival of the Fittest, whatever you call it) takes over. Allowing by design the accommodation of overly casual (as compared to a reasonable average) consequence free play spoils the experience for a large portion of players. If there exists a Wuss Mode, then someone is going to use it. If that option becomes well-known, judging by my experience with the minecraft community, that option will become the PACK default. Much like nobody having oregen except COFH or um... (my habit of overhauling any pack I come across if I look at the configs comes back to bite me now. I know there are other configurable options that have become the de-facto standard, I just can't think of them). Which is a design decision that Reika doesn't want, the realism of nuclear reactors being able to meltdown is a core design choice. Containment makes sense, he just hasn't figured out a way to do that without making your server cry and machine choke. That's what is currently being spitballed around right now. Would native ability to fully contain the explosion fit your criteria for inclusion in the pack concept I'm currently calling "spaceships and casuals"?