Posts by KrisBigK

    I checked your map, i loved the way you stacked all reactor and your mox design but you use a lot of redstone which as you said can cause lags and i don't find it a good way to automate ic2 stuff .

    Redstone dust itself doesn't cause a lot of lag, it's turning it on/off that cause lag due to the tremendous amount of block updates that it cause. For the machine part, I have tried to optimize the lag when it's idle wit the help of LagGoggles.

    I modified a bit my design, now i'm using a weighted item distributor to send iron plates in priority to canning machine then batch crafter, it makes a buffer of 128 iron plates but for now it's working but i wish the sorting machines would be able to also sort quantity (i'll make report on mantis, in case it's a bug).

    I think it is better for you to make a thread in the suggestions forum, since this is more like a feature request/suggestion than a bug.


    For your EU issue, i know the splitter cables doesn't work, you still can use 2 transformers to achieve the same goal but beware of wrong wiring (RIP my old mining factory, only 1 machine wrongly wired on 2048 instead of 512 destroyed the entire building ).

    Since my map has 20 reactor in it and each generates about 600 EU, I don't think that a few transformers will work because of the extremely high amperage (and it will be bigger if more reactors are put in there).

    If i put a stack on iron plates it will seperate this stack at 33% on the north and 66% on the top so my design would work but if i put iron plates one by one (like a metal former) it will send everything to the north, i don't know if it's a bug but i would like to be able to send exactly 1 iron plate on north then 2 iron plates on top.


    Any ideas ?

    You could use hopper minecarts and hoppers to distribute the items into the exact amount that you want with a cost of a comparatively high lag.


    Actually, I've made a fully automatic MOX reactor including fuel rod recycling, uranium production, etc. The reason why I haven't shared it yet because sometimes I stumble into problems like the EU stop flowing and I haven't finished the product treatment. This is like a pre-release version and I currently cannot guarantee that it will work 100% (and probably in the future).

    Players generally don't like the idea that if they set up a component production line, it will consume inputs until every machine input and output along the way has a full stack of intermediate products. As a result, they tend towards overly-smart logistics networks like AE, where the network is in charge of putting exactly the right inputs in so that nothing gets wasted, but I think that it would be nice to have the Factorio-like option of letting full inputs produce natural backpressure with an acceptably-low overhead, so everything can pull directly from storage.

    I don't like item stacking mainly because if hoppers are involved, they will create a tremendous amount of lag (often more than 100 μs per tick per hopper). However, I personally like to use redstone to lock the hoppers when they aren't needed to reduce the lag, and I avoid using other mods whenever possible. Also, no thing is wasted - the items there just don't get used.


    Your idea about the stack size limit is great, but I think that the accept limit is better to be (64 - N) * one craft, and the output threshold (63 - N) * one craft, otherwise only 1 upgrade is enough.


    I don't know how best to handle cases where different recipes take different counts of the same input item, perhaps a "recipe lock" upgrade would also be useful.

    I believe an IC2 machine only take one recipe at a time. I like the recipe lock idea as it can act as a item filter.

    I get the impression you're not a programmer, otherwise you probably wouldn't have even suggested this:

    "3. Simulate my manual calculation (The most complicated but accurate if done correctly)"

    Yes, I'm not a programmer, but I have some programming experience.

    Details on how to do it:

    1.Divide the components into sections (components in separate sections cannot exchange heat directly except through the reactor hull)

    2.Calculate usable vent cooling (limited by heat exchanger transfer rates), hull cooling for each section

    3.If a section contains components directly heated by fuel rod(s):

    3a. Calculate heat generation of the fuel rod(s)

    3b. If vent cooling + hull cooling >= heat generation then add vent cooling of this section to output

    3c. Else ...

    4.Else

    4a. If hull cooling <= vent cooling then add hull cooling of this section to output

    4b. Else add vent cooling of this section to output



    EDIT: My ideas on section division: Make separate sections as lists


    Start with the left-top component

    .1.If this component can accept/generate/transfer heat (excluding the component heat vent) then

    ...2.If this component is in current lists then

    .....2a.Go to 1 and check for the next component

    .....2b.Else create a list and add that into the list

    .......2c.If the component next to this one (on all 4 sides) cannot accept/generate/transfer heat (including the component heat vent)

    .........2d.Go to 1 and check for the next component

    .......2e.Else add that component into the current list

    .........2f.Go to 2c and repeat

    erp=N1c9dkJNpnU4/nE6kiX7ayavN00qGbuWTELKGQ20dNFgC6HAQT+3WMJyCo+8to4vnu99U5sA

    2302130C000000000000230C0000000000000000000C000C00000000000C0D0C0D0C00000000000C000C000000000000000000000000|esn

    This design seems to not work with the ideas too. You might have forgotten the possibility of components heated up by rods directly and then put their heat into the hull, and then cooled by components that pull heat form the hull. This would also have trouble calculating hull cooling. The reactor heat exchanger will pull heat only if its damage percentage is greater than that of the reactor.


    0302130C09110D0C0A03010C0D0C0D0C0D12010C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D0C0D110D120D120D120D11|esn

    For this one, there will be trouble with hull cooling. The heat exchanger at R0C5 cannot pull heat from the hull, because it is heated too much by the vents. That can be seen by replacing it with a component heat exchanger.

    Some ideas about calculating “effective” vent cooling:


    1. Generate a adjustable amount of heat and test for the stable one with highest possible heat generation


    2.Use pulsed controls to determine heat vented (Only possible for unstable reactors unless having a negative off pulse)


    3. Simulate my manual calculation (The most complicated but accurate if done correctly)


    I’m leaving for now. I’m going to reply in 9 hours.

    Because these are details that can be predicted ahead of time by the program (without actually running a simulation).

    Then what do you call it after running a simulation? Still calling it "predictions" doesn't make sense.

    Seems that example kind of turned the tables on me, though this one runs long enough that average HU/t output of it as a fluid reactor can be used for calculating an estimate of that - also, CSV data claims this design as a fluid reactor will output 360 HU/s very briefly at the moment when the left vent breaks. That might actually be a bug, but if so, it may be quite difficult to track down, and I want to try the design in-game first (to make sure it really is a bug). Edit: Brief 360 HU/s confirmed in-game.

    Since you want "a reliable, universal way to make my program do it", calculating the output of the corresponding fluid reactor won't work because it isn't universal. At the tick the vent broke, the left one vented heat and broke, while the right one kicks in because the left one can't absorb all the heat.


    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.

    Key word from my post: more. I said 2084 more seconds, because without the right vent, the reactor will explode at 1582 seconds. 3666 - 1582 = 2084.

    In your original post, "afterwards" refers to the time the left vent break, which is at tick 333. Then 333 + 2084 = 2417, not anywhere close to the explosion point (tick 3166) with the right vent. In your original post, I never saw/interpreted the meaning of "without the right vent". Maybe you just forgot to say that.

    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. :(

    There are some that I know of, but they aren't as active as me, and I doubt about their English skills. Having them as interpreters will slow down the conversation a lot. I just want you to be aware of my English skills, not to clarify things.

    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

    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 have never seen that before because I go on the FTB wiki to look for component information. As for "Hull Venting", what about calling it as "Hull cooling"?

    Why do you call that "Predictions"?

    1. What do you mean "fed to the reactor"? Do you mean raising the hull temperature? Or does it include heat fed to the reactor and then pulled out by components?


    The example that you gave is caused by the reactor ticking algorithm. Since the reactor ticks from the left to the right, the left fuel rod dumps 4 heat into the reactor, and then all pulled out by the reactor heat vent. Then, the fuel rod next to it dumps 4 heat into it again, and left the right vent idle. The vent can only vent 5, so heat stacks up by 3/s.

    In that case, I would say that actual used cooling is 5, with a probable exception in the tick when the left vent broke.

    Also, you might have done the math wrong. "Reactor will explode at 3666 seconds." How did you get 2084 sec?

    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)

    Really? My CSV output didn't show that. I think the fluctuating output is caused by the component heat exchangers.

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

    I am aware of that, but I still replied with these examples so that I can rule out more possibilities of misunderstanding.

    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|f2z60


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

    Unless you add another component heat vent to the bottom slot, that is what I meant by "changing components". To be exact, I meant that the reactor heat vent should only have passive neighbors that don't exchange/add heat to the reactor heat vent, so the problem of calculating component vent cooling in your planner can be seen better.

    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.

    00000C0000000C0000000C0A0C000C0A0C000C0A140D0C0D140A0C000C0A140A140A0C0000000C0A0C0A0C00000000020C020C020001|esn

    I believe that is a problem with the planner calculation. When I put the fuel rods in that generates 76 heat/s, the reactor heat increases by 4 heat/s, which means that it should only be able to vent 72 heat/s.

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

    000000000000000000000000000C000000000000000C0D0C01000100000C0D140D0C02000000000C0D0C020002000000000C02000200|esn

    That looks like a bug with the logic the old planner used to determine whether the component heat vents should be treated as having 0 vent capacity.

    I added the fuel rods in, again. In your planner it showed "Total Vent Cooling (peak usages): 128.00 of 128.00", which is correct. Adding another fuel rod will cause the OC vents to exceed its maximum venting capacity and break.

    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: "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.

    I admit that I don't know much about Talonius's planner and the versions of IC that it worked with or the reactor component behaviors at that time, so I'm not going to argue with that since I started playing IC2 in the summer of 2017. 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.


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

    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?

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



    Some of my ideas here:


    000000000000000000000000000000000000000000000000000000000000000000000000000000000C000000000000000C0B0C000000|esn

    This design can only vent 5 heat/s, since the reactor heat vent can and only pulls 5 every second and it can vent 5 heat that it pulled. Also, if the reactor heat vent is damaged, which is impossible without automation or changing components, then it can vent 17 heat/s until it got repaired as it is shown in the planner.


    00000C0000000C0000000C0A0C000C0A0C000C0A140D0C0D140A0C000C0A140A140A0C0000000C0A0C0A0C00000000000C000C000000|esn

    A more extreme example: Do you think that this can vent 260 as it is shown in the planner without changing components? For this one, the capacity of total heat removal per second is limited by its ability to pull heat - it only has 2 OC vents that can pull heat.


    000000000000000000000000000C000000000000000C0D0C00000000000C0D140D0C00000000000C0D0C000000000000000C00000000|esn

    In this example, the total heat removal per second capacity is limited by its ability of venting heat (not considering OC vent breaking), which (I believe) is correctly calculated at this moment.

    Although your description is enough for me to see the problem, could you please share a screenshot of your design or the reactor code generated by MauveCloud's reactor planner so that others can see it better?


    The problem is with the condensators. They can't take in heat forever and need to be repaired with lapis lazuli or with a reactor coolant injector. After the condensators disappear (break), the fuel rod will dump its heat directly into the reactor hull instead of the condensator that was there, causing it to explode.

    The MOX rods generate more EU when the core temperature is higher in an EU reactor, so that you see it producing more EU than using Uranium rods.

    With normal fuel rods, you just need to wait longer for it to explode since it generates less heat per fuel rod.

    Also, the current reactor output is capped at 8192 EU/t. No matter how many fuel rods you put in, it can only generate a maximum of 8192 EU/t. You can measure this with an EU-reader.

    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.

    Enjoy your break! You did a lot of enhancements recently.


    Also, for the 1 bug/feature 1 issue thing, do you really want 20-30 issues being opened in a single day? Although it is easier to track every single one of them, it is more like spamming with good contents and I also need to open that many tabs to reply to every single one of them. I can do that separately if you want it.

    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.

    I tested again in 1.7.10, and in that version 1000 mB of hot coolant generates 10000 EU with stirling generators, which is the same in 1.12.2. It might be due to a display bug that didn't got backported. In 1.12.2, the same design outputs 8 mB hot coolant/sec, so display in 1.7.10 should be wrong. It seems that Chocohead only goes on the forum every day - He has not replied to anything in IC2 bug tracker for about a week.

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


    Also, there is a Github page for the planner. Reporting bugs there is also an option.

    I managed to compress your first design into 4 chambers to make stacking easier, and yes that should have no problem handling UU regen.

    00230C0A120D0C00002306230C0D0C0A000000230C0D0C0D120000000C0D0C0D0C0D00000C0D0C0D0C0D0C00000D140A0C0A140D0000


    For the second one, I think you might have done the math wrong. The design actually outputs at 1352 * 0.75 * 20 * 10000 = 202,800,000 EU. You might have forgotten to multiply it by 20.

    With that ejecting drill bug fixed, it is so much easier to design a cobble generator with miners.

    I just designed one that is random tick proof:

    There are 2 miners that are next to a recycler. A batbox is enough to power 2 of these combinations. The glass in the picture is optional - I just put it there to prevent fire generated by lava. I put a debug item into the bottom slot of the batbox to make it an infinite EU source.


    Since this is most likely be used for scrap production, I only used normal drills and OD scanners to reduce EU cost per scrap. 1 lava source will be enough for 4 miners, but I put 2 there so that there is at least 1 cobble between the miner and the ore. I'm not certain if this is necessary.