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

    I'm keeping the older versions in spoiler tags in case anyone wants to look at it.


    New Model! All of the same features (including crater! :( ) but a fraction of the size! Only uses 1 clock for the entire system and now fits inside an entire chunk easily, so there should be no chunk load issues at all!


    Display Spoiler



    I've updated the reactor. Got it working @ 1520 eu/tick using 6 buckets a second. Please note the only mods used in the construction of this reactor (other than TMI :D) were IC 1.43 and RP2pre4 (Just realized this statement is false. I'm using EE Alchemy chests to store buckets, and I'm pretty sure a large bucket holder like this is required. I might be able to use a double chest?) . I could've used other mods but I'm trying to see how powerful I can get with just these two mods.


    http://www.talonfiremage.pwp.blueyonder.co.uk/reactorplanner.html?8k5cbamoekhefy8800nymsz6r0dus=161d101011601521s1r11r10


    Things to note about this reactor is that since the updated fix with reactors and their inventories (i.e. wont let me make an overflow of buckets) I think this is going to be near the upper limit of what we can accomplish with just RP2 and IC2.


    Other design notes. All the sequencers are set @ 0.500 seconds. It was a pain to design the retrievers so that they would split the buckets evenly. I'm using painted tubes on each of the deployer ends to make sure there is an even split, as each retriever is linked to a deployer. This reactor requires 6 units of water under it to maintain its temp. Any more or less causes it to fill with water buckets (stopping the flow of water into the machine) and will promptly cause a meltdown. (this IS v2 of this reactor for a reason >.>)


    Here are pics of it.

    Display Spoiler


    Past design ideas.

    Display Spoiler

    This information was for the old 1270 eu/t reactor


    Display Spoiler


    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)

    Don't delete the world, I'm going to be working on hotfix tonight, don't have an eta on release, but it should be before too long.

    Lesson 1: Watch over your crops....

    Display Spoiler
    alexthesax wrote:

    Don't delete the world, I'm going to be working on hotfix tonight, don't have an eta on release, but it should be before too long.

    I still have it. I figured that once whatever bug was fixed my world would work just fine.

    I have updated to 1.43 and it saved my world.


    I made two new reactors (one is a crater right now) and the other is the one now featured in the main post.

    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.

    SSD wrote:

    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.

    _Tim_ wrote:


    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.

    Rick wrote:

    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:


    Code
    1. while (gameIsRunning)
    2. {
    3. HandleEvents();
    4. UpdateWorld();
    5. UpdateEntities();
    6. Render();
    7. }


    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.

    I don't use retrievers for insertion, I use filters attached to a chest. The filters will only find the reactor as a valid inventory and put every bucket into them. You mentioned the reactor filling up and stopping flow, which is true. I find my system 100% stable once started because of the exact 6 buckets a second I get (6 filters each cycling @ 1 second) and the precise 1500 extra heat. This completely counteracts the reactor filling up and doing the stutter cooling (which caused a crater on my test world). My entire setup uses 4 sequencers, which I could condense down to 1 as all the sequencers run off a 0.500 second interval. I really wish these pipes let me 'overstuff' like buildcraft pipes so that I could make a 1720 eu/t reactor (see the link to youtube where I took the deployer idea, his reactor is amazing and completely do-able with 'dumber' RP2 pipes)

    Updated the main post with a newer model of the reactor. Now fits inside one chunk easily for smp loading purposes, uses 1 sequencer, 6 retrievers (3 in, 3 out, works like a dream once I got the out situated properly), and 3 deployer/filter combos. This reactor was a lot more picky when starting up, but should be able to withstand any loading problems that can be thrown at it, as it is completely loaded in one chunk and is only approx 8 layers tall (from bottom wire to top of pipes).


    Please, let me know what you guys think, I'll be putting this through loading stressers to check to see if it explodes.


    EDIT: Haha, stupid thing blew up on the first logoff and logon attempt. I guess it filled up and did the fluctuate filling of buckets and exploded. I'm not really surprised, back to the drawing board.