Posts by LezChap

    Yes, because playing GT is relevant to this discussion how?


    Saying FML has a bug when you're using it and it's not working as you want can only be actually defined as a bug if A) FML is documented to work as you intend and isn't, or B) You wrote FML. Otherwise it's a feature you want, but doesn't exist. Hacking it in...well, that's just unethical in my book.


    As I also said in TiC, I'm not against Gregtech...I'm against Greg's implementation of it.

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