Fission reactor discussion

GT6 reactors are out and it’s time to discuss. While the new nuclear fission reactors in GT6 seem complicated at first, they are really simple. Too simple imo. For building the most efficient reactor setups, there are very simple rules:

  • If the fuel used has a factor lesser than 1/8, surrounding fuel rods with absorber rods yields the most fuel efficiency.
  • If the fuel used has a factor of 1/8, surrounding your fuel rods with absorber, reflector or other fuel rods yields to the exact same fuel efficiency.
  • If the fuel used has a factor greater than 1/8, surrounding your fuel rods with reflectors or other fuel rods yields the most fuel efficiency.

This makes designing reactors very simple and as the energy output is constant, there is no need to control the reactor rods other than to shut down the reactor.

Even if different coolants are added changing the reactor mechanics, there are fundamental problems and restrictions with the current reactor:

Measuring problem
There is no way to measure the neutron counts with machines to control the reactor accordingly, making more advanced, non constant, mechanics impossible to implement.

This problem isn’t as easy to solve as simply adding a new sensor block, as each reactor core has neutron counts for four rods. For one sensor to monitoring four fuel rods is theoretically possible, but the output information for each rod is limited to 1 bit (redstone only allows for 4 bits). So the sensor would need to work conditionally, outputting at configurable neutron counts greater or lesser than. But the input of the condition neutron counts would be hard to archive without a GUI, especially when individual values for all four rods would be allowed.

Side/size restriction
So this would allow for simple reading, but the presence of the sensor causes another problem, there are no free sides on the reactor block anymore, the four horizontal sides are in most cases bordering other reactor cores, one side is dedicated to outputting the heatant and thus occupied by a pipe and one side is used for the sensor. There is no place for a red alloy wire. Theoretically, there could be a redstone mode selector cover directly under the sensor, which could receive its signal and thus allow control of the reactor rods this way, but this severely limits the use of the information, to just configuring a maximum or minimum neutron count for each individual rod, which causes it to retract the rod, making it less about controlling the reactor and more about configuring it, not to mention not being able to shut it down or exchange the fuel.

It’s of course possible to use universal extenders to get a little more space and use the sides of the most outer cores, but it’s obvious that the reactor does not have enough sides. I actually like this, as it puts a flexible size restriction to reactors. A 44 and a 3X reactor with universal extenders is the limit for having rod access on all reactor cores, as well as read and write on them.

Critical fuel problem
All fuel currently added have a factor lesser than 1/5 and are thus subcritical. If a fuel with a factor bigger than 1/5 would however be implemented, it would cause the count of neutrons to increase every tick, if the neutrons were to be reflected onto it. This dynamic neutron growth would need reactors designed to control the rods, to not let the reaction get out of control. However, because the fuel efficiency of the fuel is the amount of neutrons emitted each tick, and this amount raises constantly, it would allow any fuel with a factor bigger than 1/5 to have an infinitely exponentially growing efficieny.
This makes critical fuels broken and thus impossible to implement in the current system.

Possible solutions/redesigns:

Another solution for the measuring problem would be to make reactor cores Open Computers peripherals, allowing for reading and using the exact neutron counts with the computers. This is obviously far from an ideal solution, as it depends on another mod and thus creates a soft dependency.

One thing that could be done to improve the system would be to make reactor cores only have a maximum of one rod, instead of four. This would enable much finer control and measuring of the reactor, as the rods don’t just allow for binary states anymore, but up to 16 states, usable for the insertion height of the rod. Automation via item pipes or hoppers may also be possible this way, although it may be intentional that fission isn’t fully automatable. The model and texture of the reactor would however need to be changed and a change of state would also probably require a change of the model, not just the texture (although it could be archived with just texture changes, a model change would be easier to implement, as it’s just).

With rods having multiple stages of insertion, like half inserted absorbtion rods only absorbing half of the neutrons, it would make sense to have neutrons travel further than one space. This allows for the remaining half of neutrons not absorbed to travel further, potentially hitting another fuel rod. Inserting the absorbition rod fully would however stop the neutron exchange between the two rods completely and therefore slow down the reaction significantly.

Random fluctuations in the neutron count would be a feature that makes observing the neutrons much more useful, as it would make high neutron count critical reactors require constant observation based regulation of the control rods, to keep the reactor from spontaneously turning into a bomb.

Reactors would now need to be bigger, but the side restriction is also alleviated a bit, as cores with absorber or reflector rods don’t need top access, because they don’t need refueling, and they don’t need read access, only write, as their neutron value can be calculated from the the surrounding reactor cores neutron counts.

To make critical fuel possible, the fuel durability system needs to be slightly overhauled. The durability shouldn’t just drop at a constant rate, but per reaction, i.e. per neutron produced. A fuel efficiency could be re-added in several ways: A static additive to the durability loss, i.e. fuel loosing n + 10 durability per tick (n being the number of neutrons produced). It would be mechanically similar to the energy loss on cables. This fuel loss (maybe calling it “natural decay”) could also be fuel specific, adding another distinction between fuels.

