Posts by MauveCloud

    I have released v2.3 of the reactor planner, with the following changes:

    • Updated default pulse configuration to be the same as no redstone
      control (to avoid unintentional simulation of control types not actually set up in-game).
    • Added default text to "Component" tab.
    • Removed cooldown display for reactor designs/configs that will explode.
    • Added calculation of explosion power (for reactor designs/configs that will explode).
    • Standardized key names in (for i18n).
    • Added display of heat/eu outputs before first component broken (if any).
    • Added display of time to first dip below 50% heat (after being above it).
    • Made reactor temperature checks more consistent with mod - instead of checking after processing each component, it only checks at the end of the reactor tick.
    • Added min/max EU and Heat outputs for fuel rods (click the "i" button near the fuel rod to see this).
    • Added max reached heat for heat-accepting components (click the "i" button near the component to see this).
    • Slight clarification of what total cell/condensator/vent cooling means.
    • Gave the tab ordering below the reactor grid a bit more logic.
    • Added outputs and min/max heat before first fuel rod depleted.
    • Improved automation handling, allowed pre-specification of automation details when placing components.
    • Added automation details and pulse config to reactor code.
    • Added cancel button.
    • Changed output for fluid reactor to show as HU/t instead of HU/s
    • Added support for CSV Output.

    Note that as far as i18n support, the framework is there, but no translations (aside from the default, which is US English) have been provided yet. If anyone wants to provide such a translation, a GitHub pull request is a good way to do that (provided you're familiar with Java's i18n handling, so you can name the new file appropriately, etc.). Alternatively (if you can't or won't use GitHub for whatever reason), you may attach the translated to a post in this thread. Please refrain from relying on machine translations, though.

    I suggest putting in a total EU from a 50% Stirling cycle and a 75% steam cycle. I'm also not sure if the heat and the EU are both calculated correctly, this might be a bug.

    If you look back in the thread, something like that has been suggested before, but it's out of scope for the planner, because it depends too much on setup external to the reactor itself. With just IC2, the HU output of a fluid reactor (in the form of hot coolant sent to one or more liquid heat exchangers) can be passed to stirling generators, steam generators (either just regular steam or superheated and regular steam), or even used for making biogas and feeding that into some semifluid generators (though this might be less effective than the other options). With GT5u (or possibly GTCE), the hot coolant can be transferred to a Large Heat Exchanger, and other mods may have their own ways to use the hot coolant.

    From my testing results the fluid output should be HU/t, not HU/s. I would go with "Per sec", since a tick can refer to a reactor tick (1 sec), a redstone tick (0.1 sec), or a game tick (0.05 sec).

    I tentatively agree with the first part of this - in 1.7.10 a simple design with 1 uranium rod and 1 heat vent shows 8 HU/s output (in the reactor gui), but in 1.12.2 is shows 160 HU/s. I was hoping for confirmation from Chocohead, but he has yet to respond in the GitHub issue. Confirmation from someone else who has knowledge of IC2's inner workings for multiple MC versions would be nice - in-game testing doesn't entirely rule out the possibility that the output was buffed while things like HU to EU conversions were nerfed to match.

    As far as "per tick" or "per sec", I'll admit there are multiple types of ticks involved, but I've never seen "per tick" mean anything but "per game tick", plus that will be more consistent with how EU output is normally shown (as well as energy outputs from other mods, e.g. RF/t, IF/t, MJ/t, µI/t)

    I doubled the heat because that is what I recalled happening. The heat output will actually be double, I think, so 1824. I only simulated this, so I don't recall if the simulator is telling me I got something wrong, or if it falls to calculate the double heat, it if I'm just wrong. I suppose I should have pulled out other designs to check.

    The simulator calculates the double heat, as you should be able to tell from the maximum heat output displayed. However, you might also notice that the "Reactor minimum temperature" is 0, even though you started the simulation at a temperature of 6000, which means that design (and pulse configuration) is venting more heat than the MOX rods are generating, even at double "base" heat output, so it won't maintain the >5000 temperature it needs.

    There is no severe inaccuarcy in your planner. The "severe inaccuarcy" that you see is just because you forgot to set the suspending temperature to 10001.

    So far, your planner seem to be right. Removing the top-left heat exchanger do cause the reactor to explode in-game with a pulsed redstone control. I just tested that. The reactor exploded after burning the top two vents and some bottom vents. The explosion was not very powerful, though.

    That should not have made a difference, considering that my planner defaults to a suspend temperature of 8400, which the simulation claims it never reached - if the simulation says it only got up to 3000 and in-game testing caused it to explode (by hitting/exceeding 10000), I'd call that a serious discrepancy. However, I realized there's another possibility besides a mistake in my planner: something could have wrong with the redstone pulse control you set up in-game (e.g. misconfiguration, unexpected hiccups). Could you please explain exactly what you did to get an 8 sec on, 1 sec off cycle in-game?

    First, I think pulling heat from the rod and pushing heat to the core heat exchanger makes no difference. To my understanding, the core heat exchanger is like a “heat capacitor” that vents/pulls heat from the reactor. If it gains 152 heat, it cools the reactor down and basically doesn’t do anything because a few ticks later (or less) the reactor will be cooled enough for it to vent back the 72 heat pulled from the reactor in the beginning. If it is touching the rod, it takes damage at a rate of 80/s and heals at a rate of 8/s. Once its damage percentage is greater than heat percentage of the reactor, it will start to vent 72 heat into the reactor, thus not destroying itself.

    Let's put that to a side, but the core heat exchanger can vent heat at 8/s wherever it was put, right? Then why does one place work while the other one doesn't?

    TBH, I've never fully understood the heat exchangers even after looking at decompiled code for them. Among other things, they have some weird quirks when their heat level is close to zero. However, based on your statement in the second paragraph, you seem to be misunderstanding something - the heat exchanger is not venting the heat by itself - the adjacent component heat vents are each removing up to 4/s from it (and not "accepting" heat themselves, which is significant for the quad rods which are simply pushing their heat to the reactor, since there's nowhere else for the heat to go).

    Now I have some questions for you:

    1. You claimed that "removing the top-left core heat exchanger causes the reactor to explode within a cycle but doing so on the right one doesn't". Was this something you found in-game or with the simulator? Using the "Simple Cycle" simulation, it looks like removing the top-left core heat exchanger will only cause it to explode 22 seconds sooner than having both in place, and a "Pulsed Cycle" simulation with 8 seconds on, 1 second off and the top left core heat exchanger removed shows a reactor max temperature of 3000. If it explodes in-game even with an 8-1 pulsed cycle, then that's a severe inaccuracy in my simulator that I will have to investigate.

    2. Same question regarding your findings when switching the dual fuel rod with the reflector - it looks to me like it still works, just less heat output - your first design shows 1451.79 Hu/s average, and a reactor maximum temperature of 723. Swapping the reflector with the dual rod produces 944.35 Hu/s average (because several of the overclocked heat vents broke, the first at just 249 seconds), and the reactor got up to a temperature of 2568.

    I know that components can accept heat from adjacent sources, but all the components that I used can pull heat from the reactor, so the total venting should be the same regardless of how the fuel rods are placed. Then what's the difference between pulling 80 heat from the rod then give 72 to the reactor and pull 72 heat from the reactor and vent 8 heat? I can't see any difference in that.

    Okay, let me try to clarify: the exchanger is not "pulling" 80 heat from the rod, the rod is "pushing" 80 heat into the exchanger before the exchanger does its thing. This means the exchanger in question can theoretically be gaining as much as 152 heat per reactor tick when a rod is adjacent to it.

    I think I can answer a couple of your questions:

    2.Why does removing the top-left core heat exchanger causes the reactor to explode within a cycle but doing so on the right one doesn't?

    3.Why does 0223130C0D0C0D0C1303030C0D0C0D0C0D0C030C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C not work despite it generating the same heat and having the same rods/reflector, the same heat vents?

    It isn't obvious from the IC2 Wiki, but unless this has changed in newer versions of IC2, the reactor heat exchanger accepts heat from adjacent sources (such as that dual fuel rod near the upper left corner). Thus, if you remove the exchanger or swap the rod's position with the reflector, the dual rod will be pumping all its heat directly into the reactor instead of the exchanger.

    Looking at decompiled code for 2.8.104, it seems like the laser has a 10% chance of skipping drops (aka "evaporating" the block) for a block hit by the beam in any mode - see the second line of EntityMiningLaser.hitBlock(pos, side). Explosions could certainly destroy more, and I just confirmed from testing that even "low focus" mode doesn't really have a 100% drop rate - I placed 64 cobblestone, and mining it with the laser in low focus mode only got me back 53 (technically that's 17% loss, so I guess I got some bad luck there).

    Looking at circuits, I just noticed something else: there doesn't seem to be a way to produce Bisphenol A (NEI only shows me the recipe for getting it into or out of a cell with a fluid canner). Maybe I'm missing an "optional" mod that would make it obtainable, and it isn't a big deal, since all it seems to be used for is making more phenolic circuit boards per wood pulp than with glue (and it's not like wood pulp and glue are all that hard to obtain in significant quantities). Or is it something that was planned to be taken further but not fully implemented?

    Wait, I thought the Forestry Electric Engine still does RF, instead of the MJ that the latest BuildCraft has gone back to. There are some other options mentioned in another thread. Chocohead's proof-of-concept mod is probably your best bet at the moment. The one I had mentioned (ModernConverters) apparently now has MJ conversion disabled, and NuclearCraft's description page has nothing to indicate it supports BuildCraft MJ.

    once you get close to radioactive items like uranium, iridium or anything else like a reactor

    I can understand this for uranium (even though technically the ore blocks and some of the other forms of uranium don't trigger the "radiation" effect if handled without a hazmat suit), but I'm not so sure this makes sense for detecting iridium (as far as I can find, naturally-occurring iridium is stable) or reactors (they're shielded with lead)

    I've got pre5 running (aside from some strange issues with tile entities that I haven't figured out - sometimes exposed GT ores are blank until I stand next to them for a few seconds, and sometimes when I get back home from exploring, some of my JABBA barrels are blank, or some of my GT machines are pink and black, or some of my IC2 crop sticks are unexpectedly empty until I exit to menu and re-enter the world)

    Anyway, as far as I can tell, you are correct about the voltage requirements for building circuits even in pre5, but I haven't figured out the logic behind having the mainframe be the only circuit really in the HV range for making.

    I looked at the other components that use iron bars in their recipes, and they had the iron counts double what they should be for those iron bars. The only explanation I can think of is that maybe I was looking at the GregTech 5 crafting recipe for iron bars (6 iron rods to 8 iron bars, and if I make the rods by using a file instead of in the lathe or extruder, they take a full ingot each, but that's wasting iron, and by the time a GT5 player is ready to build a nuclear reactor, more material-efficient ways to make iron rods (and iron bars) should be available.

    Also, we may have some iron bars already in our inventory before our first reactor! I don't think that there's any way to accommodate that.

    Considering that iron bars are required for the scuba helmet that is part of the complete hazmat suit, I'd be surprised if you didn't, come to think of it.

    Anyway, material counts should be fixed in v2.2.1.

    Speaking of code, I noticed that placing a single Heat Vent increases causes the tool to say "10 iron" for the costs, but from what I can tell, it only costs 8.5 iron, and always has only cost 8.5 iron.


    As far as I count, you need 1.5 iron for the iron bars, 4 iron for the plates, and 3 iron for the electric motor, making a total of 8.5.

    I agree that 10 iron is incorrect, and I'm not sure quite where that came from - in August 2015 I changed the planner to show raw materials instead of components (as requested earlier in this thread), and if I had goofed and thought iron bars were 1:1 with iron ingots, that would have led to a recipe of 11 iron instead of 10. However, your total of "8.5 iron" is ignoring the fact that iron bars have to be crafted in batches of 16 (from 6 iron). If I changed the planner to calculate the iron cost of a heat vent as 8.5, designs with heat vent counts of 1, 5, 9, 13, etc. would undercount the effective iron requirements by 4.5. I haven't figured out how to deal with this yet.

    I'm aware of that one, it was a possible alternative to going whole-hog for Modular Powersuits. I wasn't sure how current the mod was, since it's something Mauve Cloud made several years ago, and he's not currently playing.

    Um, if I'm reading this post correctly, you seem to be crediting me with writing either Gravisuite or Modular Powersuits (it's not entirely clear which you mean). I did not write (or even contribute to) either mod.

    1. Have you tried running Forge by itself, to make sure it's really IC2 causing it?

    2. Are you using Java 9 or higher? Forge is known to not support that, at least until the upcoming 1.13 builds (and will crash without a log if you try, so this could easily be what you're running into). I haven't found indications of whether there are plans to backport Java 9+ support to Forge for older MC versions later.

    For me, it was mainly the "no guis, do everything with in-world interactions" philosophy that Greg seems to be using now that kept me away from GT6. The ranges of RU/KU/HU/whatever shown for the different machines in NEI don't exactly help in making me think it's "simpler" and something to switch to if I thought GT5 was too complex - I'm confused by ShumnayaBulka's logic in making that switch. Sort of a moot point in my case, since I've switched to MC 1.12 with other mods for now (and I might play MC 1.13 vanilla for a bit after it officially releases)


    Caused by: java.lang.OutOfMemoryError: Java heap space

    This one's pretty simple. You need to allocate more memory to Minecraft. I think doing that for a server is a little different than doing it for a single-player game, but it shouldn't be too hard to Google for how to do that.


    Operating System: Windows 7 (x86) version 6.1

    Java Version: 1.8.0_141, Oracle Corporation

    Java VM Version: Java HotSpot(TM) Client VM (mixed mode, sharing), Oracle Corporation

    Memory: 96684480 bytes (92 MB) / 259522560 bytes (247 MB) up to 259522560 bytes (247 MB)

    JVM Flags: 0 total;

    Based on these lines, I'd say you're running 32-bit Java, and 247 MB allocated is really tight for trying to run modded Minecraft. I strongly recommend running 64-bit Java if you can. What other mods are you planning to add? Perhaps I can come up with an estimate of how much memory you should allocate.