RC/ReC/ElC/CC Policy Changes

[keybounce]

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)

Cofh has many options for doing different types of oregen.
COG has many options for doing different types of oregen.
I don't know if Better Ore Distribution is updated to 1710 or not.

On top of that, BetterGeo wants to do its own oregen, and other mods use COG to do custom oregen (that's Geologica and ReasonableRealism).

Plus, Forestry has it's own idea of apatite, at least. There's probably other mods that do custom styles of oregen.

The idea that "nobody does oregen except COFH"?

 

[Pyure]

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.

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

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"?

I could probably devil's advocate this and argue that regardless of how insanely stupid it is, an RF choice wouldn't in and of itself be bad. But regardless, since I'm not advocating that particular option, I'll simply dodge clear of your elephant and amend with "I'm intelligent and I know my option is intelligent, and my particular option is always good. Oh, and I lose respect for anyone who says otherwise because I'm elitist like that."

As for fully-contained explosions...I'm not sure. If I could clean them up with an apparatus, and given Reika's recent policy changes, that would actually convince me and many others to play the mod. But it wouldn't work in the pack unless I could use your blast-resistant material to insulate individual parts of the reactor.

Specifically, a lot of players are fond of a 4-quadrant reactor setup, and if I could insulate each quadrant so that an error in one part didn't necessarily destroy the others...maybe.

You're too wily about my pack theme. Only PT crew know it even exists

 

[Padfoote]

Only PT crew know it even exists

And that confirms my suspicion.

Back to lurking.

 

[Pyure]

@Reika, I don't know if it makes a difference, but I'd be fine with prominently posting something to the effect of "This pack has a configuration change in ReactorCraft which disables reactor explosions. This configuration is not enabled by default by the mod and is not the preferred or proper way to enjoy the mod. This configuration option was provided by Reika to facilitate play for younger and more casual gamers."

 

[Reika]

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).

It has changed recently. See a few posts back.

@Reika, I don't know if it makes a difference, but I'd be fine with prominently posting something to the effect of "This pack has a configuration change in ReactorCraft which disables reactor explosions. This configuration is not enabled by default by the mod and is not the preferred or proper way to enjoy the mod. This configuration option was provided by Reika to facilitate play for younger and more casual gamers."

It is not you I am concerned with this. It is a hypothetical future pack whose author may be less knowledgable, willing, or who may simply make an oversight.

 

[TomeWyrm]

Cofh has many options for doing different types of oregen.
COG has many options for doing different types of oregen.
I don't know if Better Ore Distribution is updated to 1710 or not.

