Posts by Someone Else 37

    Oh? Where does he read? I have no idea why I don't seem to have P2P recipes. The IC2 compat is enabled in the AE2 config and I think the log file said it was enabling the EU P2P recipe, yet for some reason, it doesn't exist in the generated recipes directory. Same with fluid, etc, only the ME P2P recipe exists.

    Maybe you're supposed to craft an ME P2P tunnel, place it down, and then click it with an IC2 cable? I'm not certain about 1.7.10, but in later versions, I'm fairly sure that's how it works.

    So what stops the machine from accepting the first packet, getting only 30 eu because 2 were lost in the wire, accepting a second, and now it's at 60, with room for 4 more.. so it accepts a third packet, and... is overpowered?


    Also again, how do you use the ULV and higher than HV battery boxes when there are no corresponding sized batteries?


    I'm not certain that Greg's energynet works exactly the same way, but at least in pre-Experimental versions of IC2, it was impossible to over-amperage machines. Overvolt them, sure; but if a machine is given more packets than it needs, it'll just ignore the extras. If a machine only needed some of the EU in a packet, it would either take only what it needed and send the rest of the packet to the next machine in line, sending any excess EU not taken by any machines back to the generator or battery box from which it came; or just store the excess EU in its own internal buffer, and not accept any more packets until the buffer had drained some and was no longer overfilled. I don't remember which.


    If Greg's machines work the same way, you don't need to worry about giving them too many amps. It makes sense, really; in real life, current and voltage are tied together by Ohm's Law (Voltage = Current * Resistance). The voltage is dictated by your power supply, and the resistance is an intrinsic property of the machine; so the current will just be whatever it's going to be. You can't control the current except by changing the other variables. You might attempt to boost the current by lining up a bunch of batteries in parallel, but that would just make each of them drain more slowly.


    Greg's wires, however, certainly do have amperage limits (which, again, makes sense- the more current flows through a non-superconducting wire, the more energy will be dissipated as heat). So just make sure that your wires are big enough to handle anything that your battery boxes could possibly produce, and you should be fine. At least, if I'm not completely misunderstanding the mechanics.

    Looked it up and it is:
    "/Users/<user>/.gradle/caches/minecraft/net/minecraftforge/forge/<version>/unpacked/conf"
    which is difficult on a mac (as I am) because folders beginning with "." are normally reserved by the system and invisible.


    If you're familiar with working in a terminal, you can use "ls -a" to show those hidden files (ls, by default, doesn't list files that start with ".").


    If you're using Finder (or if you're in the familiar OSX file browser dialog box), you can press [Shift]+[Command]+[.] to show or hide hidden files, or [Shift]+[Command]+[G] to open a second dialog box in which you can just type the file path you want to go to.


    I don't know why OSX has so many keybinds that do useful things that aren't possible to do any other way and no built-in keyboard shortcuts guide (at least, none I've been able to find), but it does. The keybinds I do know showed up in Google searches.

    Likely thats intended. It used to protect you from hot pipes on GT5. Bet it carried over.


    If Greg set it up so that touching hot ingots and such deals fire damage (what else?), then everything that protects you from fire and lava would also prevent damage from hot metal.


    Makes sense to me.


    And I suppose the advantage in pincers would be in cost. Fire resistance potions are somewhat expensive, requiring a plant product and some mob drops only found in the Nether, while I assume that pincers only require a bit of metal (available in abundance by the time you're smelting it) and last a very long time.

    Searching this thread didn't help much because the term is so common in it, but could somebody please direct me to (or maybe just provide) an explanation of the "running costs" of reactors? I've been puzzled by it for a while. It can't be including the cost of making fresh fuel rods, because then there wouldn't be such a thing as a "zero running cost" reactor, and none of the reactor designs listed in the initial post mention iron or uranium, but I don't see anything else that would need to be replaced in them, even with the "high power high running cost" design.


    It's the material cost of anything that has to be replaced every cycle in addition to the uranium and tin (which is now iron in IC2e) for the fuel cells. This includes materials for neutronreflectors, fuel for condensators, and copper plates for dual and quad cells. When this thread was created, multicells required a great deal of copper in addition to the tin and uranium, which has also been changed in IC2e.


    In other words, zero-running-cost reactors refer to reactors that:

    • Do not use neutronreflectors
    • Do not use condensators, and
    • Do not use quad cells in IC2e or either type of multicell in pre-Experimental IC2.

    576 heat should be 1152 Hu/s So more or less the same as my setup. i would like to have an setup that get's me 1200Hu/s then i could go to 1800EU/t with only 2 secondary reactors.


    Unfortunately, that's almost certainly impossible. The problem is that, unless the physics of heat vents and exchangers has changed since Talonius last updated his reactor planner, the fastest exchanger can only transfer 36 heat per second (or 72 HU/t, apparently). So, you can cool a single cell no faster than 144 heat per tick.
    [offTopic]Wait, I can have transparent text? Cool.[/offTopic]
    The only possible way to get around this limitation is to put more cells in the reactor. Doing so runs into a second limitation: the amount of space in the reactor. Your cooler design fills all the available space, and mine fills it slightly more efficiently (with one more overclocked vent). So, there's no way to cool more than four cells at 144 heat per tick per cell in one reactor.


    However, as I write this I realize that by using more than four cells and cooling them more slowly, it might be possible to increase the total amount of heat drawn from all of them just a bit. This cooler is my first attempt at this. It *should* be able to cool four cells at 60 heat per second, two at 72 heat per second, and two more at 90, for a total of 564. This still isn't as good as the 4-cell 576-heat design I linked to earlier.


    In any case, you should be able to improve your cooling tower just a bit by swapping the component exchanger in the center with either of the component vents diagonally adjacent to it. This will only get you another 4 heat per second out of it in total, but saves you the hassle of crafting another OC vent and rearranging half of the components to get the other 8 heat per second that switching to my design would give you.


    Also, a tip for designing cooling towers in Talonius's planner: If your coolant cells are surrounded by any combination of exchangers of the same type, components that don't accept heat (i.e. component vents, fuel cells, plating, and empty space), and other coolant cells, you can replace the coolant cells with stacks of heating cells. If the other components don't overheat when you do this, the tower can dissipate at least as much heat per second as the product of the number of heating cells in the stacks and the number of exchangers that touch them. I used this trick when designing both of the coolers I linked to in this thread.


    There's no point in stacking more heating cells than the amount of heat the exchangers can transfer to other components each second. For one, they'll build up excess heat and either melt or dump it into the reactor hull; second, they won't be able to pull that much heat from the coolant cells anyway.

    Yes, AE2 import bus with fuzzy upgrade. I take them out at 75%, put them into the secondary reactor, cool them down to 25% (cooling them to 0% is more difficult/slower). I reach 1100-1200HU in the secondary reacor that way. (Does anyone know a more efficient Design for cooling coolantcells?) The 25% cooled down coolant cells go into an hopper above the primary reactor. A comperator on the hopper stops the reacor once there is no cool coolantcell left.



    Turbines now with Condensers. I wonder if i really get all water back.
    http://imgur.com/a/sPjmQ


    I designed this 6-chamber cooling tower a while back when I was mucking about with CRCS in MC 1.5. I don't think the reactor physics have changed too much since then, so this should still be pretty close to the maximum possible cooling rate. It won't ever get rid of the last few hundred heat, but that's no problem if you use AE to yank the coolant cells out when they're 75% cooled.


    Each component heat exchanger can transfer a maximum of 36 units of heat (that is, points of damage on the components; I have no clue how that corresponds to HU) per second, so the fastest that heat can possibly be extracted from a single coolant cell is 36*4=144 heat per second. The cooler I linked above cools four cells at that rate and fills the entire reactor, for a total of 576 heat per second and no room to squeeze anything else in.

    How on earth do you run mox in the 5x5 reactor? Since it puts out more heat at higher temperature, rather than more eu, you can't balance heat output with heat generated to maintain stable operation. You also can't regulate it with a fixed duty cycle. As soon as it the core temp rises by a single %, the heat output ramps up exponentially to meltdown.


    I guess Nuclear Control or some other way of measuring the temperature of the reactor and shutting it off automatically would be the only way... but even that's not without a great deal of risk. You're probably better off using traditional steam-free reactors with MOX. Assuming, of course, that those still work.

    Im using this desing http://www.talonfiremage.pwp.b…4j2wm5420w0ne8cgfo9hedxc0
    Can someone improve the effective EU/t output?
    if someone could take it up to effective 288 EU/t it would be much aprpeciated.


    It's perhaps easier- and always safer- to make a Mark 1 reactor instead of a Mark 3 with comparable average EU/t. Mark 2s and higher (with the exception of CRCS-automated mark 5s, which are for the experienced and slightly insane) are better for producing EU in short bursts.


    The second Full-Size reactor in the OP (300 EU/t out of a bunch of dual cells) should fit your bill nicely. At least in MC 1.5.2 or earlier... in IC2e, this reactor (like any reactor designed for pre-experimental IC2) might not work right.

    i think the way it can work is to set up the reactor with a storage bus and then have a level emitter controlling the toal amount of fuel rods of each type.
    Another way would be to have a level emitter for the depleted rods in the main ME network and turn on the export buses for the specific fuel rod.
    Important is that it never happens that 2 different types of rods are depleted.


    For a pure-AE solution, the first one is about the only way it can work- you'd normally set up a small network consisting of a controller and a storage bus on the reactor that's only connected to the main network by a Power Relay and a couple of import or export buses connected to ME Interfaces in the other network.


    For example, the mini-network (or sub-network in AE parlance) might only have a controller, a storage bus on the reactor, an interface set to stock a stack of empty fuel cells, and two level emitters. Attached to the Interface are two export buses and an import bus, all connected to the main network. The import bus is set to import the empty cells into the main network, while one export bus is set to fill the interface with fresh dual cells and the other with fresh quad cells. One of the level emitters (which is connected to the sub-network) is set to disable the quad-cell-exporting bus when there are more than two quad cells in the subnet (whose only storage is the reactor), and the other level emitter does the same, but with dual cells and the other export bus.


    This page on the AE wiki explains the concept far better than I just did.


    Alternatively, I just realized that Translocators would do the same thing just as well, but with only one or two fairly inexpensive blocks. Just attach them to an ME Interface set to stock a couple fuel cells of each type, and put a Diamond Nugget on the Translocator that's feeding the reactor before configuring it the same way.


    Could you post some screenshots of your setup? I'm mainly interested in the reactor, the machines directly feeding it, and the machines controlling those machines- the production and processing I could hack together easily enough.


    To my understanding, if you try to go the simple route and use an ME Export Bus to dump fuel cells directly into the reactor, it will make no effort to put the proper cells into the proper slots. When the dual cells expire (say the system replaced the quads correctly), the Export Bus will replace them with whatever's on hand, or with either fresh dual or quads at random (Ok, so it's probably not totally random, but I don't know what might make it prefer one over the other). If it replaces them with quad cells instead of dual cells, then you've got a reactor that's producing 1.5 times as much heat as it was designed to deal with, which could quickly lead to a meltdown. This is what I was referring to in my post. I think you misunderstood me in you last couple paragraphs- I wasn't even thinking about producing fuel.


    There are, however, a few things that could make your system work, most notably the Logistics Supplier Pipe or an Applied Energistics sub-network. Either could be configured to keep the reactor stocked with a precise number of cells- in your case, two dual and two quad. Once the dual cells expire, the subnetwork (or LP network) will request two more to replace them. These will be injected into the reactor, and 10-15 minutes later, the quad cells will be similarly replaced. Which is all well and good, unless something goes wrong. Should the system fail to replace the dual cells during the 10-15 minute window before the quads burn out, it may well put a quad cell where there should've been a dual cell, potentially turning something like this Mark I into this Mark II-1, which could eventually explode if your automation keeps up with it.

    You can easily automate reactors with different rod size if you use AE. Just load up the reactor, start it up, wait for 5-10 minutes, and then change 2-cell rods for a fresh ones. That way 4-cell rods will expire faster, get replaced by AE import/export buses, and then, 5 minutes later, 2-cell rods will expire and get replaced too.


    What's to keep AE from replacing rods with the wrong ones? Logistics Pipes or an AE Subnetwork could be used to keep the reactor stocked with the proper number of each type of rod, in which case, your setup certainly could work; but export buses alone aren't smart enough to do what you want them to do. There's nothing to keep them from replacing smaller burned-out cells with larger ones, which could easily be catastrophic.


    Even if you are using LP or a subnet, if your system runs out of one type of cells, but still has access to the other, it may put them in the wrong places, which could also cause problems.


    Depends on what you mean by "better". If you want to make the most out of your uranium, and don't care about burning lots of other resources, then what you've come up with is as good as anything I've seen. However, neutronreflectors are a huge trap because they burn up after every cycle, and are quite expensive to replace. If you use UUM to replace them, your effective efficiency will drop a lot. Before IC2e, it would probably drop from 7 about 3; in IC2e, it might make your rector entirely unsustainable.


    If you're OK burning lots of tin, copper, and whatever else form other sources or crafting unbreakable Iridium Neutronreflectors from GregTech, that's fine. But normal or thick reflectors are usually a waste of resources.


    CRCS, while dangerous and tricky to automate, can get an efficiency of almost 6.0 while also producing ludicrous amounts of power, as opposed to your mere 140 EU/t.

    This is a Mark 1 that produces 100 EU/t.


    This is the first Mark 2 that I managed to put together today. It's much more expensive than the Mark 1 linked above and only produces 40 more EU/t, which I don't think is worth it. Also note that none of the heat goes into the reactor hull, so you won't be able to automate it with Nuclear Control. Just make sure that all the heat bars on the components- or at least most of them- are gone before you stick in any new fuel cells.


    Wouldn't that just make the algorithm fill the reactor with only MOX fuel?


    No, it would only block the Basic, Reactor, and Advanced Heat Exchangers and the Reactor and Overclocked Heat Vents. These are the only components than remove heat from the reactor hull- designs that use them tend to cool down over time, which is not good for MOX reactors. MOX fuel burns more efficiently when the reactor is hot, so you want MOX reactors to stay hot all the time.

    Yes and no. The final phase of the genetic algorithm (the "promoted" population) is essentially an annealing/fine-tuning phase, where it only makes minor tweaks to make small optimizations, without changing the overall design. This could be applied to human-generated designs to make minor improvements. However, *only* minor improvements would result. Human-generated designs would lack genetic variability, which is key to the correct function of genetic algorithms. In DNA terms, human-generated designs lack introns.

    But I would think that finding minor improvements to an existing design would be much faster than coming up with something on par with a human-created design first, even if you had to create some new variations yourself. You've said this thing takes days to run- clearly, time isn't a concern. If it was, though, I would try feeding your program something from the Official Reactor Designs thread, and seeing what it comes up with.


    I'd be interested in having a contest between this genetic algorithm and a human designer. Specify a set of exact requirements on which designs are evaluated, pick the current best human-generated design, and see if the genetic algorithm can find a better design - without any help or pre-seeding from the human design. It's quite possible that this could outperform the human design process, making pre-seeding it with a human-generated design completely unnecessary.

    I'd like to see that, too. Say you're looking for max EU/t from a 0-chamber reactor (3 columns) using only single cells. This design is already engineered for precisely this purpose.


    Only the very first generation is random components thrown together. Complex patterns arising in the result doesn't imply intelligent design - just as the complex arrangement of molecules and cells in animals doesn't.

    Of that, I am very well aware. I was specifically referring to designs that looked something like this amid obviously random nonsense. Columns of single cells topped with dual cells isn't something I would've tried, but that's the whole point of having a computer try lots of things.


    I haven't coded in support for MOX fuel cells yet. I may add support if there's enough interest, but the result would likely take longer to stabilize, as exact equilibrium is harder to achieve using annealing-style techniques. Also, if I do add support for MOX cells, it wouldn't rate reactors based on the equilibrium being achieved - it would rate designs based on the same basic factors, eu produced, cycle time, efficiency, etc. The nature of the algorithm is that many different approaches can achieve the same result. Consider the case of a reactor that (somehow?) produces a sinusoidal wave of heat. While not in equilibrium, such a reactor could potentially have better overall results.

    MOX fuel works exactly like normal fuel, except it burns half as long and produces more power if the reactor is hotter. With normal reactors, you want them to cool down faster than the uranium heats them up, in case something goes wrong. However, with MOX, you want it to be balanced, so the reactor stays hot after you heat it up. Additionally, designs that do not transfer heat between the reactor core and the components are even more preferable, because they don't cool down after the fuel expires.
    All you'd need to do is edit your scoring algorithm to give reactors with more balance and less core transfer higher scores.


    Also, I'm pretty sure fluctuating heat is impossible- unless you count Mark 1s and 2s periodically running out of fuel; Mark 3s, 4s, and 5s periodically being switched on and off; and the last couple hundred heat bouncing around in things like this cooling tower. While your point may be valid in some cases, I don't think most players want to use a MOX reactor that cannot remain stable at 85% heat- anything cooler means a smaller MOX efficiency boost, and anything hotter means stuff will start melting into lava.


    The way these types of algorithms work, they "figure out" what needs to occur to get to the end goal (which is an efficient reactor that doesn't explode), instead of being programmed with intermediate goals (such as trying to balance heat transfer). This allows them to approach problems (insofar as random mutations are an approach) in ways that a human may have not even considered.

    But balanced heat transfer IS an end goal- arguably the most important end goal- of a MOX design, and not using components that interact with hull heat is the best way to fulfil it. As I noted above, you'd just need to work that into your scoring algorithm, alongside cost, efficiency, output, etc; or follow SpwnX's suggestion and ban basic, advanced, and reactor exchangers as well as reactor and overclocked vents altogether. You wouldn't even need to take special action against designs that put heat into the reactor hull with the latter suggestion- with nothing to take it back out, all such designs would explode.

    What happens if you start it off with some human-created designs already known to work well, instead of whatever random mish-mash it generates randomly? Would is be able to find improvements that have slipped our engineers' brains?


    Also, I see that a few of the designs on that page look kind of intelligently built, rather than a bunch of random components that happens to not explode. Keep up the good work.


    And, a final suggestion: Make it work with MOX by having it really like designs that do not heat up or cool down over time while running, and like designs that don't cool when turned off either even more. Heat dumped into hull equalling that pulled out by vents and things is good; the smaller those rates are, the better.


    Are you running an old version of IC2e? I know some of then had bugs where MOX output depended on the exact location of cells within the reactor. But other than that, I don't know what could be causing this.


    Hmm... You talk about turning things into lava. That was re-added after the placement bug was fixed.. so it's not that.


    With the quad cells above the dual cells, the bottom row of vents and exchangers can dissipate or spread around some of their heat. With the quads on bottom, there's less heat in the hull for them (I'm guessing the Reactor Exchangers have the most effect) to take, so then the quad cells dump more heat into the hull.


    Hypothesis: Hull heat for meltdown purposes is determined by the heat after all components have been ticked, while hull heat for MOX bonus purposes is the peak heat during the last tick. Or maybe the heat at the time when some MOX cell was last ticked.


    Can anyone verify or refute this?


    Looks like you've found what happens when you use an outdated reactorplanner to test reactor designs in an updated IC2!


    I remember that reactor cooling systems got buffed by a factor of two a while back; it looks like you've found a design that makes use of this.
    Also note that the component vents in the upper corners of your design are doing nothing at all- they can only vent heat from adjacent components that store heat, which uranium cells don't. You can just remove them, and the behavior of the reactor won't change.


    If your reactor is in fact stable, then it's a Mark 1. Be hesitant about believing anything that the reactorplanner says when you're using IC2 Experimental.