Automated breeder/CASUC breeder info thread

    Well, a long time ago I was talking about an automated breeder, and was mostly done with one before alblaka had even finished the whole invalid reactor slots thing.


    Now that retrievers are here, I had started working on one in 1.8.1 again (today was my first day back working on it in a long time), and wanted to test something.


    Earlier, I had found in the test.vendaria.net app (the only one that lets you step through it afaik) that the breeding cells all went at different rates of each other, regardless of the number of uranium cells they are touching or the heat of the hull, and I found that the lower the heat of the hull, the more differing the rates were for all of them, although I found that no matter how high the heat of the hull was that they all go at different rates. I believe this is a bug (maybe somehow related to how dispensers didn't shoot things with even probability for a while?), but at first I thought that maybe it was just something wrong with the app, as that isn't the best test app in the first place. However, I just tested it (right as alblaka made his update post) in MC 1.8.1 using this inside set-up: http://test.vendaria.net/index…XXUIPIPUIUIPPXXXXXXXXXXXX
    with no air blocks around it, and 4 fire blocks so it could have exactly 250 heat, and I could feed it exactly 1 bucket per second. I wasn't going to complicate things just for a test.


    And the results were: all of them save the top 2 went in different orders. (excluding the bottom two which only touch 1 uranium and are only there for heat) it started with the bottom left, then the bottom right, then the middle left, and finally the upper 2. This poses a serious problem to automated breeders, and may be a problem with breeders in general. I doubt I'm the first to notice this though, and am looking for people with more experience with the bug. If I am the first to find it, I will probably report it as I learn more about it. It is still of course possible to have a fully automated breeder, but a bit more difficult, especially if the result is that some are left at the end of the cycle which are just barely not done breeding.


    Why am I working on an automated breeder you ask? because now that IC2 is on 1.0 and there are retrievers in RP which many many people who play IC use, there will be a ton of reactors which look like this: http://test.vendaria.net/index…UXUUUUUXUUUUUUUUUUUXXXXXX
    and this (more efficiency): http://test.vendaria.net/index…UXUUUUUXUUUUUXUUUUUXXXXXX


    those will be a piece of cake to build tbh. btw, to those building them, a word of advice: when using retrievers, I have already tested and found them to have one problem/mirable: once an item is pulled, it still follows normal tube distribution as long as it goes to one of the retrievers which is valid, and if many at different distances fire at the same time, all items will go into the closest retriever, but the retriever's buffer empties instantly as though it were a transposer sucking said items from the air. This means that all but one of the retrievers don't even need somewhere on the back end to put the items, because they will never go to those retrievers unless they are equidistant, allowing them to be remote and the design to be greatly simplified and compact.


    Also, I found that one (blutricity) solar panel and batbox can power roughly 32 retrievers day and night constantly, but only if there is no weather. plan accordingly.


    Finally, if you are to build one, you must know that the entire design needs to fit in one chunk. otherwise, if you walk away and only some of the chunks it is residing in are unloaded, there will be issues.


    Anyways, the point is that those will be pretty easy to make (much moreso than the old CASUC reactors), and will provide an astounding 1740 to 1770 EU/t, but will take a LOT of uranium to power them for any length of time. Therefore, a good breeder may become necessary to keep what I believe will be a common design running constantly, or anywhere near constantly.


    If anyone already has a breeder design, I'd love to see it, but for now I don't need so much a design, (as I already have a pretty good one that i made without the reactor itself yet that should be able to handle this: http://test.vendaria.net/index…PPIUIUIIUIUIIPIPIIIXXXXXX )


    Moreso, I need information about this breeder glitch for the moment. I still plan on finishing above, already mostly made breeder, but the uranium management system will need to be different depending on your answers here and my testing.

    I plan on never letting the reactor heat up or cool down while it isn't running, and just having it maintain the same heat the whole time. That way I never have to supply more lava buckets. I also plan on using pistons to control the air blocks around it so it can either slowly heat or slowly cool as necessary. Otherwise, I plan on having 3 lava blocks, 4 fire blocks (on netherack), and otherwise only solid blocks surrounding the reactor. I do not plan on using the fact that transposers and the like can fire about 2.5 times per second, because I plan on syncing the machine to the reactor so I can replace the uranium at very specific times. It should just make life easier to have 3 transposers emptying buffer chests at 1 time per second, with the 3rd transposer being controlled by a flip flop (well, actually I used a self-resetting counter so I can avoid making a pulse former on the end of the t-flip flop). Anyways, their output will be put in the air in front of one final transposer, in order to suck them up all at the same time.


    I also plan on just having 3 retrievers run as long as the reactor is on, or even constantly, as they only appear to use up power when they actually pull something, not just from dry firing.


    The main problem is the uranium management. Before I found out about the fact that they don't finish at the same time despite having the same number of uranium contacting them and (obviously) the same hull heat, I had been planning on changing them at fixed intervals as they finished, but now it appears I will need to make an attempt constantly, every reactor tick. This may be a bit more difficult, and makes it particularly hard to calculate the actual output of the breeder, as there will be many partials when the uranium is changed.


    Which brings me to the other issue I have with them finishing at varying times. Initially, I had planned on having the finished isotopes stay in on the final tick of the uranium, so I could extract the decayed uranium and insert new ones, using the isotopes as placeholders. Now, that may be impossible, we'll see.

    The site you are using for your reactor calculations is outdated. Just be aware of that, three things have changed since that was last updated (AFAIK) and that is Buckets now cool 250, not 500. Ice now cools 400, not 200 and the reactor outputs 2x the energy.

    Quote from Cadde

    The site you are using for your reactor calculations is outdated. Just be aware of that, three things have changed since that was last updated (AFAIK) and that is Buckets now cool 250, not 500. Ice now cools 400, not 200 and the reactor outputs 2x the energy.

    I knew all that, I only used that because its the only app i can use from my ipad. I mainly use it just for visualization. I have very, very limited computer access, so most of my posts are done from my ipad, and very little of my work is actually done in MC, but is planning.


    But ya, I knew all that, all this still applies. Look at my post and you can see I plan on using 2.5 buckets per second for a 625 heat reactor.


    There is one thing though, I was pretty sure that ice cooled 300, not 400 now. Not sure though. But ya, the only reason I use that is because I'm stuck on an ipad. It kinda sucks, but as soon as I get on the computer next I'll show you guys what I have already made. Might be a day or two though, it really is that bad.


    Edit: also, ice doesn't really apply to me, simply because I don't like the ice reactors because of the massive set-ups of compressors required and/or having to hack the items in. They make for something cool to look at, but aren't very practical in a legit world compared to bucket CASUC reactors.

    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.

    Which also, of course, requires the thermometer addon so you don't accidently blow your self up guessing where your temperature is.


    I've thought more about automated breeding and have similarly reluctantly reached the conclusion that a closed-loop control system is required. This currently means a human must be involved since there is no in game way of reading the reactor temperature and making a decision based on it. Which isn't to say that it's impossible to make the reloading mostly automated; it's just that there are still observations and decisions which need to be made by hand.


    I disagree on the offset issue though. For automated setups you want everything to complete at the same time (even if your uranium reloads are synced to your enriching cells or not) so that you can do something like detect the reactor's power output via redstone to trigger an end of uranium pause, dump spent, push buckets (to fill cooling slots), push uranium (reloading breeding slots), suck enriched, reload renriched, reload and hold for human confirmation.


    Though that sounds like a lot of effort to program via logic gates. Worse-Better would be just pausing it whenever it detects loss of power and/or a retriever pulls a single re-enriched uranium cell. (You'd loose a noticeable quantity of temperature, but not a critical amount which can't be restored by cutting off the external cooling for a small duration.)