1520 EU/t MkV CASUC [MC1.0] [IC 1.43] [RPpre4]

Well i know filters and transposers can run at 0.4 sec but i do not know if that applies to retrievers.

This should be possible maybe with 2 retrievers if 1 isnt fast enough.
http://www.talonfiremage.pwp.b…=1l10101001501521s1r11r10

Quote from ccrraazzyyman

I currently have 4 retrievers, and the one above (5 buckets/second) is the best I can get right now. If I didn't need sleep I would figure out of they ran @ .4.

Also, the reactor is stable with what I've built so far.

Cycle finished... and minecraft crashed. Not sure why.

Whatever happened it ruined this world.

Display More

see the bugs section, it's a known bug, not any problems with the design.
Epic reactor though, rather too crazy for me though. (a MK-2 is about my limit)

The crash was a bug with reactors finishing a cycle, it has been fixed in 1.43

The new retrievers are definitely nice and are very good at extracting the empty buckets.
I also made a CASUC reactor today using retrievers.
By the way, thanks for reminding me that you can use the retrievers for CASUC reactors.

http://www.talonfiremage.pwp.b…=101l101011a01521s1r11r10

I was able to go 70 EU/t higher, but it was very easy to build once I realized the insertion retrievers need to be as close as possible to the reactor itself.
The problem with this setup (and maybe your's as well) is that once the reactor gets fully filled, the insertion retrievers stop sending buckets for just long enough to make the reactor overheat.
This for me makes this setup a little bit scary to use, so I found a solution in the form of Buildcraft and Additional Pipes.
As far as CASUC reactors go, Buildcraft and Redpower work perfectly together for me, sometimes I even replace deployers with bucket fillers because of the lower CPU load and higher SMP reliability (as in, it never drains an infinite waterpool).
The reactor has only 10 EU/t less then your's but it feels 100% safer then when using Redpower to insert the water buckets into the reactor.
http://www.talonfiremage.pwp.b…=101m101011a01521s1r11r10

The insertion is done with an advanced insertion pipe, a gold pipe (to speed up the buffer filling rate) and an iron pipe in a circle to make it a buffer which can hold (in theory) an infinite number of buckets as a buffer.
The nice think about this is that it instantly fills all the empty slots in the reactor with water buckets.
In combination with 7 retrievers pulsing at 0.5 seconds with a timer and 4 deployers on the same timer.
It will (at least when i'm testing and looking at it) take less than 1/10th of a second to get all the used water buckets out and fill the empty slots with new water buckets.
So in my opinion it is just as safe as a mark 1 reactor with a heat balance of minus 20.
When Bucket Filler comes out for Bukkit I will probably make a low CPU usage version of this 1510 EU/t reactor.
Then the only Redpower machine I will use is going to be the 7 retrievers for pulling out the empty buckets.
The rest is going to be Buildcraft, which for me always has been way less CPU intensive and way more SMP usable.
I can never figure out that a HD6870 Crossfire, 4 Ghz quadcore QX9650 machine can run Crysis 2 without breaking a sweat but not being able to run minecraft singleplayer with a good CASUC reactor in it without any stuttering.
And on SMP (where the server runs on a dedicated 6-core 8GB MineOS Ramdisk machine) it also doesn't seem to run without stuttering when I'm in the same area as the CASUC reactor.
Well, as long as I can play minecraft, build and discuss CASUC reactors with other people I'm going to be a happy man.

eloraam has to put 'dumb' pipes in her mod that should fix the problem.

Quote from SSD

I can never figure out that a HD6870 Crossfire, 4 Ghz quadcore QX9650 machine can run Crysis 2 without breaking a sweat but not being able to run minecraft singleplayer with a good CASUC reactor in it without any stuttering.

One word; Java.

Quote from _Tim_

One word; Java.

One more word: SingleThreaded.

A lot of time is spent rendering and then all of a sudden EVERYTHING is updated at the same time in a single thread or at least using sync locked threads.
Java however enabled Notch to focus more time of adding stuff and less time on coding to make code to add code to add stuff.

From what i know optifine has some multicore support. But i think its only to load chunks.

Quote from Rick

From what i know optifine has some multicore support. But i think its only to load chunks.

Correct.

Is it possible to make it completely multithreaded? I mean chunk loading is already multithreaded in optifine or is that just impossible no matter what 'smart' programing you use in java?

Quote from Rick

Is it possible to make it completely multithreaded? I mean chunk loading is already multithreaded in optifine or is that just impossible no matter what 'smart' programing you use in java?

The game is running in a single threaded update loop.

For instance:

while (gameIsRunning)
{
	HandleEvents();
	UpdateWorld();
	UpdateEntities();
	Render();
}

Each of those calls in turn makes other calls.

HandleEvents() handles user input and updates the players movement stats etc. Optifine can move this over to a separate thread and thus you don't get stuck keys etc.
Pressing the forwards key sets a movement vector to lookVector*1. (simplified)
Pressing the backwards key sets a movement vector to 0-lookVector*1. (yet again, simplified)
The reason this can be in a separate thread is because it is altering separate variables that are then handled in UpdateEntities()

UpdateWorld() deals with block adding/removing and setting the lighting etc. Water flow and lava flow and the day/night cycle etc etc. Loading and generation of new chunks too.
Most of this can also be put in a separate thread but not all of it. Breaking a block has to be handled in the same thread as the player entity.

UpdateEntities() handles ALL entities (players, mobs, animals, machines etc etc) and have to be in the same thread as UpdateWorld() or really wonky stuff would happen.

Render() handles screen drawing only. It however also "needs" to be in the same thread as the above two. Otherwise it would render with lots of artifacts.
Optifine has a MultiThreaded render process as well but it causes render artifacts. Especially noticeable when lots of entities are updated in a single tick and the Render thread and Update thread comes out of sync with eachother.
As well as chunk updates etc.
Optifine CAN get it to work but the amount of coding involved and the number of places things can go haywire is immense and numerous.

EDIT:

Forgot to mention that some of the above calls are only executed "on demand" (like input handling, only if there is input then code is executed) and on every X ticks.
For instance, mobs get new pathing targets every X ticks. This pathing is VERY expensive on the CPU. So every X ticks you get a kind of freeze lag as the animals are all updated in the same tick.

In short, Notch and the Mojang team could have done EVERYTHING in Minecraft a LOT better but they aren't really "professionals", they get the job done but they rarely make great code.
Had Minecraft been coded in C++ or likewise then they would have to follow MUCH stricter coding standards (and we would have A LOT more crashes and a much harder time finding the cause for the crashes) and mods would be nearly impossible to make for the average amateur. One thing for sure is we wouldn't have IC2 if Minecraft was C++ or likewise.
We would probably have to do without a LOT of the mods we have today if MC was written in another language.

I am not saying it would be impossible, just saying the threshold to get into modding would be THAT much bigger.
GTA 4 has a large modding community however and GTA 4 is C++. But it's very different with such big titles, everything is VERY organized and structured. It is easier to reverse engineer such projects.