An off switch is a critical functionality for any jetpack, yes. Without an off switch I'd rather wear no jetpack at all, and only pull it out of storage for long-distance journeys.
IE creosote is pretty much a straight clone of Railcraft's creosote - produced by literally the same machine using the same input resources. In Railcraft, creosote oil is pegged at 1/10th the fuel value of Forestry ethanol. Ethanol is supported by the semifluid generator and produces 32,000 EU per bucket. You could support both Railcraft and IE creosote in this way.
IE's diesel generator supports both its own biodiesel as well as traditional Buildcraft fuel. While it does not support Forestry's ethanol, the balance between biodiesel and Buildcraft fuel is about 3:1. Unfortunately, IE also has its own Ethanol resource - and this is an ingredient to making biodiesel. I don't know if Forestry's ethanol can be substituted. Plant Oil and ethanol are used in a 50/50 mixture to make biodiesel, under additional energy input. Overall I'm not sure if it's worth giving these two burn values, since they're not meant for any other purpose in IE than to be made into biodiesel.
So, to sum up,I suggest:
IE Creosote: 3,200 EU at 4 EU/t
Railcraft Creosote: 3,200 EU at 4 EU/t
IE Biodiesel: 42,000 EU at 32 EU/t
And if you want to:
IE Ethanol: 32,000 EU at 16 EU/t
IE Plant Oil: 16,000 EU/t at 8 EU/t
...but these values are just guesstimated and do not take into account the difficulty of producing them, which I don't have memorized.
The liquid fuel heat generator seems to mirror the semifluid generator's fuels and output, so it should probably get them too.
Thermal Expansion's new fuel types are listed as follows:
Liquid Coal: 500,000 RF/b
Naphtha: 1,250,000 RF/b
Refined Fuel: 2,000,000 RF/b
Tree Oil: 1,000,000 RF/b
...in a compression dynamo. The same engine pulls 500,000 RF out of a bucket of Forestry ethanol.
Ergo, I suggest:
Liquid Coal: 32,000 EU at 16 EU/t
Naphtha: 80,000 EU at 32 EU/t
Refined Fuel: 128,000 EU at 32 EU/t
Tree Oil: 64,000 EU at 16 EU/t
These values look high, compared to the rest of the semifluid generator's portfolio, but there's another indication that this is balanced: making a bucket of liquid coal consumes 10 pieces of coal, which would be worth 40,000 in a basic generator. So burning liquid coal is actually a loss. Then, you can refine two buckets of liquid coal into a bucket of naphtha, which makes naphtha equivalent to 80,000 EU in a basic generator - here you break even. Then you can further refine the naphtha into refined fuel, which is still equivalent to 20 coal pieces, but now exceeds their burn value after three intermediate processing steps that took power. Seems fair to me.
Tree oil could be dropped to 32k since it can be generated passively, if you feel that is fairer, but it is only generated at 1 mB/s per machine dedicated to the task.
Thanks for the explanation! I can't check the mod version right now since I'm not home, but the modpack I'm using last updated its mods on June 20th, a couple days before I downloaded it. Browsing the IC2 Curseforge, it seems the most likely candidate is industrialcraft-2-2.6.234-ex110.
Want me to test this with a specific newer version?
Immersive Engineering: Biodiesel and Ethanol (maybe even Plant Oil?)
And creosote, please. I don't care how inefficiently it burns. I just want a better way to use it than a void pipe.
(And no, crafting treated wood doesn't use up nearly enough of it...)
If I observe the three batboxes in my base that feed power into my basic machines, I notice the following: from one batbox to the next, energy is transferred in batches of 32, like I would expect - even if the input from power generation is lower than 32 EU/t. The batbox waits until it can assemble a full batch to send. However, if a batbox transmits to a machine that is topped off but currently processing, it makes an effort to replace every single missing energy unit instantly. It doesn't wait until it can send a batch of 32. I have a macerator that is 4 blocks away from the batbox that feeds it; it runs at 2 EU/t, and the batbox replenishes it to full every single tick.
So, do I understand correctly that the batbox sends one 2.8 EU packet every tick to the macerator, which receives 2 EU/t after accounting for cable losses? And because the batbox does this instead of sending full batches of 32 EU, I have a whopping 40% energy loss over just four cables?
If yes, is there any way to force the batbox to only send out full batches?
43 is pretty good, not sure if anyone can beat that.
If anyone has any suggestions on how we could better improve on our setup, please let me know. I am eager to expand and optimize this setup as best I can!
Your setup raises a few questions in my head.
For starters: 22 liquid heat exchangers per reactor? That's a wee bit excessive. Those are capable of 2,200 hU/t in terms of heat throughput. But each of your reactors only outputs 456 hU/t. You should therefore be able to get by on 5 exchangers per reactor. Heck, you could take the 22 exchanger bank from one reactor, remove three exchangers, and use the remaining 19 to cool all four reactors at once!
Second thought: if reactor #3 has consistently less heat output than the others, but uses the same blueprint, then you made a mistake in inserting the components. One or two of the heat vents aren't getting any heat shuffled to them because something is misarranged compared to the blueprint.
Third thought: your reactor blueprint contains two advanced heat vents that literally do nothing, even when everything is inserted correctly. They are in the top row, in the fourth and sixth slot. Since advanced heat vents cannot draw heat from the core, and there are no heat exchangers touching these two vents, they sit idle even when the reactor is under load. You can remove them with no adverse effect on reactor operations, which saves you eight advanced vents worth of construction materials across your four reactors.
Fourth thought: your reactor blueprint as a whole is no good. I don't mean to be disrespectful to whoever came up with it, but viewed objectively, it performs very poorly for its build cost; there are reactors half the price with more throughput. And I'm going to try and explain to you why that is.
You have a fuel rod setup that produces 2048 hU/t, but your cooling setup only transfers 456 of that - barely a quarter - out of the reactor and towards the power production. Which is the reason you have to run it pulsed. But then why do you have such a massive fuel rod setup in the first place? It even has active running costs, due to the quad rods and especially the thick reflector. Like, you could remove the central cross of four quad rods and the reflector... just remove them outright, and the reactor would still faithfully output the same 456 hU/t. In fact, it would still need to be pulsed, because the four outer quad rods on their own still output 768 hU/t.
As for pulse configurations in general: people use these because they want to run a fuel rod setup that is impossible to stabilize on internal cooling without runtime pauses. But this does not increase your power production output. A reactor that runs on 500 hU/t with 100% average uptime produces exactly the same power output as one that runs on 1000 hU/t with 50% average uptime. Therefore, you don't use pulse configurations to maximize power throughput. Instead, you use them to maximize fuel rod efficiency. As efficiency increases linearly, heat output climbs exponentially, so if you really push your fuel rods to those 5's, 6's, or 7's in efficiency, keeping them cool may become impossible. At that point, you start pulsing. You accept a penalty in power throughput in order to maintain the highest possible efficiencies for your fuel rods.
However, your setup isn't doing this. Your setup runs at efficiency 3.5, and uses lots of fuel rods instead. Which means: your setup is a power throughput configuration. In other words, the kind of configuration you should never be pulsing. Now consider the fact that there are existing reactor designs that transfer over three times the heat of your setup towards power production... with a higher fuel rod efficiency than the build you have here... while also running continuously, no pulse automation required... and you should start to see why I am unfortunately not impressed with your setup
Additionally, your setup uses extremely expensive components without regard for whether less expensive ones might have done the same job, and it arranges them poorly. You have heat exchangers next to heat exchangers in multiple places, which do nothing but shuttle heat back and forth between them, instead of actually providing cooling. Also, the two heat vents that don't do anything (see point three, above).
I'll gladly suggest some alternative designs to you, but you'll have to tell me what you're actually after. Do you want to maximize efficiency, because you are super short on uranium, which should never happen with normal IC2 ore spawn rates? Do you want as much power throughput as possible in order to feed your base's energy needs? Or do you want to burn through as many fuel rods as possible in order to rapidly obtain useful amounts of plutonium?
EDIT: for what it's worth: I really dig your reactor room! It totally looks the part, and everything is clean and organized.
Those probably won't work out, I'm afraid. The smallest step down is converting the dual rod into a single, and that will drop heat output to 668. Upgrading to all quad rods would increase the heat load to 816. Placing the dual rod in the middle of the T-junction and having quads all around would drop the heat down to 600, even.
You are fundamentally limited in how much heat you can dissipate by the number of OC vents you have in any given design, since those are what primarily pulls the heat from the core (where the fuel rods dump it, since there are no active adjacent components). Each vent pulls 36 heat. However, it can cool only 20, so it needs to be surrounded on all four sides by component vents to avoid meltdown. That's how you get the checkerboard pattern you see in almost any reactor design. At the edges of the the field, there is no more room to fully enclose the OC vents, and so you have to remove some OC vents and some component vents to add heat exchangers and advanced vents instead, which handle the excess load from the not completely stabilized OC vents. However, doing so costs you both cooling capacity and core transfer capacity.
This design here has room for 19 OC vents: 19x36 = 684. Additionally, there are three advanced and two basic heat exchangers in the grid. With the basic ones able to do 4 and the advanced ones able to do 8, they are what makes up the 20 missing core transfer not handled by OC vents. In fact, they could make up as much as 24. Which happens to match the excess vent cooling capacity. (For that reason I was able to use a component exchanger without core transfer in one spot, to save cost. The extra transfer of an advanced vent would not translate into extra cooling because the vents are already maxed out.)
The fuel rods need to be surrounded on all sides by passive components (things that don't accept heat, like component vents), so they dump their heat straight into the core. If an active part was adjacent to a fuel rod, it would receive all of the heat output of that rod and just melt, because these are big quad rods running at elevated efficiencies. Now, we have already established that this T-shape can't produce other useful heat values (see the start of this post). However, if you go and start allocating additional slots to fuel rods - or even try to change their shape into a square - you have to break up the cooling system. The square is particularly bad because you want that square surrounded by passive components, but you want those passive components in a checkerboard pattern, not in straight walls. Any change in the fuel rod configuration, no matter how you twist and turn it, results in the loss of at least one OC vent.
And that lost vent will drop the cooling by at least 20 (likely more, since you are likely to lose a component vent as well), and what's more important, it will drop core transfer by 36. So instead of 708 core transfer, you will end up with... drumroll... 672, and you're back where you started. It's no coincidence that precisely that number showed up, because the number of OC vents in any given design is just that defining of its performance.
TL;DR: there's no room (literally) to tweak this design further, especially not by small heat steps. And since this is one of the very few configurations that can safely fit 19 OC vents without any one of them melting, you're not going to be able to find many (if any) different setups of similar potency.
If you have a higher heat reactor that only uses IC2, I want to know!
Hmm! Well, I am fairly rusty, but if memory serves... Unless things have changed more than I am aware of, you should be able to safely exceed 700 heat per second.
*goes to fiddle with the planner for a while*
Okay, here's one variant that does it. 0303030C0D120D0C0D0C020C0D0C0A0C0A140D0C0D0C0D0C0D0C0D120A0C0D0C0D0C0D0C0D0C0A0C0D0C0D0C0D0C0D120D0C0D110A11
At efficiency 4.43, 310 EU/t and 14 fuel rods, it isn't all that different from the "Highest Overall Efficiency" reactor at 4.67 / 280 / 12. But with two extra uranium input for worse efficiency and a power output increase barely worth mentioning, people who are concerned about efficiency would never use it - and those who wanted raw output, or plutonium, have much better options too. So a design like this was never really good for anything, and for good reason. There are various ways in which you can arrange fuel rods; some configurations can have the same efficiency and the same power output, but differ in the amount of cooling required. Obviously, those with the higher cooling requirements for the same stats never see use. This reactor uses such a less optimal arrangement.
However, if it's exclusively heat that you want, the less effective fuel rod design can become the better one. In this case, you get a fluid reactor running at a blazing 704 heat per second - or rather, 1408, after the fluid reactor bonus. Yields a total output of 28.155.058 heat per full cycle, compared to 26.876.784 for the hottest among your designs. Of course, it uses almost twice as much uranium per cycle... but, on the upside, it does not require a single reflector. In fact, adding a reflector would only lower the heat output.
However, I think your logic is off on one point: the reactor generates 648 heat each tick, but with 18 overclocked heat vents, none of that heat is accumulating in the core while those last. The heat is building up in that corner OC heat vent, because with only 2 adjacent component heat vents, that's only 28 heat dissipated from it per tick.
My logic is not off - I completely agree with you on the above point. I now accept that this setup is bug-free. If I didn't make myself clear enough, I apologize.
When I talked about the planner showing the wrong thing, I chose to examine the case in which the corner vent was removed (as stated), because I thought it would make a better example.
I'll raise an issue on github tomorrow, sure.
That design uses heat exchangers, which complicate things - the descriptions on the wiki don't adequately explain them, based on what I found when I decompiled the mod a while back, so I got special permission to adapt the decompiled code for my planner. However, none of them are adjacent to the failing overclocked heat vent.
They're not really that arcane. They just look at the heat level of themselves and all components they are able to interact with (which may or may not include the reactor core), and then move heat around between all of these reservoirs with the aim of balancing them out percentage-wise, up to the limits of their transfer capacity.
I started to explain to you here why I specifically used component exchangers here - because they don't interact with the core. In this whole design, only the OC vents draw heat from the core. No other part does. Then I did some math, and it occurred to me what the problem might be. Namely, there are 18 OC vents in this design. Each draws 36 heat. 18x36 = 648. The reactor also outputs 648 heat. So, contrary to my initial assumption, the corner vent is actually forced to draw its full load. There is no bug with IC2 here.
However, the output of your planner is not clear here. If I remove the bottom right vent, the planner says that there is 23 excess heating. However, what it actually should say is that there is 36 excess heating, because that is the unhandled amount that accumulates in the core every second. Additionally, the parts claim that they are cooling more than they actually do. It says that 625 out of 628 cooling is happening. Which makes sense at first glance, because one OC vent was removed, and therefore 20 vent cooling went away: 648-20 = 628. However, the 17 OC vents only manage to draw 612 heat from the core each second. How can the cooling system run only 3 points below capacity, when each turn it is fed 16 heat less than its capacity? I went and clicked the little "i" buttons for each active component, and indeed: all of them except two claim to be fully loaded. One is a component vent at 5:7 (row:column), which claims 14 of 16 capacity; the other the component vent at 3:5, which claims 15 of 16 capacity. Three short of maximum. But there's not enough heat for that!
So the actual thing that the planner should display in this case is both 36 excess heating and 19 excess (or better, "unused") cooling, at the same time. And the components should adequately reflect if their turn in the tick order comes up and there is no heat for them to interact with.
So, umm. Yeah. Consider it a bug report?
Oh, looks like the dev team ended up agreeing on the cost issue:
"Fixed reactor pressure casings being 4x too expensive" - from a build on September 1st
I'm currently playing in 1.10.2, and I have no mods other than IC2 that spawn lead. I'm running two normal miners in parallel; each one pulls up a two-digit amount of lead ore per run. I'm using standard ore density settings. Why are you getting so much less lead?
It should probably be noted that I'm mining from the surface, so around y=70, not 50. Lead ore does spawn this high up; I'm getting it at all altitudes, much like uranium (just more of it). Maybe you need to place your miners higher up.
Also, the OV scanner in my game reports a range of "12 blocks" (actually 13), not 9 like it used to. The wiki doesn't reflect it, but the tooltip of the scanner ingame says so - and when I tested it in a creative world, I found that the miner indeed digs 6 blocks out in all directions, not 4 blocks like it used to in the past. Because of how surface area works, this is a huge increase: 9x9 = 81, 13x13 = 169. The miner now reaches slightly more than twice the area in one run. If your build also has these enlarged scanners, and you keep spacing the miners apart by 9 blocks instead of 13, that means that a significant part of the miner's area is overlapping the already depleted previous area, and you're getting less ore per run. Check your scanner stats and if necessary, space your mining runs further apart.
Also, I built large reactors in survival mode several times in the past. It's not nearly as impossible as you make it sound... you just need a big enough mining operation.
In 1.6.x, I built a combo-wombo piece made out of eight individual three-chamber reactors, which I dubbed The Heart Of The Mountain. Now that gobbled up some lead, I tell you!
It even ran MOX too - eight times this design: 000C0A0C0A0C0000000C0A140A140A0000000A1404050A0C0000000C0A0505140A0000000A140A140A0C0000000C0A0C0A0C00000000
Anyone crying for diamonds yet? Was worth it though, this thing pumped out over 4,700 EU/t with all eight units under heat, which is why I had to have four parallel HV cable lines terminating in a dedicated MFSU each (because I clearly hadn't used enough diamonds yet) followed by a massive array of voltage transformers splitting and routing the power around my various consumers. Also, you know how you get hurt a little bit when approaching a reactor above 7000 degrees? This miniature sun of mine would hurt you eight times per pulse. A friend made the mistake of ignoring the array of visitor hazmat suits I lined up along the heavily secured entrance tunnel, as well as the big warning sign and the Nuclear Control displays clearly showing the temperature readings. He was dead before he realized what was happening
In 1.7.x, I built a full scale fluid reactor running on this classic design: 030C0D140D0D0C0D00000C0D0D0C0D0D030D000D030D0D030D0D0C0C0D0D0C0D0D0C0D000D030D0D030D0D030D000D0C000D0C000D0C
Along with the necessary heat exchanger setup, of course. Used stirling generators because the steam turbines were buggy at the time. I didn't play long enough on that server to get enough plutonium for a six-chamber MOX setup though...
Hey Mauve, I don't suppose you could help me with my confusion above? Considering you wrote the planner, you must have some insight into ghow the components tick inside the reactor nowadays... (I hope )
...Okay, folks. Riddle me this.
The overclocked vent in the lower right corner fails. Ordinarily, this would be expected; it is only flanked by two component vents, so it can dissipate only 28 heat, while drawing 36.
HOWEVER! This design has 5 excess vent cooling. Reactor components are supposed to tick one by one, row by row, top left to bottom right. By the time it is that vent's turn to tick, it should not be able to draw 36 heat, because it is the very last component in the tick order. It should be drawing 23. You can confirm this by deleting that vent outright: the reactor now has 23 excess heating. Which is precisely the amount that vent would need to handle. All the other components are isolated from this lonely corner vent, and run at capacity; there is not a single one that cools less than what it is specced for. Therefore we can say with confidence that up until this point, the cooling system has removed all but 23 points of heat from the core. All the fuel rods have already ticked much earlier in the pass, so there is nothing that adds heat to the reactor core right before the lonely vent takes its turn. There should simply not be enough for the vent to draw to melt itself.
What gives? Is this a bug in the planner, or does IC2 act the same way? And if so, is it a bug in IC2, or intended?
EDITed: I went and confirmed this inside Minecraft: IC2 does exactly the same in practice. The vent overheats. But how? Hull heat is permanently at 0.00%, and only 23 excess heat is available for a part that can cool 20+4+4. What changed about the reactor simulation that caused this? And is it intended?
I consulted the first post designs, and this one "Mid power low running cost" is very similar to mine in basic design, but is currently broken:
It seems that if we could increase the cooling slightly, and re-adjust some of the vent distributions, it might be able to work? I tried for a while and ended up with the same numbers in a different configuration ( 02020C0D120A140D0C0202000C0D0C0D0C0D02020C0D0C0D0C0A12020C0D0C0D0C0D0C0D0C0D0C0A0C0D0C0A0C0D120D140D0C0D140D )
Yeah, I remember that design well. Problem is, it just won't work. You need a certain amount of advanced heat echangers and vents in order to keep the overclocked vents at the rim alive, those that aren't fully surrounded by component vents. And in order to fit that amount, you need to sacrifice cooling capacity... enough cooling capacity to drop below the heat output of the fuel rods. You're stuck in a catch-22: you either have the cooling capacity but it melts itself to pieces uncontrolledly, or you keep alive every part but the reactor is heat flow positive. Regardless of how you arrange the pieces, if it's heat flow positive it will eventually melt. The best I've been able to do is just shy of 7,000 seconds lifetime for the first component to fail, which leads to the reactor detonating shortly after the 8,150 second mark.
No, to fully stabilize it, you'd need to make use of that one empty slot, the one next to one of the fuel cells. Unfortunately, that's appears impossible, because no part exists that survives being being the only neighbour that interacts with an efficiency 5 dual rod for an entire cycle.
Fun fact: you used to be able to do it. An efficiency 5 dual rod puts out 2x60 heat. The core heat exchanger can do 72 core transfer. But at some point during IC2 Experimental's development, the transfer values for all of the exchangers got accidentally doubled. So the core heat exchanger did 144 core transfer. You would put one of these in that empty slot, and because the fuel rod now had a component next to it that could accept heat, it would stop dumping its heat directly into the core, and instead dumped it all into the exchanger. Which, in turn, would dump it into the core. At first glance that looks like it gained you nothing, but: that exchanger is surrounded by three component vents. So even though all you did was route the heat into the core through a slightly different path, you magically gained 3x4 additional vent cooling. And since the whole design is only 3 heat over, suddenly the reactor was stable!
The strange doubled exchanger transfer rates persisted for many versions - certainly straight through 1.6 and also 1.7 for a good while - but it appears that it has been reverted since I last looked into it.
... OR HAST IT?!
Yes. Yes it has. The core exchanger melts in under two and a half minutes.
EDIT: Incidentally, this is stable: 02020C0D120D0C0A120201020C0A0C0D0C0D02020C0D0C0D0C0D0C020C0D0C0D0C0D0C090C0D0C0D0C0A0C0D110D120A0C0D120D0C0D
You can even swap an advanced vent and an advanced exchanger for basic variants, as I have done in that link.
The reactor goes from efficiency 4.286, 300 EU/t, 14 rods per cycle to efficiency 4.067, 305 EU/t, 15 rods per cycle. You know, though it looks a bit awkward and fails to satisfy the itch for ORDNUNG MUSS SEIN, I might actually prefer this variant over the defunct original, for reasons I have laid out in response to albijoe below. Still higher efficiency than I'd usually opt for (I aim to stay between 3 and 4), but the packing density of the reactor is pretty good, and it has no running cost - so it definitely has some things going for it. Maybe if someone ends up unusually short on uranium...
Here's the reactors I use, in the new format.
Those are not the best designs I'm afraid. Well, all except the third, which is a standard design from page 1.
You've got 692 vent cooling, and none of your fuel rod configurations manages to make use of all of it - like, the fourth one runs only at 560 heat. You could probably pull that off with a 5-chamber design.
Also, this may be personal bias, but I'm not a fan of reflectors and chasing efficiency in general. I've used nuclear reactors since Minecraft beta 1.2 (which is long before Minecraft 1.2, which is long before where we are now). And while I was initially also very gung-ho about optimizing my efficiency at all cost, eventually I noticed a common theme about every game I played with IC2. Namely: uranium is never the bottleneck. Just the act of mining the resources necessary to build and run the really big and expensive reactors would turn up so much uranium on the side that you'd be set for days, if not a week of real time. During which your (generally fully automated) high-end mining solutions would pull up uranium faster than you could use it.
The idea then of trying to maximize the output of every single fuel rod seems kind of pointless then. The idea of burning other resources to stretch your uranium supply seems outright folly. Now add to the fact that a lower efficiency reactor actually puts out higher EU/t numbers for the same cooling system, allowing you to run your mass fab faster and get more iridium sooner, and I started to wonder why I've even been bothering.
And then they added plutonium and MOX fuel. Now, you have an even greater incentive to not go for high efficiencies - because ultimately, you want plutonium. Its mere existance further stretches your uranium supplies because your nuclear waste can go for a second, super-efficient cycle; you can use it to convert your useless, excess U-238 into something useful (more plutonium); and you finally end up with an infinite passive EU source of not insignificant magnitude. And you only get plutonium by burning through fuel rods. So you want to burn as many of them in as short a time as you can. You're actually gaining something by being wasteful!
Quad cells do have one thing going for them - they can result in a greater packing density inside the reactor, which is why that 420 EU/t standard reactor is such popular compromise between efficiency, EU/t and plutonium per cycle. All for very modest running costs. But reflectors? Complete waste of time and resources. Even the iridium ones. Why would I spend my ultra-expensive iridium on even more expensive reflectors, if I could spend it on my quantum suit instead, and just use more fuel rods in that slot in the reactor for the same effect but with more valuable plutonium throughput? If I just do that, then by the time I have built my quantum suit, I have enough pellets to fill up a RTG already.
This is the best I could come up with that is both reasonable EU/t and also reasonable efficiency:
It uses a mixture of dual and quad cells. I am sure that there are better designs out there. Has anybody put something together that's strictly better yet?
Yes... in fact, this thread's opening post from 2013 has the same fuel rod configuration with more efficient cooling, resulting in a lower build price. Thus strictly better than yours
The links there are out of order (so I'm not surprised you didn't check them), but here are the codes for all the opening post reactors with the new (current) reactor planner. See "highest overall efficiency".
Don't let it get to you though. The more efficient use of components comes down to knowledge of how exactly the reactor internally iterates from itemslot to itemslot for each of its "ticks", and that kind of stuff can border on the arcane. For your own work, coming up with the design you presented is quite good - you successfully identified the highest possible zero-reflector efficiency configuration possible under internal cooling, and set up a configuration for it that works reliably.
Meanwhile, a question for everyone:
What are the best designs that use only dual cells and no consumables or reflectors nowadays? I'm *very* rusty Aiming for practical efficiencies between 3 and 4, and minimzed unused space. A quick poke at the planner yielded this modification of an old MOX design of mine, which I doubt is as good as it gets... (3 chambers, two empty slots, efficiency 4.00, 160 EU/t, no running cost)
Is energy loss per packet still truncated like it was back in the olden days? I.e. copper caple had 1 unit of loss every 5 blocks, but if you had a 4-block long cable you'd have 0 loss. Does it still work that way? Or do you get 0.8 loss now, because it counts decimals?
Yeah, but it's also about price and power - the quantum suit is too expensive and at the same time too powerful for my tastes. Sounds funny, but it's true I never even bother to build it.
(Unless they toned the quantum suit down since I last checked, but I doubt it.)
*nods* That's what I expected. Thanks for the answer! Definitely a pity though, the advanced nanosuit is probably my favorite armor across all of modded Minecraft.