On top of that, BetterGeo wants to do its own oregen, and other mods use COG to do custom oregen (that's Geologica and ReasonableRealism).

Plus, Forestry has it's own idea of apatite, at least. There's probably other mods that do custom styles of oregen.

The idea that "nobody does oregen except COFH"?

No, I mean that every major pack disables native duplicate oregen in favor of COFH. I was giving an example of de facto defaults via major packs. It was the only one I could think of at the time. I still can't think of any of the other FTB universal changes right now that even packs like RR3 duplicate.

It is not you I am concerned with this. It is a hypothetical future pack whose author may be less knowledgable, willing, or who may simply make an oversight.

Maybe something along the lines of AgSkies' Forestry? By that I mean a special pack-only version of ReactorCraft. It's a trivial change. Have a NO REDISTRIBUTION warning with it too. Is it possible to have hidden config options? Or you could be silly and name the option B:DO_NOT_CHANGE_THIS_VALUE_IT_WILL_BREAK_REACTORS=false

 

[EyeDeck]

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.

The best simple alternative to the way it works I can think of, if we want radiation entities to be containable, is to spawn each radiation entity at the point of the explosion, then, as mentioned, fire it away from where it spawns (with setVelocity(x,y,z) or something, where x,y, and z are each a random number based on the same number that determines how far radiation can spawn from a failed reactor currently).

At that point you can simulate collision, and make the radiation stop moving after a few seconds by putting a chunk of code in EntityRadiation's onUpdate block to the effect of

if (motionX || motionY || motionZ) {
    motionX *= 0.99D;
    motionY *= 0.99D; Drops velocity by 1% per tick
    motionZ *= 0.99D;

    Block b = worldObj.getBlock(posX, posY, posZ);

    if (b.isNormalCube()) {
        if (b.blockHardness >= 60) { ; might need to add an extra check against a blacklist here so things like other reactor blocks explicitly don't stop the entities, also 60 hardness is arbitrary
            this.setVelocity(0, 0, 0);
        }
    }
}

It would take a bit of trial and error to work out exactly how much velocity to apply to the radiation entity to get it to work the way it does now, but I think it's workable. Oh, and I guess the radiation would leak outside its container slightly, but whatever.

EDIT: I notice after writing this TomeWyrm described essentially exactly the same thing I did.

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?

Another edit: A thought occurs: assuming the above would work to contain all the mess of a destroyed reactor in some kind of ultra-dangerous steel cube, what if ReC whitelisted its TileEntity blocks to work with AE spatial storage? Theoretically one could then suck that ultra-dangerous steel cube up into a spatial storage cell and then jettison it into space or whatever. I imagine Reika would not like this idea though.

 

[Pyrolusite]

Containment is the superior choice. Removing explosions is dumbing down the mod.
I'd be sad to see such an interesting mod becoming casualized because "it's too hard for certain modpacks".

Like GregTech modpacks, they should be constructed with RoC/ReC in mind, if not central to it, not just throw them in and blame the modder for not providing enough options.
You can make any mod "harder" by MineTweaking stuff, but you can't make mods like RoC easier with it because of how different it is.
And it being so much different and powerful is, imo, a sign that you shouldn't just expect the modder to bend to your modpack philosophy.

 

[ljfa]

So, what are we talking about now? One particular feature or the general principle of providing such features in the first place?

 

[Pyrolusite]

So, what are we talking about now? One particular feature or the general principle of providing such features in the first place?

Actually, we should probably explore the "sanctionned modpack" and "radioactivity cleaning"/"containment" track.
The original subject is pretty much doomed to get answers like "omg consulting a modder before screwing his mod ?! 2hard4me 0/10" now.

 

[Pyure]

It is not you I am concerned with this. It is a hypothetical future pack whose author may be less knowledgable, willing, or who may simply make an oversight.

Its them and your concern about them I'm looking to control with the clause. I hope you'll agree its a massive concession considering a) I'm admitting upfront its wussmode, b) I'm clarifying that people shouldn't want to typically play it that way, and c) I prefer not to give specific mods/devs special status.

 

[Strikingwolf]

Just going to point out that someone linked to the power of defaults, which makes me happy

 

[Pyrolusite]

Its them and your concern about them I'm looking to control with the clause. I hope you'll agree its a massive concession considering a) I'm admitting upfront its wussmode, b) I'm clarifying that people shouldn't want to typically play it that way, and c) I prefer not to give specific mods/devs special status.

Telling people that they shouldn't play the mod that way, while enforcing to play it that way on your modpack, is contradictory and ineffective.

 

[Pyure]

Telling people that they shouldn't play the mod that way, while enforcing to play it that way on your modpack, is contradictory and ineffective.

Amusing opinion noted.

 

[keybounce]

I could probably devil's advocate this and argue that regardless of how insanely stupid it is, an RF choice wouldn't in and of itself be bad.

Hmm. Then allow me to try that position.

The real goal of Reika, with regard to the machines and power consumption, is tech gating. If, for example, no matter what kind of power you had, you had to have bedrock dust in the high-end equipment, and a bedrock breaker needed some material that was produced by a jet engine, (etc), then you could have a pure RF mod without breaking the gating chain.

EDIT: Ok, so either of the two jet fuel engines could be used to run the bedrock breaker (one just more slowly than the other). So maybe this material that the bedrock breaker needs should be obtained from the fractionator during production of jet fuel. Etc. down the line.

Pure RF? Sure. But you still need the materials from the tech tree.

 

[Pyure]

Hmm. Then allow me to try that position.

The real goal of Reika, with regard to the machines and power consumption, is tech gating. If, for example, no matter what kind of power you had, you had to have bedrock dust in the high-end equipment, and a bedrock breaker needed some material that was produced by a jet engine, (etc), then you could have a pure RF mod without breaking the gating chain.

You're ballsier than I am

The obvious counter-argument would be that the other goals of Reika include having machines that aren't simply magical fuel-in-RF-out fountains. Multi-dimensional power requires a bit of forethought and infrastructure considerations.

