Posts by Chronophaser

Quote from raGan

Actually... there is no loss up to 40 block using glass fibre (40th block is storage device or HVT). With 512EU/p there is 1EU loss every 40 blocks which is barely 0.2% of total package. But this method is so expensive it's in my opinion not worth it. ** 10 diamonds **

I guess I should clarify where those numbers came from: the lossless indefinite glass setup would be 39 glass cable + 1 EVTF (stepping down) every 40 blocks... 39 glass cable uses 9.75 diamonds, and the EVTF uses 1... so I rounded up to 11 diamonds per 40 distance. The loss percentage was for the same 40 block distance covered by iron cable carrying EV (2048EU/p)... my calculation was wrong, in fact: with uninsulated iron, it's around 1.95% loss, with 3x insulation it's around 1.56% loss.

Quote from raGan

I think i should use EU/p instead. There is an easy way to connect 512EU/p input into copper network, MVT at the beginning would do just fine. It costs 8x refined iron bar + 2x copper cable and tadaa ! 512EU/p input copper system created.

I did not mention glass fibre earlier because i think it's simply too expensive to use in long(OK... let that be 40+) wiring. At least compared to its cost.

I wasn't saying you can only connect 128EU/p 'voltage' to a copper/LVTF line (32EU/p is what's actually transferred, anyway)... rather, I was saying that 128EU/t is the maximum throughput such a connection can transmit, due to the way the TFs work. For example, if you have 200EU/t worth of power generation hooked up to a long copper/LVTF line and place an infinite-load device (like storage or massfab) at the end, that end device will only get 128 EU/t total (in 32EU packets).

To grossly simplify:
Each tick, the LVTF's high side asks for 128 EU... the LVTF before it sends 4x 32EU packets, which that LVTF can then send to the next one in 4 32EU packets. Because this 'load' on each segment of the network is only 128 EU/t, that's the maximum EU/t (total current, not packet size) that can be sent through in this configuration.

You can get around the limit by increasing the load via multiple TFs, but with copper's 4-block lossless limit, the block placement to allow it is just impractical.

Quote from raGan

3rd factor - maximal input for both systems without additional costs (128EU/t for copper / 512EU/t for EV)
additional factor is material (as copper is better option earlygame)

An additional caveat:

Maximum EU/t throughput

Using TFs to reboost your signal works great and can be cheap, but their throughput is strictly limited by the EU/t rating of the high side.
In the case of the copper wire reboosted by LVTFs, your maximum throughput is 128EU/t, since that's the maximum an LVTF will let through.
Wire itself (ANY wire) has no throughput limit, only packet size limit. I've had 800EU/t over tin (with 1 EU/t packets), and 20,000EU/t over glass (with 512EU/t packets).

I'll definitely agree the chain of copper/LVTF is a good option early in the game for lossless transmission of up to 128 EU/t (since you always have surplus copper anyway), but if you need more throughput than that, there are other lossless options:

EV works fine if you don't mind the slight loss... but if you really want your wire to be lossless, you can get EV throughput over glass using basically the same method as above, but with EVTFs and glass fibre. Glass fibre line with EVTFs every 40 blocks allows indefinite lossless transmission of up to 2048EU/t.
It's very expensive, obviously, and most certainly wouldn't be worth it in the majority of cases... (per 40 blocks distance we're talking 11 diamonds to prevent barely 1% loss) ...but it's a nice option for the perfectionists out there.

Quote from NotCoach

New to IC2 anad the forums. So if what I am about to suggest is ridiculous because I missed something, please forgive me.

I have been reading about the multiple chamber designs using water buckets for cooling and how vital it is to maintain 5 or 6 buckets a second. Instaed of that why not 3 or four single chamber reactors each requiring only 2 buckets per second? The follwoing design produces 490EU/t. Add two more reactors and you get 1470EU/t. A foruth, 1960. The only major drawback I see is that you would need approxiamtely 50% more uranium cells to match the 1520EU/t design I saw here. Thoughts?

Reactor Design: http://www.talonfiremage.pwp.b…=1110101011201521s1r11r10

To answer your question of 'why not', well, to be blunt: efficiency.
Normally, reactor design is about balancing EU/t output, uranium efficiency, cost, and liability to explode. CASUCs 'cheat' that balance by allowing very high efficiencies that can be run continuously for very high EU/t output. While you could make multiple smaller CASUCs to equal one maximum-size CASUC, they will never be as efficient. That extra uranium needed in the smaller reactors is uranium that wouldn't have to be burned to get the same output from the big reactor.
The only reason you might want to go with smaller CASUCs is reactor cost. But, since you need at least 3 single reactors (3x2 = 6 chambers + 3x other reactor bits) to equal the one 5-chamber reactor (2+5 = 7 chambers + 1x other reactor bits), that's almost completely ruled out.

I see two possible other reasons (outside the usual reactor balance) to consider smaller CASUCs:

1) "RP2 tubes are haaard :("
...to paraphrase your main argument . Indeed, trying to push 5-6 buckets a second with so little margin for error is quite a daunting challenge. If you don't think you're up to it, or that it'll be too unstable, feel free to go for a smaller CASUC with less explosion liability. Just be aware that there's good reason to cram as much uran as possible into these things.

