Posts by MauveCloud

Quote from KrisBigK

Could you please upload the archived reactor planner? Somehow I can't open (download it from) that website.

No, because A. I can't find the licensing details for Talonius's planner, and B. Chocohead already attached a copy to this post.

Quote from KrisBigK

Also, my native language is not English so I am very likely to have some problems trying to explain exactly what I mean without misunderstanding. Therefore, I'm going to clarify again - to my understanding, it means the usable ability of venting heat.

I don't know what your native language is, but if there is someone else on the forum who speaks the same language, perhaps having them act as an interpreter might work better, because I'm sorry to say that this doesn't clarify anything for me.

However, perhaps part of the confusion comes from ambiguity in what is meant by "venting", which the IC2 Wiki may be partly to blame for - see the below taken from https://wiki.industrial-craft.…tle=Overclocked_Heat_Vent

Quote

Self Venting Rate refers to the amount of heat the Heat Vent will vent from itself per reactor tick

Hull Venting Rate refers to the amount of heat the Heat Vent will remove from the reactor hull per reactor tick

Component Venting Rate refers to the amount of heat the Heat Vent will remove from adjacent components per reactor tick

The heat handled by Self Venting and Component Venting is transferred to coolant for a fluid reactor (or just eliminated for an EU reactor), but the heat handled by Hull Venting is stored in the component (at least initially - some of it may be self-vented, component-vented by neighbors, or transferred by exchangers), so I dislike calling that "venting".

I think I can add a "Predictions" tab with the following details:

1. Heat generated by fuel rods (split into how much is fed to the reactor vs. how much is fed to neighbors).

2. Heat pulled from the reactor by various components.

3. Theoretical maximum venting (potentially into coolant).

Actual used cooling is harder to predict (or at least I haven't thought of a reliable, universal way to make my program do it) - perhaps this example will help to demonstrate:

01000B01000B000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000|esn

Until the left vent breaks (at 333 seconds), the right vent will be idle, but afterwards it will operate at full speed and give the reactor 2084 more seconds before it explodes.

Since your complicated design only feeds heat to the reactor, I thought that replacing the rods and reflectors with heat-capacity plating and starting the reactor with really high heat would allow the max HU output to be used to calculate the actual used venting, but that gave 1282 HU/t, which would correspond to 641 used venting, while simulating it as an automated reactor showed your manual calculations of 640 venting per reactor tick were spot-on - it ran for at least 357 cycles (based on components replaced) without going below 6000 heat or over 7280, and average output was 1280.00 HU/t. I'm not sure how it peaked at 1312 HU/t (26240 HU/s) output though (at about reactor tick 315 according to CSV data). Also note that the following components continued to have fluctuating output during the cycle: Advanced Heat Vent (R0C3), Advanced Heat Vent (R0C7), Component Heat Vent (R1C3), Component Heat Vent (R3C1), Component Heat Vent (R3C7), Component Heat Vent (R4C0), Component Heat Vent (R4C4), Component Heat Vent (R4C6), Advanced Heat Vent (R5C0), Advanced Heat Vent (R5C4), Component Heat Vent (R5C7), Advanced Heat Vent (R5C8)

When I asked for input from "others", I kind of meant besides you.

However, those are some good examples for helping me gain further insight into what the old planner meant by "vent cooling". For that first example, the old planner shows cooling of 0 (5), though I'd need to search decompiled code to find the logic it uses to determine that the component heat vents should be treated as having 0 vent capacity in this design. If I move things up and place a dual uranium fuel rod below the reactor heat vent (and use pulse configuration to make sure it stops before that vent breaks):

000000000000000000000000000000000000000000000000000000000000000C000000000000000C0B0C000000000000000200000000|epn|n3w|f2z60w

The old planner shows 17 (17), matching my planner. Is that what you meant by "changing components"?

The second example shows 0 (148) in the old planner, and remains the same if I remove all the component heat vents, which gives me a clue where to look.

The third example shows 0 (80) in the old planner.

On the other hand, one could argue that Talonius's planner is obsolete and shouldn't have to be matched exactly. Based on your own words:

Quote from KrisBigK

I think the key word in Omicron's post is "capacity". Here, it should mean the ability of venting heat.

and https://wiki.industrial-craft.…title=Component_Heat_Vent a component heat vent can reasonably be considered to have vent capacity of 4 per coolable neighbor (other vent types, exchangers, or coolant cells) - it has the "ability" to vent that much heat, even if it never uses it.

Edit: looking at the more complicated design you posted on GitHub:

0B230B0A140D0C0A122306230C0D0C0D0C0D0B230C0D0C0D0C0D0C0B0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D140A140D0C0A140D0C0A|fpn4mo|n5|f2

I think I'm starting to understand your manual calculations and what you want "effective vent cooling" to mean, but trying the closest approximation I can get in the old planner ( 21p7gjnnw20e91es8hy61d1c8mbcxzt9gitwjy3qlgkgbzr5pmf5mgmenu0v2cwebkf9i6v3l3tfcw0 ), either the "vent cooling" shown meant something different than what you're looking for or its calculations are buggy - at 0 initial hull heat, it shows 451 (608) vent cooling, and at 8400 initial hull heat, it shows 644 (664) vent cooling.

Quote from Omicron

Feature request: display the cooling system's total heat removal per second capacity and the fuel rod's total heat per second generation as separate values.

After some discussion in https://github.com/MauveCloud/Ic2ExpReactorPlanner/issues/36 I have realized I don't fully understand what these meant in Talonius's old planner (or maybe I did, and I've forgotten). Do others here (especially those that have looked at the source code) think my planner calculates these values appropriately? If so, how can I clarify what they mean? If not, how should they be calculated instead and why?

Quote from KrisBigK

Also, for the 1 bug/feature 1 issue thing, do you really want 20-30 issues being opened in a single day?

If you really still have that many ideas, go for it. However, I hope you won't be too upset if I mark some of them as "wontfix" (though I'll try to provide justification for that)

Quote from KrisBigK

Is reactor output added to the CSV output? It seems that I can't find it.

Sorry, I guess that one slipped my mind. I plan to take a few days break from working on the planner, but then this can be the first change to go into the next release. I am starting to see why some developers insist on one bug/feature per issue - having a bunch crammed into one issue makes it too easy to accidentally skip details like this.

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 Bundle.properties (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 Bundle.properties to a post in this thread. Please refrain from relying on machine translations, though.

Quote from albijoe

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.

Quote from KrisBigK

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)

Quote from albijoe

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.

Quote from KrisBigK

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?

Quote from KrisBigK

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.

Quote from KrisBigK

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:

Quote from KrisBigK

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

I think AE2 wants IC2 to take care of it, as already indicated in this issue: https://github.com/AppliedEner…Energistics-2/issues/3762

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.

Quote from Dogger

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.

Quote from Chezzik

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.

Quote from Chezzik

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.