Version 1.337 is out!, watch out for them reactor changes ;)

Quote from Cadde

No, you said he isn't incorrect. How can someone not be correct if they aren't wrong? (Untwist that...)

Because you're the sort of individual who cannot possibly comprehend that there can be more than one correct answer, or that any way of interpreting something other than your own is wrong.
See, until 1.337, that interpretation yielded the same mathematical result - and, so I'll ask you: If the answer is the same as the only right answer you'll accept, how can it be wrong?

Don't try to play logic games with me.

Sure, whatever floats your minecraft boat.

In my view we have (and have always had) two competing standards here:
1. Pulse Standard: Efficiency is the average number of pulses the uranium gives off per reactor tick.
2. Energy Standard: Efficiency is the average number of millions of EU given off by the uranium per reactor cycle.

Prior to the 1337 patch, which standard you used was purely semantic. They both yielded the same efficiencies in the same situations. Now that reactor output is doubled, standard #2 gives 2x the efficiency as standard #1.
Both are intuitive in their own way. We simply have to pick one to use.

Personally, I prefer the pulse standard, as it results in the same efficiencies as before the patch and involves the direct workings of how reactors operate.

Still have to wait till IC2 supports 1.0.0. I seen redpower and buildcraft already supporting it so this is the last mod iam waiting for

Yes, IC2 for 1.0 will be some nuclear engineering excitement for me. I have been waiting for RP and IC to match up since Eloraam tweeted about the Retriever and the Sorter. I have a design I have built and tested in my 1.0 world that should keep my CASUC idea fueled with either Ice or Buckets to any degree that I can produce them.

Using a circular system of pipes with a Sorter and Retriever hooked up back to back allows you to route empty/full buckets all over the place, with only one tube to the reactor/refillers.

Actually, using the Sorter and Retriever in conjunction, somewhere midway in your tube system, and properly painting your pipes allows you to replace exceedingly complex systems with very simple mid-network loops. In my case, I have (with chests to stand in for the applicable IC machines) reduced my ore management center to a very simple one-track design, which can handle ANY amount of different ores but still output them all to sorted boxes. Indeed, I can then pull refined tin/copper bars BACK into the system, where they get re-macerated for the production of Bronze, without all the mucking-about with ratios that was previously required.

With the recent addition of the EU Detector wires, I plan on setting up a fully automated system to replace the Uranium Cells in my reactors once the cycle has completed. I'm hoping for a down-time of only a second or two. However, this will require that my SUC slots be filled and that SUC flow TO the reactor stop entirely before I swap out the U-Cells. I'm still working on that...

Can anyone give me an idea of how many concurrent requests I would need to make for 9 buckets (per request) to keep one of these 1k+ EU/t CASUCs cool? As it stands now, I can stuff 9 buckets per 0.2 seconds into the reactor. Double that for each Retriever/Sorter I place in the system.

So, I guess the big questions are:
1) Ice or water: Water is easier to set up, requiring only pumps and pre-made buckets. Ice works better but requires pump+compressor+compressor. Which costs the least in startup resources?
2) How many IC2 machines are needed for each setup at the maximum needed speed?
3) What's the best ratio of U-Cells to Coolant for each setup? (In a 5 core reactor w/ external cooling)

Quote from Corbald

Can anyone give me an idea of how many concurrent requests I would need to make for 9 buckets (per request) to keep one of these 1k+ EU/t CASUCs cool? As it stands now, I can stuff 9 buckets per 0.2 seconds into the reactor. Double that for each Retriever/Sorter I place in the system.

So, I guess the big questions are:
1) Ice or water: Water is easier to set up, requiring only pumps and pre-made buckets. Ice works better but requires pump+compressor+compressor. Which costs the least in startup resources?
2) How many IC2 machines are needed for each setup at the maximum needed speed?
3) What's the best ratio of U-Cells to Coolant for each setup? (In a 5 core reactor w/ external cooling)