Efficiency could also be added by a multiplier for the durability loss (n * multiplier), the multiplier being dependent on the number of neutrons produced. The multiplier could be smaller the more neutrons released, but it could also be dependent on a fuel specific optimal neutron emission. I would personally like to have both this mechanisms, but find the multiplier more appealing, because it allows for some fuels with special conditions other than getting the most neutrons for the best efficiency.

If you got this far reading this wall of text, you should also post your opinion and ideas on the subject below.


Yep, the whole thing is a Gameplay Experiment if anything.

Yeah I didn’t even add the Geiger Counter yet. And yeah it would just add up all 4 Neutron Counts, so you would need to do Maths to find out where to limit the Neutron Amounts.

There is a reason the Changelog states you can do all sorts of whacky bullshit with Extenders :wink:
Also You can transmit Redstone through GT6 Blocks using special Redstone Transmission Covers so you can definitely transmit Redstone from the horizontal Sides of the Reactor.

At least with the current individual Rod Maths. That is why I’m planning to have different Modes using Coolants as sort of Selector. I could just make it do +1 Total Neutron every tick, that way it wont go critical too fast and cause the reactor to just be a block-updatey flickery mess.

That specific Model Change is easy to do, I would just need to change one Texture and then make it render only one Rod centered. You might have noticed Rods can be placed in world too. :wink:

Hrrm RNG you say.

I could make inactive Rods still lose durability that would be a way. But then I need to prevent automation from extracting Fuel Rods until they are depleted.

I definitely got a few Ideas from this, including the Single Slot Type of Reactor, which I only didnt do last week for aesthetic reasons, even though it’s like super easy for me to do. ^^


That won’t block the neutrons on that side? Would expect it to. Though would be nice if it didn’t, lol. Consistency is nice though.

I kind of like the idea of single-rod blocks at least to start with, easier to automate pre-computers or so. 4-rod blocks would be nice when you have better automation capabilities, like via OC computers.


Covers dont block anything in GT6 anymore. Unless its Shutter Covers.


Sounds reasonable, but with randomness thrown into the mix there would be some uncertainty, but I think that would be manageable. I like the data to be a bit obfuscated, so simple redstone connection loops aren’t enough and there is some challenge and use case for advanced redstone engineering or computers.

For the sensors itself, I would recommend being able to set a minimum and a maximum neutron count, the minimum signifying a redstone strength of one and the maximum (and above) a strength of 15, neutron counts between the two values get interpolated redstone strengths. This allows some degree of finer measuring, without making the sensor terribly more complicated.

I think completely different systems for different coolants may not be such a good idea, as it makes learning to build reactors very complicated, potentially bloats tool tips and is very hard to balance. There needs to be some common ground, the coolants only adding their unique twist onto the system.

Fuels having different factors across different systems (or not having a factor at all because the system is so different) would be very confusing, just because the current system doesn’t allow for factors greater than 1/4 (I checked it this time, 1/5 was false). That’s why I think changing how the durability for fuel rods works would be the best way, as it doesn’t change the system so that current setups would break, while also allowing for fuels with a factor greater than 1/4.

But things going critical too fast is a valid concern, as the neutron economy gets updated every tick. When having a fuel rod with an emission and self of 128 and a factor of 1/4 surrounded by reflectors, it would take two seconds for the neutron and therefore heat output to rise to 20608. After 47 seconds the heat would be so big, no pipe could transfer the coolant needed to cool the reactor.

Reducing the neutron counts growth artificially however would make high neutron economies have the same level of risk as low ones, because there is no exponential growth. A better way to solve this would maybe to change the update-rate of the reactor, similar to the IC2 reactor, which only updates once per 20 ticks. The update rate could also be a game mechanic the player can control, dependent on the coolant.

I meant the extra durability loss only to be added when the rod is active, when it normally loses durability, not when it’s inactive. Wires not being used don’t consume electricity either.


The current fuel rod lasts too long to break the balance… A fuel rod only needs 0.5 units of material, but even the shortest thorium-230 rod has 10,000 minutes, 24x60 = 1440,10000÷1440 = 6.9444… That is to say, even if I play 24 hours, a thorium-230 fuel rod can be used for a week, which seriously affects the balance…


Why is this a problem? a typical fission reactor today with really old designs (average age is 30 years now) need to refuel every 2 years. The depleted uranium-238 traveling wave reactor proposed by TerraPower is even said to be able to sustain its own operation without refueling for the entire life span of the reactor (40-60 years).


It being somewhat realistic is not the problem, but it overpowering other generators or even other possible reactor coolants is a game design problem. Since reactors scale very easily, they can output almost unlimited amounts of power already, while also having always no fuel consumption.