Posts by Omicron

    I:energyGeneratorNuclear=5


    That is the relevant entry for nuclear reactor power output. 5 is the default value. Now, if that was somehow set to "1", then you would see exactly 84 EU/t (one fifth of 420). Odd that it's still set to 5. Try raising it to 6 and see if something changes?


    (remember that both the client and the server should have identical configs.)

    Yeah, i have had the same issue.


    I solved it for me by downgrading the security level of java via the control panel. But that's dangerous for your system as a whole, so I would only do it while you're actively using the planner and put it back up again after you're done. Also, you could try updating, maybe the latest update treats things differently.

    Heat generation and reduction goes like this:


    The reactor ticks once per second. During each such tick, every slot in the reactor is checked once.


    It starts in the upper left corner, and goes horizontally across, the whole top row. Then it does the second row, again left to right. Then the third row, and so on. That is why the top components are the first to overload, because they act first and thus take the full brunt of the heat.


    When a slot is checked and something is in that slot, that something gets to do its thing. A fuel cell will generate energy and heat depending on its neighbor situation. An OC heat vent will draw all availble hull heat into itself, up to a maximum of 36, and after that, will cool itself for 20. A component heat vent will cool every component it touches and has heat in it by 4, whether they have already acted yet or not. A component heat exchange will make sure that all items touching it plus itself all contain the same percentage of internal heat, whether they have already acted yet or not, up to its maximum transfer limit. A regular heat vent will attempt to do the same and additionally also balance against the reactor hull, again up to its maximum transfer limit. And so on.


    When the final slot is checked, the tick finishes. The reactor ejects all generated EU to the e-net, and any unprocessed heat in the reactor hull will remain there and carry over into the next tick, allowing components that act before the fuel cells to process the stored heat from last tick.

    Are you running the latest Java version (7u25)?


    Basically what happens is that Java complains about some of the old code used in the planner that is considered an insecure style nowadays, and straight-out refuses to run it.

    That was a bug in the computercube I also ran into and reported to Greg. I assume it got fixed (though I didn't check recently).


    Basically, no design where a fully active overclocked heat vent is sitting on the edge of the chamber is stable. This is because the overclocked vent will draw up to 36 heat from the reactor, but it can only dissipate 20 heat. That leaves 16 heat per tick to accumulate inside the vent, eventually melting it. If you surround an overclocked vent with four component vents, then each component vent removes 4 additional heat for a total of 4x4=16. Thus the OC vent becomes stable and doesn't melt itself. But at the edges of the chamber, the OC vent cannot be surrounded by 4 component vents for obvious reasons. I do not know what rode the computercube there to claim this as stable, because it never was and never will be, regardless of whether you use thorium or plutonium or just plain IC2 uranium.


    You need to find ways to move the extra heat away from the OC vents on the edges. One possible way is doing this, with heat exchangers moving some heat back into the hull or swapping it to other vents that don't draw from the hull by themselves. This reactor shows another possible approach, where heat is moved towards additional OC vents in places where they would usually not be able to draw any heat themselves. Ultimately, which works best depends on your heat profile and the shape of your fuel cell cluster.

    Hold on, let me check something.


    ...ah yes. That beta version doesn't have that change fully implemented either. It's in place for thorium, but not for the other two fuel types. Starting 3.0, all fuel types work that way though. Apologies for promising too much there.


    Honestly FTB should just have stayed with 2.82, it would make things infinitely easier for everyone involved =/

    It's.... adequate. But you're burning a large amount of uranium at really low efficiency. GregTech reduces the costs of making multicells by some 85%, so it's honestly a waste of uranium not to build at least dual cells. The zero running cost reactors are for people on plain old IC2.


    This will have almost the same output at almost twice the efficiency, for only slightly more initial building cost and 12 copper bars per 2h46min cycle.


    And if it's maximum output you're hunting, there's this silly thing.

    Spreadsheet updated to GregTech 3.07i. As always, check my numbers just in case I messed up.


    Plutonium changed again, completely. Greg says that was the last tweak he's making until completely reworking the entire reactor game mechanic in a future update without ETA.
    What was changed: The multipulse system is gone, instead plutonium is a 1:1 copy of thorium multiplied by 10 (with the exception of runtimes, those are still different).


    Pros:
    - Plutonium now outputs a lot less heat. Like, almost down by half in some cases. Should allow for a lot more EU/t from reactors involving plutonium.
    - Scaling is no longer different in hybrid setups, meaning you can use good old cell value efficiency to compare hybrid reactors again.


    Cons:
    - No more crazy efficient setups.


    In other news, the bug that made thorium reactors behave oddly got fixed. They no longer show any divergent behavior.




    Also, can someone help me confirm a bug, likely IC2 related?


    I tested the following combinations:
    - IC2 #312, GregTech 3.05g
    - IC2 #312, GregTech 3.07i
    - IC2 #349, GregTech 3.07i


    And in all three combinations, depleted isotopes got recharged instantly in a zero-heat reactor. One reactor tick, boom, any depleted isotope neighbouring any kind of fuel cell instantly becomes a fully recharged isotope. This kind of messes with the concept of breeding reactors just a tiny little bit, as you can imagine ;)

    I've only just added the newest version of GregTech to my spreadsheet literally a minute ago. Plutonium changed again completely. I have no idea what works best right now.


    Unless with "newest version of GregTech" you mean "the very old version of GregTech in the newest version of the FTB ultimate pack", in which case:


    - Use uranium reactors. There's some fairly good designs in that thread.
    - For thorium use this and expect it to suck, thorium is bugged in that version and this is the best you can do, and it's reasonably cheap. 108 EU/t at efficiency 3.
    - For plutonium, use this. Not 100% min/maxed but the best I can come up with in 5 minutes. Should do 340 EU/t at efficiency 5.67.

    As the post in the big thread explicitly points out, the presented hybrid designs don't work and will likely explode in any GregTech version of 2.9x and higher. Which is what the Ultimate pack is running. In fact, that version doesn't just have the "hybrid effect" removed, it's actually a buggy beta version and generates significantly less than intended in pretty much all hybrid situations.


    So unfortunately, the answer is no. There are no good hybrid reactors for FTB Ultimate. Stick to pure reactors only.


    Spreadsheet with data: https://docs.google.com/spread…VHhEZzUtX0dTZ3E2aVE#gid=9

    It's being blocked because it contains old code that is considered insecure and/or bad style by today's standards. Therefore the JVM refuses to run it.


    You can lower your security level in the control panel under java options. However, realize that this will let malware to have an easier time infecting your system.

    Try the list in the first post of this thread. There's a 420 EU/t design using uranium. Since I happen to know that you are running GregTech due to your other thread, the advertised running cost of 280 copper per cycle is actually much lower for you (only 35), and thus the effective efficiency is much closer to 3 than to 2.5.


    If you want better efficiency than that, no deal though. You can have either low heat or high efficiency or high EU/t. As soon as you improve one aspect, the other two get worse. The reactor above can only do over 400 EU/t because it runs very inefficient while dissipating a ton of heat.


    Uranium is generally your go-to fuel for high EU/t operations, while plutonium is for high efficiency designs (though that's not hard and fast, just a general tendency). Thorium is somewhat of a waste product but if you use dedicated thorium sink reactors that burn very large amounts of thorium at once, you can still get average output at decent efficiencies from it. You can also use single thorium cells as cheap reflector stand-ins to boost other fuel types up in efficiency while generating almost no heat for the thorium itself (but the hybrid effect that created crazy numbers for thorium/plutonium pairs in 1.4.7 was a bug that has since been fixed).

    What Fallen_dead and Glease mean to say:


    The reactor planner has not been updated for any GregTech versions newer than 2.8x. If you use 2.9x or 3.xx, you cannot use the reactor planner alone to make working setups or predict your output anymore. Use the computercube (spawn one in if you must, it doesn't do anything besides being a reference manual anyway) and simulate your reactor there. Or if you fancy doing some math by hand, you can use my spreadsheet in conjunction with the outdated planner to build mockups of potential cooling systems that you can later test ingame.


    The reactor planner is still valid for pure IC2 setups, by the way. It's just the GregTech stuff that's changed.

    Anyone have a good suggestion for a relatively cheap thorium-based breeder (to start off my nuclear production) that works with Gregtech's new thorium behavior? I'm on a world where the old 8x depleted isotopes per uranium is still enabled to help keep nuclear viable vs MFR tree farms and spammed boilers.


    You could try this: http://www.talonfiremage.pwp.b…vmiivu9waot76tfdu7ydkldkw


    It's not the cheapest there is out there, but as a 1-chmber it's reasonably inexpensive compared to fullsize reactors, and it's fairly powerful and very scalable. It should charge 220 isotopes per single thorium cell. The heat output for thorium was reduced, so it will put out only 12 instead of 15 heat in this configuration, which is exactly compensated by the single vent. If you want to upgrade this, all you need to do is add an additional chamber, fill it to the brim with plating, and then increase the number of heating cells to hit your new heat allowance. With 4 chambers, this hits the maximum 64 heating cells possible (and thus the maximum possible breeding speed for a single cell), and with 6 chambers it even stops hurting you while you stand next to it - or alternatively allows you to fit a second single thorium cell + 4 isotopes in there.



    I really like that design, that's indeed a significant improvement. You rarely see one of the listed designs get shot down as hard as this :D


    I don't know why people are so bothered by running costs. Its only an advantage if it leads to a higher overall efficiency, which it doesn't in the case of your 1st reactor. Granted, it does for the second reactor, but there's probably a design out there with higher overall efficiency by using multiple cells.


    Because it can add up severely for people who play without GregTech. Direwolf20 discovered this the hard way with his lapis condensator reactor. He ended up having bigger issues trying to come up with enough copper than coming up with enough lapis. It cost him 720 copper every 2 hours 46 minutes.


    Now if you step back a moment and stop taking Mystcraft mining ages, Redpower frame tunnelbores, turtle armies, lava centrifuges and tesseract quarries for granted (because not everyone plays FTB ultimate, and not everyone has access to these technologies or even knows they exist), you can see why running costs might be daunting for some people. The zero running cost reactors are there as one option among many, not as the one end-all solution.