Posts by Kenken244

    Or you could use the dev version which is for 1.4.6. Redpower usually does end up being the best transport method for this, mainly due to the sorting machines. you would want to be using redpower logic anyway for the timing (computercraft doesn't work, since the timer resets when the server restarts)

    I am not sure how many you will need for a thorium version. you just need to take the total heat generated per pulse, and divide it by 20 to get the number of vents needed. then just make sure you have room for them in cooling reactors.

    That is a symptom of the sorting machines getting out of synch. they no longer pull in unison, making there be times when the slots are empty. This happens wen you reload the game. I am working on a design that avoids this problem, but in the meantime, breaking it and replacing is a temporary fix.

    That has happened to me before, there are two main causes that I can see. The first is the sorting machines becoming synchronized by saving and reloading. the only solution is to break them and replace them. Sometimes this can also happen if you turn the reactor on and off very quickly. in that case it is a simple matter of manually distributing them evenly again.

    I thought I would give a bit of an update on this. The automation setup I used works very well, until the server restarts (such as by quitting and reloading) then the sorting machines become out of synch. Theoretically, they should automatically synch themselves, but that does not seem to be the case. I am currently working on a way to force the sorting machines to pulse in synch with each other. Fortunately, with the safety systems, this does not result in an explosion, but the reactor flickers, which significantly reduces eu/t output.

    This is certainly an interesting idea, However, I don't think this will ever manage to be more efficient than DDoS of HVC reactors, as they require less movement, and use more efficient cooling configurations. this might work, though if the hull is used as a heat sink, though cooling that would require a very complex setup that would be difficult to automate.

    probably. especially since gregtech lets you triple your copper output. I guess gregtech users should just judge their own. Although, that still would be worth it, using a DDoS or HVC reactor, since you get much better efficency, or using plutonium.

    Just ran some numbers. the energy cost of copper c=from a centrifuge is 16*30000 (potential energy generated) + 50000 (centrifuge energy consumption) /4 (the recipe produces 4) = 132500 eu per copper using lava. It also conveniently produces tin as well, in the proper ratio for producing neutron reflectors, so you can safely discount tin costs.

    That sounds like a good general metric. I wonder if it might be good to also make a gregtech metric that is based on centrifuging lava? both in energy costs and opportunity costs, since uum costs way too much in gregtech to consider using for reactor maintenance.

    that would have to be some pretty severe tick lag, if it makes the sorting machines not pulse for the three seconds it would take for the vents to melt. plus extra since there are a few extra vents sitting in the adjacent relays. especially coupled with a nuclear control heat monitor. It could, however be a concern in a plutonium reactor, since only 2 seconds are needed to melt the heat vents in that case. In any case, I have run this for several cycles, and not gotten any hull heat buildup. The redpower sorting machines will automatically synch themselves with the reactor, so no matter how I try to mess with them, they always fix themselves without a hitch.

    The reactor system shown in the OP runs without a hitch. I have not had any hull heat buildup over the course of several cycles, using the constant cycling. due to the way sorting machines work, the vents are swapped in a single tick, leaving no time when the slot is empty. in addition, the gate on top completely prevents the reactor from pulsing if one of the vents were somehow missing. also, your math is wrong. you are calculating the amount of heat from two second cycles, but only the cooling from a one second ( at least, I think. Your math is definitely wrong, since my setup runs perfect with 4 3 chamber reactors, without pausing at all.)



    EDIT: that's odd. After reloading the save, the gate conditional stopped working. It constantly has the bar highlighted saying that the inventory is full, but the redstone signal flashes anyway. It was working fine earlier, and breaking and replacing it doesn't seem to help. oh well. It's not very necessary anyway, as there has never been any hull heat buildup with or without it. A Nuclear control heat monitor should work fine.


    EDIT EDIT: Now after changing it to an iron gate, it works fine. I have no idea why this is.

    As those of you who keep up with the DDoS reactor thread will know, I have been experimenting with a new reactor concept. I though it time to post my findings in a thread of its own. Therefore, allow me to propose the Heat Vent Cycle reactor.


    The Heat Vent Cycle reactor (HVC) is similar to the DDoS concept, in that it involvesthe exchange of heated components to cooling reactors. However, the chief difference is that the HVC reactor exchanges heat vents instead of coolant cells.


    The intended advantage of such a design is that expensive cooling tower designs would not be required, as no components would be needed for exchange of heat, nor any coolant cells. This would however create a very short microcycle time, meaning that automation would become a challenge if you want to be able to create a good effective EU/t


    Given that this reactor design centers on the exchange of heat vents, we should talk about heat vents first. We can safely discount both the advanced and reactor heat vents for this purpose, as they both provide less cooling than a cheaper alternative.


    This leaves us with normal heat vents and overclocked heat vents. Since microcycle time is not a consideration in this design, we need only analyze the cooling provided versus the cost. As you know, normal heat vents provide 6 cooling for approximately 6 iron.


    Overclocked heat vents provide 14 additional cooling, at the cost of an additional 16 copper and 2 gold. This provides a much better cooling for a given amount of iron, but at the cost of significant amounts of copper and a handful of gold.


    Bear in mind that a standard heat vent setup would require over three times more total reactor chambers to provide the same amount of cooling. This eats up additional copper and iron. Frankly, the small gold cost of the overclocked heat vents is easily worth the extra gold cost.


    However, we are neglecting another, perhaps more efficient heat vent: the component heat vent. Now, the CHV cannot hold any heat on its own, so it must be combined with other heat vents to improve their efficiency. They provide a theoretical maximum of 16 cooling for an additional cost of 4 tin and a bit of iron. This would be much cheaper from a gold and copper standpoint, though is more costly in terms of iron and tin.


    A theoretical amount of cooling is all well and good, but for a proper analysis we must account for the cooling a CHV would provide in practice. To do so, we must analyze potential cooling reactor designs.


    But before we get ahead of ourselves, what are we going to be cooling? The reactor design in this case is just a slight modification of the standard DDoS design, replacing the Cooling cells with heat vents. We end up with something like this.


    But what about the cooling reactor? Assuming you aren’t using component heat vents, you simply need to shove the heat vents in a reactor and let them cool themselves. Because this makes the reactors basically a glorified chest, one can simply base the cost on total number of chambers required, and the number of heat vents necessary.


    Now, to cool the reactor above without CHVs, four reactors like This would be required. They cost 772 copper, 258 iron, and 72 gold each, for a total of 3088 copper, 1032 iron, and 288 gold.


    An alternative design using CHV, such as this, would require 724 copper, 112 tin 422 iron, and 54 gold each, for a total of 2172 copper, 336 tin, 1266 iron, and 162 gold. So it is a savings of 66 gold, and 916 copper, at the cost of 234 iron and 336 tin. There is also one other consideration, and that is the size and shape of the CHV reactor makes it difficult to automate in a compact manner. This is actually an important consideration in terms of resource cost, as will be detailed later.


    Now, unless you are planning on manually swapping the heat vents using your Uber-1337 Ctrl-Shift-clicking skills, you also need a way to automate the exchange of vents. This is easy enough, but there is one other problem: the microcycle time is only 2 seconds. This means that if we are to have the reactor run smoothly at all, we must exchange the vents while the reactor is still running. There are a myriad of ways to do this, but for our purposes we have a few special considerations. Any method used for this automation must:


    *Be able to distinguish between cool and uncooled vents


    *Be capable of exchanging all 8 vents every second, using a limited number of facings


    *Be reliable enough to ensure that no components melt, and that no heat reaches the hull


    Through my experimentation, I have found that redpower sorting machines make an ideal candidate. They are capable of distinguishing cooled vents, and in automatic mode, they pull at a regular 2 times per second. This means that with 4 sorting machines and 4 relays, one can exchange every vent every second, and still have facings left for redstone and wiring. They also are ideal for pulling cooled vents out of the cooling reactors, as they will pull vents as soon as they are completely cooled.


    An example of such a setup is here


    You can see in this picture an example reactor setup (and bert the slime, who likes the heat coming out of my heat vents) The central reactor has 4 automated sorting machines with damaged vents in their filters, that pull out the vents and put them directly into the cooling reactors, which in turn have 4 sorting machines that pull out the cooled vents. On top there is a simple gate that emits redstone as long as the reactor is full, ensuring the reactor does not pulse if one of the vents were somehow missing.


    You notice that the design is also very compact. This is actually an important consideration because there will always be heat vents moving around in your system. The longer the tubing between the reactor and the cooling towers, the more vents are needed to “saturate” the system. Since you will need about 1 vent per block of tubing, this can add up quickly.


    Now, how about our goal? We produce the same amount of energy as a DDoS design, but did we succeed in being cheaper? We have to compare it to the cooling designs of your standard DDoS setup. Our Heat Vent Cycle Reactor inherently beat out any cooling design that uses overclocked vents as its main method of cooling, as we save out on the cost of coolant cells and heat exchangers. That leaves us with the standard component heat vent system of cooling for comparison. That gives us something like This, cooling 336 heat, meaning you would need 8 cooling reactors to run it in a “mark I” fashion. At 508 copper, 1651 tin, and 273 iron each, that brings us to a total of 4064 copper, 13208 tin, and 2184 iron. But no gold!


    …Yeah, I think we beat it.


    Now that does not mean that DDoS reactors are useless. Our HVC reactor can only be run in a “mark 1” fashion, due to the extremely short microcycle time, and having to exchange while the reactor is running. This means that we have to build all of the cooling reactors right away, while in a DDoS reactor, you can run it in a “mark II” or “mark III” fashion, which requires much less investment. Also, I have not (yet) been able to fully automate the system, so you must replace the neutron reflectors and uranium cells manually. Also, walls made of cooling reactors are cool.


    If there is demand, I may put up a video going over this in greater detail, and to show you how it works. If anyone has any criticisms or proposed improvements, I would love to hear them. Thank you for reading.

    flickering is not necessary. There is no chance of hull heat being generated. trying to do so would make the reactor produce very little effective eu/t since the microcyle time is only 2 seconds. If you are using a plutonium reactor, then swapping them out every second is necessary.


    I will probably put out a thread of my own a bit later with my findings so far.