Posts by Someone Else 37

psusi wrote:

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.

psusi wrote:

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.

*error user name found* wrote:

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.

There's also Blood Magic's teleposers, which can teleport up to a 9x9x9 volume of blocks (if not more; I don't remember offhand) instantly to a matching teleposer, even across dimensions. They work on entities, too, but transporting them across dimensions has been iffy in the past.

SpwnX wrote:

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.

MauveCloud wrote:

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.

Blood Asp wrote:

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.

Blood Asp wrote:

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.

psusi wrote:

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.

feral wrote:

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.

yeganer wrote:

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.

Lime wrote:

Looks like you didn't get the idea of timing.
First of all, it's tested and it works.
Second, AE set up to import depleted cells of both types and export fresh ones of both types.
Look:

:Advanced Machine: :Water Mill: :Wind Mill: - heat vents
:Uranium Cell: - double fuel rod, :Coal Cell: - empty double fuel rod
:Lava Cell: - quad, :Empty Cell: - empty quad

Initial load (simplified):
:Wind Mill: :Water Mill: :Wind Mill: :Water Mill:
:Water Mill: :Uranium Cell: :Lava Cell: :Wind Mill:
:Wind Mill: :Lava Cell: :Uranium Cell: :Water Mill:
:Water Mill: :Wind Mill: :Water Mill: :Wind Mill:

After 10-15 minutes replace slightly damaged dual cells :Uranium Cell: with fresh ones.

State after 2 hours 44 minutes (1 full cycle):

:Wind Mill: :Water Mill: :Wind Mill: :Water Mill:
:Water Mill: :Uranium Cell: :Empty Cell: :Wind Mill:
:Wind Mill: :Empty Cell: :Uranium Cell: :Water Mill:
:Water Mill: :Wind Mill: :Water Mill: :Wind Mill:

AE imports depleted quads (note the untouched doubles, because they're still have 15 minutes to burn):

:Wind Mill: :Water Mill: :Wind Mill: :Water Mill:
:Water Mill: :Uranium Cell: :Wind Mill:
:Wind Mill: :Uranium Cell: :Water Mill:
:Water Mill: :Wind Mill: :Water Mill: :Wind Mill:

AE exports new quads into two empty slots:

:Wind Mill: :Water Mill: :Wind Mill: :Water Mill:
:Water Mill: :Uranium Cell: :Lava Cell: :Wind Mill:
:Wind Mill: :Lava Cell: :Uranium Cell: :Water Mill:
:Water Mill: :Wind Mill: :Water Mill: :Wind Mill:

10-15 minutes later same repeats for doubles.

Again, it's tested and it works.

First of all, if your reactor has efficiency > 3.33 - then this is not a problem, as it produces more EU than it is required to generate uranium ore out of the matter.
Second, that's your job to automate production of fuel cells. To prevent filling reactor with 4 quads, use toggle bus and level emitters: If level of certain cells drops below limit, just turn off the cable that goes to reactor. And maybe light up a red lamp in control room.

For example, my closed/dedicated reactor supply line system consists of:
Mass fabcricator (constantly fed with scrap). 2 replicators - one for iron ore, one for uranium ore. 6 auto-workbench for crafting fuel, mox fuel, plutonium, dual uranium, quad uranium, dual mox. Macerator > Washer > Thermal Centrifuge. Metal former for iron plates > for cells crafting and fuel rods. Metal former for fuel rods. Canning machine. 2 uranium reactors, 4 mox reactors. Always keeps in stock 40 mox cells, 120 uranium cells of both types. Runs replicators when out of stock of anything.
Works like a swiss clock.

Display More

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.

Lime wrote:

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.

feral wrote:

I was searching in the pages and i found this reactor...
http://www.talonfiremage.pwp.b…misohrg5twy0lvrik4pqlunls

i like it becouse it uses the most of my uranium and i don´t have a lot.
i was playing with it around in the designer and notice it waste a lot of material and make some changes.
This is my final product atm.
http://www.talonfiremage.pwp.b…vlxarxor5fwxm17vhcznvzxmo

Its something bad about my desing or its better?
Is there any better for a quad uranium?

Display More

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.

hoho wrote:

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.

crispy1989 wrote:

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.

crispy1989 wrote:

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.

crispy1989 wrote:

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.

crispy1989 wrote:

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.

crispy1989 wrote:

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.

snahsnah wrote:

Hi guys,
I was experimenting with the exact amount of heat when reactors start turning blocks into lava.

I noticed that this reactors runs smoothly until 1238 eu/t, http://www.talonfiremage.pwp.b…w23tu08tq6y4dekwg6qo5zntg

but this one only gets up to 1232 eu/t before it turns blocks into lava. http://www.talonfiremage.pwp.b…w23tu08tq6y4da8gqaq32niok

Any ideas why?

Display More

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?

Joannou1 wrote:

^^^
As a noob, I have been messing around with the designer all day..
After a lot of trial and error, I have created (the worlds first?) stable MK5 reactor.

MK5 - Designer

Outputs 340 EU/t
I think the efficiency is terrible, 2.4?
It's been running for over an hour now and no components are degrading.

I am not sure why this works, as the designer indicates a failure.
If anyone knows, leme know.

Display More

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.