Posts by LezChap

    I was looking to upgrade the power supply to my main assembly/processing line...right now I have a uranium reactor producing 100eu/t. I was looking for a Mark I design (as this is running out in the open and I don't want a CRCS system that will blow if something doesn't exchange at the right moment). As I find single-chamber reactors really easy to automate, I decided to go with that. I want the most power I can produce for the space I have available, as resources are not an issue but power generation is. The best I've been able to come up with is this design: http://www.talonfiremage.pwp.b…52r1fz97v993yb8qvlfyckcg0


    It produces a base of 120 eu/t. Can anyone do better? Then again, I can upgrade to a 3-chamber design, it'd be just as easy to automate, and I could use Omicron's design to get 135 eu/t...at a MUCH higher efficiency. Decisions decisions.

    Yes, that would explain it. Which build generated that config, out of interest? That would be one heck of an undocumented reactor buff.


    I can't find a backup of the first version of the pack, but I went as far back as I could to build 264 of IC2, and testing I couldn't replicate the config. :(


    I doubt that's the case...in one attempt to squash the bug, I set up my code to turn off the reactor (rs.setOutput("back", false)). I then told it to wait 2/10ths of a second. Any processing going on in the reactor for that tick -should- be done at that point, unless the calculations are spread evenly across the 20 ticks in a second to reduce spikes every 20th tick. Then I'd swap the a coolant cell out, and wait another 2/10ths of a second before turning the reactor back on. Even doing this, I had the reactor randomly gain heat from the glitch.


    The -only- other option I have is to pause the program for a whole second after turning off the reactor before replacing the coolant cell and see if that works...but that'll reduce the -effective- eu/t, so I didn't want to do that...but I may give it a try just to see if it works.


    I think I found my problem...my program uses OpenPeripherals to detect the status of the reactor's heat value, as well as the status of the components in the reactor. The problem is that each of these operations takes an in-game tick, which I didn't anticipate. I finally discovered this issue as I create bigger and bigger reactors with more and more components that required checking...it got to the point where there was close to a 3 second delay between the start of detecting the status of components, and the end of it, creating very unstable reactors when pushing the edge of heat tolerances...as well as resulting in fried components due to the delay. I know how to fix this, but it'll require almost a complete re-write of my control program...and finding out that my numbers aren't as impressive as I thought they were due to the problems with my config file, my drive to do so as quickly as it might have otherwise been has vanished. :( I'm sure I'll get to it eventually.

    Edited the OP to denote that my config files apparently generated incorrectly, buffing nuclear fuel output by 4x before the MOX Modifier. Sorry, my outputs aren't as impressive as I thought...the 30k original design would only output 7,500 eu/t with default configs. I apologize to anyone I may have gotten hopes up for, I didn't realize this buff I was seeing wasn't intentional, as I used the configs as they generated, and didn't modify their values. It was not my intent to mislead anyone by posting these insane EU Outputs.

    Yes, the multiplier over what the reactor planner states is the heat bonus. It scales from x1 (at 0% heat) to x5 (at 100% heat). Therefore, if I manage to get the heat so high that I get the maximum bonus, I will produce 675 EU/t with one such 3-chamber segment.


    If you are getting any more than that, it's a bug and you need to tell Thunderdark that Player broke something again :P


    EDIT: quick confirmation in build #298: https://dl.dropboxusercontent.…0/2013-11-15_19.17.09.png (don't mind the wildfire)


    No...even with uranium reactors I get 4x the power stated in the planner. I went to look in my configs and found this:



    I know I didn't change any of those values (and I created the pack I'm playing on), they had to have generated that way. Looks like I'm getting a base value for nuclear fuel of 20...whereas the planner and IC2 before experimental you got a base of 5 per rod...thus the 4x multiplier I'm getting BEFORE the MOX modifier.

    My experience since installing experimental is that nuclear reactors produce 4x more power than the reactor planner states...I didn't change any configs to get that result either...


    So the planner states 135eu/t. x4 that's 540. x((4*.7)+1) = 2,052.

    Another three-chamber design I just made: http://www.talonfiremage.pwp.b…52r1fz97v993yb8qvlfyckcg0


    Kinda proud of this one. If anyone can get more output out of three chambers without using hull transfer components or CRCS, let me know! ...Why three? Well, let's say I have a little project in mind. :whistling:


    That's a very good build...at just under 70% max hull heat, it'll produce exactly 2048 eu/t...and being 3 chambers, it's stackable...am I going where you're going?


    edit: Also wanted to ask: Why the containment reactor plates over the Heat-Capacity ones?

    I know, I just couldn't find a better word to describe it, thus it being surrounded by ...'s :P I just wanted to put the warning out for someone that might expect for reactors to remain intact during and after transit...because if I didn't think about it before it exploded violently in my test world, someone else is bound to do the same thing...only on their legit world.

    Found a...glitch...when using multi-chamber reactors and Redstone in Motion frames...if your heat level is over what can be handled by your main nuclear reactor chamber and the components inside its slots (the first 3 columns), it'll explode when the frame moves it. This hits hard if you plan to use a lot of reactor plating to increase the max heat to make heat levels easier to manage, or if you plan to operate on the high range straddling the edge of efficiency and danger.


    Just figured I'd let anyone know, in case they planned on a build combining RiM and MOX Reactors.

    Two questions:


    1) Does 85% heat melt (iridium/tungstensteel) reinforced stone? What is the radius that the reactor affects?


    2) How well will the design work with Advanced Reactors?


    Either turning things to lava is extremely rare, or it's not implemented yet. In all my testing, I've yet to see it happen. The worst that's happened is:


    1) Things catch within a block or two of the reactor. As long as they're not burnable blocks like wood, this isn't a problem.
    2) Vanilla chests break and vanish near the reactor
    3) Within two or three blocks of the reactor you take damage.


    As for Advanced Reactors, I don't know...but I'll look into it.


    edit: Looked into Advanced Reactors and honestly, I wouldn't want to run a high-efficiency MOX reactor with it. It has too many negative environmental effects for my taste.

    Are you sure the coolant cell thing is a bug, and not simply related to the fact that reactor components are processed one by one, left to right, top to bottom? Maybe the slot where the coolant cell was inserted had simply been processed already, if the insertion happens during the one tick each second that the calculation is being run...


    I doubt that's the case...in one attempt to squash the bug, I set up my code to turn off the reactor (rs.setOutput("back", false)). I then told it to wait 2/10ths of a second. Any processing going on in the reactor for that tick -should- be done at that point, unless the calculations are spread evenly across the 20 ticks in a second to reduce spikes every 20th tick. Then I'd swap the a coolant cell out, and wait another 2/10ths of a second before turning the reactor back on. Even doing this, I had the reactor randomly gain heat from the glitch.


    The -only- other option I have is to pause the program for a whole second after turning off the reactor before replacing the coolant cell and see if that works...but that'll reduce the -effective- eu/t, so I didn't want to do that...but I may give it a try just to see if it works.

    Yeah, basing your entire play plan on a temporarily disabled feature in a development build is probably not the best idea ;)


    Thanks LezChap for testing it, now that I know the limit I can plan around it.


    I'm with Omicron...I'm not going to plan my game play around a temporary fix for a bug when they're going to squash the bug (at some point) and reintroduce exploding machines, and make me redesign everything.


    You know the saying...if you do it right the first time...


    And you're welcome...least I could do for all the help you gave me getting it working :)

    I was thinking...with the elimination to Breeders and the addition of MOX fuel, does the old formula of neutron pulses divided by fuel rods still have a place? As far as I can tell, MOX fuel doesn't calculate its bonus based on neutron pulses...at least not directly. And it'd be nice to be able to see the efficiency of a MOX reactor at compared to a uranium one.


    One way we can do this is by multiplying the MOX Bonus ((4*%ofmaxheat)+1) with the efficiency rating of a Uranium reactor using the same type of rods. This has the bonus of using game code (I couldn't find the source when looking the other day, but I believe Thunderdark posted it somewhere), and being fairly simple...but adds another number to the calculation that's dependent on a boolean (MOX Reactor = true/false).


    Another way we could do it is by scrapping the whole neutron paradigm, and rewriting the formula used to calculate efficiency. And what is efficiency other than the power output per fuel rod? I'm sure if I get all mathematical and do the proofs, I can prove that the formula I'm about to suggest is the same formula as the old efficiency formula, just using other variables...but it's been awhile since I've been to math class, and math can be boring for some, so I'm not going to do that.


    Anyways, I propose we calculate efficiency by dividing the power output (eu/t) by the rods used, and divide that by 20. If you'll look at my spreadsheet where I took my 14-rod MOX reactor, and all the reactors from the Official Reactor Design thread, the formula is completely backwards compatible with efficiency ratings using the old formula, but allows for accurate efficiency ratings for the new MOX reactors.


    So what do you think? Good idea? Workable? Bad?

    Question: is the result of transformer upgrades in machines capped?


    In other words, if I insert enough transformer upgrades into a machine to bring it to 8k EU/t allowance - the highest rating supported by cables and EV transformers - will I be able to add more still? Will I be able to go to 32k, then 128k and so on? Or is there a cap at 8k?


    Just tested using the world I have the insane MOX Reactor set up on. I hooked up 5 MFSUs to cabling, and piped it into a Macerator with 4 upgrades in it. It blew. I then tried again with like a dozen upgrades. Still blew. Hoping for some luck, I switched to a Mass Fabricator and gave it a dozenish upgrades. It blew. Looks like the most a -machine- can accept is 8,192 :(

    So 30,000eu/t just wasn't enough for me. I had to squeeze every last once of power I could out of those MOX Fuel Rods, and so I went about it...I went about abusing the ever-living snuff out of those poor helpless fuel rods. I rewrote the MOX Control Program to add a 4th "phase" or mode to the reactor cycle. When you first start it up, it goes through the heatup phase. In this phase, all cooling mechanisms are removed from the reactor so every last Kelvin of heat goes into the reactor's hull. Then, at 54,500 heat, it enters the second phase, "slowdown". In this phase, it inserts all the coolant cells into the proper places, then removes one. This throttles the reactor heatup process by eliminating the heat of all the fuel rods except one from going into the reactor hull. This reduces the heat transferred to the reactor hull from 4,320 a tick to a measly 240. This reduces the total EU the reactor can generate in the first cycle by a small amount, but it increases the safety factor so much that it's worth it. And given the next change, we need that extra safety factor. The next phase is the "running" phase, where it reaches "optimum" operating temperature where you've balanced the risk of explosion to the gain of bonus EU to your liking. In my setup, I have the operating temperatures set between 59,000 and 59,100 heat. Remember, when the reactor reaches 60,000 heat, it explodes. What can I say, I like to push the lines! And the 900 heat safety factor is needed. There seems to be a glitch where replaced coolant cells take a reactor tick to be detected and used in the reactor's heat calculations. Every time this happens, between 240 and 336 heat is transferred to the reactor's hull, increasing the temperature above the temperature margin for the running phase. When this happens, it enters the cooldown phase, where the control program immediately shuts down the reactor, makes sure every coolant cell is in place, and inserts an overclocked heat vent to start transferring heat away from the reactor's hull. Once enough heat is transferred away that the running temperatures are reached again, the heat vent is removed from the reactor, and it is turned back on to operate.


    So, the moment you've been waiting for: At 59,100 heat it generates a total of 31,616eu/t.. You might be able to squeeze a couple hundred more EU out of her, but in doing so you increase the chance for meltdown to unacceptable levels (in my opinion). Given the stated operating temperatures, it'll generate a minimum of 31,573eu/t. I'm quite proud of that.


    But honestly, it wasn't enough for me. I know I could do more. I know I could do bigger. But I couldn't do it with my current reactor design. I'd reached the limit of what 14 Quad MOX Fuel rods could give me. A redesign of the reactor was in order. It was a simple upgrade, but it allowed me to squeeze in 4 more Quad MOX Fuel rods, though it resulted in a significant 16,000 heat units lost to the maximum hull temperature. Whatever, I knew I could adapt and overcome. Putting to work what I enacted with the 14-Quad-rod reactor, all the work was done for me. All I had to do was add 6 more cooling reactors to ensure my Coolant Cells were always available and refreshed when the reactor needed them. So simple, it doesn't even come with a picture. Because of the changed max heat variable, I had to change my control program to adapt. I decided to go with 35,000 heat units for threshold to enter the slowdown phase, as this reactor would produce 5,664 heat a tick, and I wanted a good buffer. The running phase would be in effect between 43,200 and 43,300 heat. With 700 heat units separating my reactor from a crater in the dirt, I was putting myself and my reactor at significant risk. Remember the bug where coolant cells weren't always detected and used properly? Well if that happens twice in the same tick, 360 times 2 is over 700. BOOM! Luckily the chance for that is small (it didn't occur during any of my testing, and I ran a full cycle), but the possibility is there. Lowering the operating temperature by a few hundred heat units will significantly increase the safety factor, but I wanted to reach that level for a reason. The reason? at 43,207 heat, the reactor produces a massive 41,000eu/t, on the dot. I wanted a reactor that outpaced my previous design by nearly 10,000eu/t, and I got it. At higher heat levels, which it's more prone to operating at due to the coolant cell bug, it'll produce slightly more. Here's an example at 43,272 heat where I'm producing 41,049 eu/t.


    I made some other small changes to the control program in the 18-cell build. One change is I reduced the console spam by a considerable margin. When it adds or removes all the Coolant cells in the reactor, instead of a line on the console for each cell, there's just one line for the mass of them. I also made it so it only displays the phase and temperature if the temperature changes. Finally, because the increase in the number of cells that can be moved at once when it places or removes them all, I felt this created a lag in the control program where a reactor tick could occur that the Control Program wouldn't detect and operate on, I told it to enact it's nuclear logic function where it detects the heat level and acts accordingly both before and after all components are checked, before pausing for 8/10ths of a second and repeating the process. I felt this increases the safety factor significantly, while harming nothing.


    And as you can see in a screenshot of my AE system mid-cycle, the system can handle and maintain adequate cooling. The only reason you don't see Overclocked Heat Vents in the buffer is I lost a few when stopping the control program during cooldown phases, and neglected to replace them. This caused a problem part-way through the cycle when it attempted to insert a heat vent, but there wasn't one in the slot in the chest it was looking for one in....and is when I first noticed the problem, and rectified it.


    Some things I learned during these builds:

    • If you calculate that you need 20.05 transformers to handle the power you're putting out...the .05 is SIGNIFICANT! Don't ignore it ;)
    • Power doesn't distribute evenly down a parallel power line. The line of MFSUs coming off the transformer closest to the reactor had more EU stored than the ones further down the line. It's so significant that over the course of the cycle, the MFSU lines at the last few transformers has a whole MFSU's less power stored than the ones at the front of the line.
    • nodding off while you have your reactor gui open when you have a tendency to click your mouse when you startle back awake isn't safe. Especially when your mouse is hovering over one of the reactor platings when you click, at least when operating this close to max heat (thus the picture of the crater).


    Hope you enjoyed these builds. I have a few blueprints I'm going to try soon that'll (theoretically, if the math's right) put the best Gregtech has to offer to shame.