Worse case scenario, 8 buckets/second. The hottest possible design needs 7 buckets of cooling, the 8th bucket is to catch up if you get a little behind. Only tricky bit is pipe lag : within the space of 1 second you need to retrieve all 8 empty buckets AND insert all 8 full buckets before the second is up. It takes time for stuff to flow in the pipes, so the 8 buckets needed need to be in close proximity to the reactor destination inside the tube loop and you might need to desynchronize your retrievers. That is, if you activate all 8 retrievers on the same tick, will the first one grab the first bucket and then all the other ones try to grab that bucket and fail? If not, then that part will work nicely, you just need to stay ahead of pipe lag. Not sure what the sorting machines will do for you that the retrievers don't already do.

The design I am thinking of is 8 retrievers that activate every 0.8 seconds and 8 filters that pull from 8 transposers every 0.8 seconds as well. Possibly with repeaters to offset their activations by 1 tick.

For Ice vs water :
Ice : Advantage is SAFETY. You can keep several full stacks of 64 ice in the reactor, consuming at most 6 ice per second (so 30 seconds of cooling). You can have the excess ice flow past an item detector ever so often..if you don't have excess that means the reactor is burning through ice faster than you are making it and you can just trigger an automatic shutdown right then. You can have 2 or 3 minutes of cooling reserve, giving your auto-shutdown system time to work.
Disadvantages
1. It lowers the efficiency of the reactor significantly since about 20% of it's output has to go to running ice makers
2. It requires a LOT, a ridiculous number of pumps and compressors. Like 90.
3. It makes breeding half as effective, and breeding fuel is huge if you are playing legit

Water is more dangerous, more efficient, and twice as fast at breeding.

According to the wiki:

Pump + Compressor + Compressor = 200 eU / 10 seconds + 625 eU / ~15.625 seconds + 625 eU / ~15.625 seconds

Thus cooling for 300 costs 1450 eU and close to 42 seconds.

Each pulse a uranium cell produces (at maximum eff) is 10 heat and 10 eU, therefore in order to come out ahead cooling wise ice must cost less than 300eU to produce. It does not.

Buckets however cost 0eU to produce (costing only redstone action and some unknown volume of RP2 power to suck out through one pipe, OR redstone action only to filter out), and still cool for 250. However it seems that buckets cool one at a time, in series; perhaps a limit of 10-20 placed buckets/sec? That would still yield over 2500 cooling though.

The Retriever has a 3x3 grid. I'm going to have to check to see if it can try to pull 9 buckets simultaneously. However, I am working under the assumption that it does NOT and was going to set up a similar system to the one suggested above, with multiple Retrievers on slightly offset ticks to pull empty buckets. According to my testing, I do NOT believe that Transposers/Filters will be needed AT ALL for this system. Retrievers fill the role of moving things OUT of the various machines and Sorters fill the role of moving things INTO them. So long as every item moving through the system passes through the Retriever THEN the Sorter, without any other possible routes in between those two machines, it should work just fine. Even if the tubes from the Sorter output and the Retriever input are the same network.

Where = tube, = retriever and = sorter.

Specific items will be routed through the network from their applicable storages (hoping this works with the reactor too, or the entire system fails) by the Retriever, passed through the Sorter, where they receive their color coding, then pass through to the proper sub-network.

Different sub-networks will be color coded, so (for example) empty buckets will only pass through into the filling sub-net, full buckets to the reactor's sub-net, etc....

Just so you know, you don't have to wait for (or use) retrievers to make a 8 bucket cooled full cell reactor.
See my explanation video i made for Quartz in another thread: http://www.youtube.com/watch?v=9SQCc3N71FM