And while I hate some machines as being a bit magical in nature (the dc generator thing, the steam generator, the AC generator thing....all of which I *think* emit power with no fuel; I could be wrong) this problem is largely mitigated by the junction cap (which solution I also don't care for since its also somewhat magical in nature.)

If we're really trying to argue that position, the best I could probably come up with is that deviating from that vision isn't in and of itself bad. Just kinda boring and dumb.

 

[Reika]

The best simple alternative to the way it works I can think of, if we want radiation entities to be containable, is to spawn each radiation entity at the point of the explosion, then, as mentioned, fire it away from where it spawns (with setVelocity(x,y,z) or something, where x,y, and z are each a random number based on the same number that determines how far radiation can spawn from a failed reactor currently).

At that point you can simulate collision, and make the radiation stop moving after a few seconds by putting a chunk of code in EntityRadiation's onUpdate block to the effect of

if (motionX || motionY || motionZ) {
    motionX *= 0.99D;
    motionY *= 0.99D; Drops velocity by 1% per tick
    motionZ *= 0.99D;

    Block b = worldObj.getBlock(posX, posY, posZ);

    if (b.isNormalCube()) {
        if (b.blockHardness >= 60) { ; might need to add an extra check against a blacklist here so things like other reactor blocks explicitly don't stop the entities, also 60 hardness is arbitrary
            this.setVelocity(0, 0, 0);
        }
    }
}

It would take a bit of trial and error to work out exactly how much velocity to apply to the radiation entity to get it to work the way it does now, but I think it's workable. Oh, and I guess the radiation would leak outside its container slightly, but whatever.

EDIT: I notice after writing this TomeWyrm described essentially exactly the same thing I did.


Another edit: A thought occurs: assuming the above would work to contain all the mess of a destroyed reactor in some kind of ultra-dangerous steel cube, what if ReC whitelisted its TileEntity blocks to work with AE spatial storage? Theoretically one could then suck that ultra-dangerous steel cube up into a spatial storage cell and then jettison it into space or whatever. I imagine Reika would not like this idea though.

@Celestialphoenix had a similar idea here that might well work. It allows me to use the MC collision engine to control where radiation can go, but without introducing the problems of an asynchronous raytrace or of making radiation entities collideable.

However, there remains an unsolved problem: Radiation itself has AOE effects. It is not contact with a radiation entity that causes blocks to convert, or the poisoning to be applied; they randomly pick nearby coordinates or entities to apply their effect to. The range of that "nearby" is a function of the radiation "size" - usually about 16 blocks. This means that even containment would be somewhat insufficient to fully contain the effects. The only way I can think of to avoid this is to put the raytrace there, but that is even more expensive than the spawning algorithm, because it is called much more (each of say 20 entities calling it every few seconds) and for a much longer time frame.

It does halve the effective range of radiation effects - uncontained, the entity spread is about 16 blocks range, plus another 16 for the AOE.

Also, an aside: Having all the radiation contained in an area that you cannot really enter makes cleanup much more difficult than loosely spread radiation would be.

Containment is the superior choice. Removing explosions is dumbing down the mod.
I'd be sad to see such an interesting mod becoming casualized because "it's too hard for certain modpacks".

Like GregTech modpacks, they should be constructed with RoC/ReC in mind, if not central to it, not just throw them in and blame the modder for not providing enough options.
You can make any mod "harder" by MineTweaking stuff, but you can't make mods like RoC easier with it because of how different it is.
And it being so much different and powerful is, imo, a sign that you shouldn't just expect the modder to bend to your modpack philosophy.

This.

So, what are we talking about now? One particular feature or the general principle of providing such features in the first place?

Given they are both related by overarching topics, either one is more than acceptable.

 

[Pyure]

This.

Seriously? It didn't even qualify for a response from me.

Player: GameX would be dumbed down if you made it accessible to casual and younger players.

Dev: I'm providing an option that lets casual and younger players enjoy the mod. Its off by default.

Player: My game is ruined! Even though I don't plan on actually using the config.

Dev: OK but don't forget that because all pack-makers are inherently stupid they're all going to use my new config and ruin your game. Presumably you'll a) decide to play those packs for some reason, and b) forget how to revert back to the default.

Player: GameX is stupid now.

Apparently sailing is dangerous because the world is flat. And fortunately I'm disinclined to worry about what these sorts of people think.

@Pyrolusite, out of respect for past congenial conversations:

Containment is the superior choice. Removing explosions is dumbing down the mod.

Smart. Yes, its "dumbing" down the mod.

I'd be sad to see such an interesting mod becoming casualized because "it's too hard for certain modpacks".

You're far, far more clever than this.

 

[Strikingwolf]

However, there remains an unsolved problem: Radiation itself has AOE effects. It is not contact with a radiation entity that causes blocks to convert, or the poisoning to be applied; they randomly pick nearby coordinates or entities to apply their effect to. The range of that "nearby" is a function of the radiation "size" - usually about 16 blocks. This means that even containment would be somewhat insufficient to fully contain the effects. The only way I can think of to avoid this is to put the raytrace there, but that is even more expensive than the spawning algorithm, because it is called much more (each of say 20 entities calling it every few seconds) and for a much longer time frame.

I believe once you hit a wall and contain the entity you could register where the wall is, could you not? Then just do some parsing around your entity for blocks in the range (once you hit a block in one of the directions it can spread you can ignore that direction for that spot). Then when it picks it can do that without spreading through walls.

Now for the interesting part of my post

I had resigned myself to not contributing to this discussion again, but I'm going to go back on that. Looking back on the discussion had I first want to bring up a few points. Then I would like to introduce a third solution

• Neither side wants to give up their position, no matter the arguments against it
• Looking at the discussion in full it is apparent that the answer is probably on neither side
• The main points for customization are natural evolution, the right of the player to decide what they want, and customization does not affect regular users besides defaults (community-set or otherwise)
• The main points against are the configuration becoming the standard, watering down of the original by configuration, and taking away power from the modder over their design

In an ideal solution the mod

• could naturally evolve
• the player would have full control over customization
• all types of defaults would need to be controlled by the modder
• non-modified would need to be the standard
• modder can control evolution to a degree

Due to the effect of modpacks and popularity it seems that this ideal option is impossible to construct...however, I believe there is a way to at least approximate it, here is how I think it would go

• Pulling an idea I had from an earlier post. Modder is allowed to curate pull requests and they are added given enough votes. This gives the modder the power to veto any ridiculous PRs or PRs that completely subvert the mod.
• Defaults are controlled by modder.
• Forks must be re-merged (if point one passes) into the original mod. This way modified versions of the mod cannot become standard.
• Whenever a config option is changed the user is greeted with a message for the first time they login. This message tells them that their has been a modification and that this is not the standard experience. It then gives them a button to press to enable the standard experience. It also tells them of a command to toggle default vs. modified. This allows the user to know that this is not the standard and that there is a quick way to enable the standard experience. This both sets the standard to the default and allows the user full control

This of course needs to be tightened up, but I would like to hear both side's opinions on the idea. If there are problems with the solution I would like them to be solved together, not left as binary choices with no solution.

 

[Pyure]

Due to the effect of modpacks and popularity it seems that this ideal option is impossible to construct...however, I believe there is a way to at least approximate it, here is how I think it would go

• Pulling an idea I had from an earlier post. Modder is allowed to curate pull requests and they are added given enough votes. This gives the modder the power to veto any ridiculous PRs or PRs that completely subvert the mod.
• Defaults are controlled by modder.
• Forks must be re-merged (if point one passes) into the original mod. This way modified versions of the mod cannot become standard.
• Whenever a config option is changed the user is greeted with a message for the first time they login. This message tells them that their has been a modification and that this is not the standard experience. It then gives them a button to press to enable the standard experience. It also tells them of a command to toggle default vs. modified. This allows the user to know that this is not the standard and that there is a quick way to enable the standard experience. This both sets the standard to the default and allows the user full control

This of course needs to be tightened up, but I would like to hear both side's opinions on the idea. If there are problems with the solution I would like them to be solved together, not left as binary choices with no solution.

I don't want to see any dev (Reika or otherwise) feel compelled to subject his work to any kind of democratic process. Its his work, end of story. However: this is altogether different from hoping that dev's have the capacity to evaluate ideas, perform basic cost/benefit analysis, and implement properly as desired.

Reika has refuted any number of my ideas in the past. Some of them he's pointed out errors in my proposal, and I've either gone back to the drawing board with the new information or abandoned them. So far there have been zero logical arguments other than "I don't wanna" for the configs in discussion. ("I don't wanna" being pretty fair and logical btw. No sarcasm.)

There's a lot of repeated talk using the exact same arguments ad nauseum, but those have already been fully debunked as illogical. Not everyone grasps this of course, but not everyone thinks the world is round either.

As for your last point, regarding notifying the user about standards/defaults/whatever: normally this wasn't my preference but I'm strongly in favour of this idea in Reika's case specifically. He's extremely sensitive about the gameplay tweaks and I feel it could ameliorate his concerns if there was such a disclaimer.

I dunno if your button idea would work in production? I don't think you can change configs at that point, but I'm not a modder.