2) mobile power source for RP2 frames (when they arrive)
Since frames (as we've seen them so far, anyway) will only move blocks directly touching them, moving a 5-chamber reactor with frames could be somewhat difficult (but not impossible, provided Eloraam gets tubes working within frames as planned). A single chamber CASUC could be much easier to set up for such a rig. It may also be much more appropriate, as 1.5kEU/t seems a bit overkill for any activities I see a mobile platform doing.

Edit:
And welcome to the forums!
Don't worry, your suggestion isn't ridiculous.

TL;DR version:
A smaller CASUC would be much easier to engineer for, but doing so would cut down efficiency, which is fully half the reason for going CASUC in the first place. So I doubt you'll find many users to support the idea.

Hm, where to start...

First, I'm not sure what's up with your isotopes finishing at different rates in the first example. I've never observed this behavior myself, but then, I never run breeders with more than 1 uran touching each isotope... any more than that and you're loosing efficiency unless you have some sort of auto-reload mechanism, which was extremely difficult to set up before retrievers.

It sounds like you're wanting to accomplish two separate things in the same design: CASUC breeder, and auto-reload breeder. In my experimentation, I've found this to be impossible to do successfully in the current set of mods. The biggest reason for this is simply that you cannot guarantee that anything stuck into a reactor will go where you intended it to go while it's running CASUC. You need at least 1 RP2 tube between the transposers/filters and the reactor, and there's no telling until you fire it up as to how that delay and the RP2 clocks will sync with the reactor's ticks. Also keep in mind that as of 1.337 with fixed reactor inventory, you can't push items to a reactor unless there are empty slots for them.

A CASUC breeder can be done. I've done so myself, and you can make it a nice easy to use auto-start rig with some logic gates.

An auto-reload breeder can also be done, but not with CASUC. I haven't built one, but plan to, probably using a plain perfect breeder design (like this), combined with RP2 stuff to either alternate attempts to pull out spent things and reload (making sure there's enough delay to prevent risk of getting more than one uran in), or time out exactly when the uran and isotopes will run out. In either case, the reactor would have to be manually heated to 9k, and you'd want to get it started with a quarter-used uran or a quarter-cycle delay, to make sure uran and isotopes run out at different times so the reload will go to the right spot. It would likely also require intermittent manual reheating (by controlling water flow, probably) to compensate for the brief periods during reload that it's not making the same heat. This would be fairly infrequent however.

I've run a bunch more cycles with the auto-startup breeder, and found that the temp CAN vary slightly... it is either at 9270 with buckets disappearing almost immediately, or at 9520 with buckets sitting in it a second before going. So the syncing isn't exact... but for the purposes of this breeder it seems to be fine. There's a reasonable safety margin (auto-shutoff kicks in at 11k, reactor doesn't melt till 13.5k), so this variance only concerns me if it allows the temp to drop below 9k.

It might be an issue for an automatic-reload breeder like what you're discussing, but for the one I'm running, this desync is NOT an issue. So long as the redstone timer ticks stay within 1-2 seconds of the reactor ticks during a breeding cycle (~5000 ticks), there's no problem.

Also, out of curiosity... how exactly do you plan to swap out things the exact tick it is depleted? As of 1.337 the reactor inventory has been 'fixed', so RP2 tubes will NOT recognize a full reactor as a valid destination. You need at least one tube to the reactor, so the reactor slot must be open for at least that travel duration.

I've finished adjusting my own version of a CASUC auto-start perfect breeder on MJEvan's server (IC2+RP2 1.8.1):

http://www.talonfiremage.pwp.b…h=1a161010111010101001019

PICS:

It looks a bit ugly, but I was kinda just working around where the reactor was already placed (Yay for RP2 bundled cables).

It features an automatic emergency shutdown system (which has already prevented one explosion when the wire to the water injector got broken accidentally). After the shutoff trips (either from a problem or the end of a cycle), pistons open to increase the external cooling, so the reactor can cool down on its own between cycles, despite the 20 isotopes still giving off heat.

The redstone stuff does require that the reactor be at 'zero' heat when it's started, but since there are no heatsinks inside, it'll usually be completely cool again just from the time it takes to swap out cells between cycles.

The nifty part (at least I think so ) is that all the redstone controls have been condensed into just 2 manual inputs: the on/off switch, and a reset button (which only works while the reactor is off). When you push the reset button, it resets the RS latch to stop the clocks (which feed the shutoff and startup counters), resets the startup counter, and resets the shutoff counter via a 0.2s clock and another RS latch. Then, when you switch the reactor on, the clocks start, the counters start ticking, and the CASUC system waits 36 seconds to start injecting buckets, leaving the reactor running stable at 9520 (higher temp allows some wiggle room for when isotopes finish somewhat unevenly).

This is all contained within a single chunk, with plenty of room to spare. It could be made prettier, but it works beautifully as an easy-to-use, set-and-forget, maximum-efficiency breeder.

Quote from Red Lynx

But, ICE semms to work in a misteriause ways it should melt over 300 heat ... 3 k heat ice melts continiausly until reactor is cold 20 heat only... and consumes about 8 or 10 ICE block when it's in this state, Thermometer dosn't seems to be at foult. But where to post a bug when you can only see it with a mod addon

Fairly sure that's not a bug. Ice melts above 300 heat and reduces heat by 300 when it does so. But that cooling only applies to hull heat, so if you have other components with heat it can take time for that heat to transfer to the hull where the ice will melt. And the ice melting factor in the heat is done in the same reactor tick that transfers heat, so while the reactor may put 320 heat to the hull, an ice will melt and reduce it to 20 before the reactor 'tick' ends, so you read 20 with the thermometer.
Bottom line: as long as there's still ice in the reactor, you shouldn't see hull heat go above 300, even if ice is melting.