That is a fully operational 1740 EU/t bucket cooled reactor. There are MANY ways you can design it but it does rely on Power Crystals power converter mod for BC 2.2.5 and IC² 1.23 (which works just fine for IC² 1.337 OFC) using those power links which will act on wooden transport pipes once per tick. (No other power conversion mod i know of allows that rate of bucket extraction using BC's pipes)
So in short, without RP2's retrievers the only way i know how is to use those energy links from that conversion mod but it does work just fine and now it's just a matter of making the design less CPU intensive. It is just a proof of concept in it's current state...

Sorry bout the horrible English, I am not that good at speaking it.

Quote from Cadde

Just so you know, you don't have to wait for (or use) retrievers to make a 8 bucket cooled full cell reactor.
See my explanation video i made for Quartz in another thread: http://www.youtube.com/watch?v=9SQCc3N71FM

That is a fully operational 1740 EU/t bucket cooled reactor. There are MANY ways you can design it but it does rely on Power Crystals power converter mod for BC 2.2.5 and IC² 1.23 (which works just fine for IC² 1.337 OFC) using those power links which will act on wooden transport pipes once per tick. (No other power conversion mod i know of allows that rate of bucket extraction using BC's pipes)
So in short, without RP2's retrievers the only way i know how is to use those energy links from that conversion mod but it does work just fine and now it's just a matter of making the design less CPU intensive. It is just a proof of concept in it's current state...

Sorry bout the horrible English, I am not that good at speaking it.

Yeah, I forgot about this. Those energy links are incredibly strong engines when acting on wooden pipes. Looking at your video, it was hard to tell why your wooden pipes don't pull out fuel rods from the reactor.

Quote from Corbald

According to my testing, I do NOT believe that Transposers/Filters will be needed AT ALL for this system. Retrievers fill the role of moving things OUT of the various machines and Sorters fill the role of moving things INTO them.

Perhaps not, I just don't see what the sorters are for. Hmm..you could use them to make sure that the buckets are distributed evenly between the deployers.

The rough design I had in mind was real simple : you have 8 retrievers, and 8 filters on 8 deployers. Once per second, you yank all 8 empty buckets from the reactor and you yank all 8 full buckets from the deployers. You route your piping so that there is another destination besides the reactor available to the buckets coming from the deployers : perhaps a route back to the deployers that passes through a transposer one way valve. This "packet" of 8 buckets close to each other in the pipe you combine into one tube by using inline transposers (since they transport an item through instantly)

I wanted a design that minimzes unnecessary buckets in the tubes, because those increase CPU and GPU load unnecessarily (I play in SMP). I want there to be only as many buckets traveling as the reactor actually needs, with a small cooling surplus since the system won't be synchronized with the reactor so it might sometimes fall 1 second behind. The reason to use 8 filters on a 1 second timer rather than 4 on a 0.4 second timer is to make one unified "packet" in the pipe to make sure all 8 buckets are replaced before 1 second is over. You might have to have sent a couple of packets already to avoid getting behind. One other key note : I've read the reactor source code. Only once per second does the reactor update and iterate through the contents of the reactor. Any buckets it finds will be consumed all in the same tick. This is why we only need to activate things once per second, anything more is just spam.

Quote from MJEvans

According to the wiki:

Pump + Compressor + Compressor = 200 eU / 10 seconds + 625 eU / ~15.625 seconds + 625 eU / ~15.625 seconds

Thus cooling for 300 costs 1450 eU and close to 42 seconds.

Each pulse a uranium cell produces (at maximum eff) is 10 heat and 10 eU, therefore in order to come out ahead cooling wise ice must cost less than 300eU to produce. It does not.

Buckets however cost 0eU to produce (costing only redstone action and some unknown volume of RP2 power to suck out through one pipe, OR redstone action only to filter out), and still cool for 250. However it seems that buckets cool one at a time, in series; perhaps a limit of 10-20 placed buckets/sec? That would still yield over 2500 cooling though.

Display More

Evans : thanks for pointing this out. I didn't bother to actually compute the energy requirements, I just relied on another player's post on this. Apparently, unless you are using EE to get the ice or maybe snowmen and block breakers (when the 1.0 update comes) it's a no go.

The way reactors work, once per second the reactor code checks every single slot in the reactor. If it finds an invalid item, it ejects it. If it finds a bucket of water, it subtracts 250 heat from the reactor and empties the bucket if heat is over 3000. If it finds a uranium cell, it checks to see how many other uranium cells are adjacent by checking each of the 4 adjacent squares and adds a certain amount of EU to the reactor's production rate and a certain amount of heat to itself. And so on for each square.

So if you want to remove 250 heat/second, you must sacrifice a slot to a bucket. The rate that you insert buckets with transposers and filters does not matter so long as you replace all buckets within 1 second.

Quote from BrickedKeyboard

... Looking at your video, it was hard to tell why your wooden pipes don't pull out fuel rods from the reactor.

Additional Pipes using advanced wooden pipe (selective extraction based on item you have in the wooden pipe) and the video was made as a response to a specific thread where everything is detailed.

Link: http://forum.industrial-craft.…ad&threadID=2954&pageNo=2
That page on basically. Discussion between me and Quartz which lead to me discovering the power of the energy link... A bit OP but it works where all others fail (Redstone / other engines from other conversion mods etc) due to being blown up by the energy output of the reactor or simply not fast and reliant enough to make a 8 BPS CASUC. (BPS = Buckets per second, trying to introduce new terms)

That design can easily be throttled so that it only really operates once per second though. The energy links stop spamming buckets if redstone power is applied to them.
And about the OP-ness of the energy links, it is still possible to change the conversion rates via config if one thinks they are too cheap.
The real problem i have with them though is they are TOO fast for something so simple and i would much rather have like electric engines with high RPM (>120 so they can cycle more than twice per second obviously) that doesn't accept power from the reactor chambers they inevitably have to be up against if you are going to be using 4 of them.

EDIT: Or if the reactor chambers are part of the inventory of the reactor core. Allowing you to extract and insert items at the outer chambers would also solve a lot of issues. And i would switch back to electric engines from that other BC->IC conversion mod.

RedPower's retrievers will be equally great at pumping buckets and they will be free in terms of energy consumption and then we might as well use TMI to make lapo crystals... IMHO. There should be some losses in the cooling system so that you want to design an as efficient and stable coolant system as possible while making sure it doesn't become too power hungry.

On a side note, the very moment the FiniteLiquids mod becomes Forge compatible (said to happen in V6) i will install that. Imagine having to collect coolant for your reactors from the ocean and relying on downpour for said ocean to refill with water.
Imagine building your reactor in the middle of a large tundra, pumping water from afar isn't an option due to distance. So you have to make a collection pool for rain and pray that the water collected is enough to cool your reactor.
Like i said, i would be on top of that in an instant for the challenge!

Having read the redpower blog earlier today; Retrievers cost bluetricity. I don't know how much, but they do.

Quote from MJEvans

Having read the redpower blog earlier today; Retrievers cost bluetricity. I don't know how much, but they do.

Bluetricity is still (IMHO) free power. You just have to use those solar panels which are after all, nothing more than a more expensive recipe for the retrievers.
Can't understand how anyone would want to have solar power as it is zero challenge in constructing and using them. Solar power in the real world makes sense because we want to avoid extra tedious work but to me, in Minecraft, it's the other way around. I want to make renewable energy from some kind of production facility. Like growing trees and using machines to cut them down. Making efficient designs to increase net energy gain after the process is completed.

Not just simply crafting a block and placing it and never having to touch it ever again. Too easy.

/rant

After more thorough testing, I was able to remove the Sorter. As mentioned above, it was, in fact, not needed. Turns out that I missed the tiny destination-color select button on the Retrievers. Now using to opposing Retrievers to move empty/full buckets up/down the line.

I switched over to using a Deployer on a rapid pulse to simulate the Reactor. It simply empties my buckets and they are then pulled back into the network.

I am, however, having some serious backstuffing issues, whenever any part of the system is shut down and can no longer accept buckets of either variety. This jams the entire system, forcing manual intervention to clear out the stuffed RP machines....

I'm also having issues with the initial startup. If I turn on the flow AND the 'Reactor' simultaneously, it seems to work fine, but there's a large delay in getting those first filled buckets to it. I'm afraid it would melt down in that time. With the bucket flow ON but the Reactor OFF, I get the above backstuffing issue....

I'm working on solutions and will keep you all updated.

As to the suggestion to use BC and applicable mods. I'm trying to get this all up and running with RP tubes and machines exclusively, as I believe they will be the better solution in the long run, and because I can't abide by BC's tendency to 'spill.' (Yes, I DO know I can use an obsidian pipe to suck up the spillage.) Call me silly, but it's just my goal to use the RP machines. I feel that RP tubes give us more in the way of control over the system.

Quote from MJEvans

According to the wiki:

Pump + Compressor + Compressor = 200 eU / 10 seconds + 625 eU / ~15.625 seconds + 625 eU / ~15.625 seconds

Thus cooling for 300 costs 1450 eU and close to 42 seconds.

Each pulse a uranium cell produces (at maximum eff) is 10 heat and 10 eU, therefore in order to come out ahead cooling wise ice must cost less than 300eU to produce. It does not.

Buckets however cost 0eU to produce (costing only redstone action and some unknown volume of RP2 power to suck out through one pipe, OR redstone action only to filter out), and still cool for 250. However it seems that buckets cool one at a time, in series; perhaps a limit of 10-20 placed buckets/sec? That would still yield over 2500 cooling though.

Display More

Pretty sure you've got some serious scaling issues here. According to ICW, each pulse a uranium cell produces up to 10 heat (depending on surroundings) and 200 EU, not 10.

Quote from Hawk777

Pretty sure you've got some serious scaling issues here. According to ICW, each pulse a uranium cell produces up to 10 heat (depending on surroundings) and 200 EU, not 10.

Good catch, I think you might be correct. It seems during my brief break at work I had a meters/feet conversion type issue. Heat is in seconds, power is quoted in eU/t (of which there are, IIRC, 20 per second).

Doing the numbers again, 300 heat is 30 pulses. 30*200 = 6000 . Ice cooling would then consume roughly 25% of your reactor's output power.

Still, with a number like 25% that equates to a 25% loss in eff; if you've gone to a CASUC do you //really// want to spend all of that extra iron and infrastructure to get a measly 3.285 Eff? (4.38 * 0.75 if you use 5 chambers filled with uranium except for a column of 6 ice) Or would 4.35 with buckets be better?
http://www.talonfiremage.pwp.b…=1k10101011811i21s1o11r13

Edit:
Also, if you're shopping for ~3-3.5 eff there are designs in the best of the best http://forum.industrial-craft.…page=Thread&threadID=2963 which run at 3.0 full cycle and at 3.6 if you multiply the build by 10 and switch between them. I recall a design that I submitted a revision on that had 4 cycling as well; with the /vast/ array of ice producing machines (which probably wouldn't even fit in the chunk!) and gigantic energy grid required to service them you could /surely/ afford to build more reactors instead.

I know it's kinda silly to point this out... But setting up in an icy biome DOES reduce your power consumption for a CASUC design significantly... Block breakers would reduce the number of pump/compressor/compressor combos you would need by a fair margin! Not sure what the optimal number would be.. Something like 32-64 to mine self-renewing ice. Probably 64 if the breakers are pointing up, to allow for the alternating coverstones to protect the water source blocks, yet still expose the mineable area to the sky.

Still, it's a limited use scenario.

While I agree that's possible, and could even use tree-farm tactics and well placed sources of heat to ensure only the correct water freezes... there is absolutely no way you're getting much ice from a single chunk.