Mk5-CASUC 640 eu/tick 4.27 eff with redpower 2 pre3b (Outdated does not work properly on 1.0)

    Yeah, I recently built a reactor [it was going to be a display model for "how they work"] ... it exploded. I thought I might have done something wrong, or didn't have it all in one chunk.
    Maybe it was the "timer issue" You still haven't explained WHAT it is lols. Or I would actually test the shit. .. Redpower stops working... at points... yeah I'll try to see if I can cause that to happen... (it's probably happened for me but I didn't notice, or the reactor blew up and I was like "there goes another one" ... Hell I've had one blow up that, I don't even know what reactor it was or I didn't even think it was running... )


    I've only ever had a couple of these reactors that were actually stable [through chunk loading], so it almost seems like luck of the draw with me :P


    Also I think you have your math a little off, or you linked the wrong planners, cos you're using 18 uranium cells to recharge 12, so idk how you can think it'd cost 4 uranium for 2 1/2 cycles. Since the run cycle would require 12 additional uranium + the 12 cells you just bred. [Still seems like at least 18 uranium minimum for 2 cycles (and I think that's with counting the bred cells twice) *shrugs*].


    I actually did manage to screenshot the "idiot switch" I used on that reactor to make it impossible (or well probably near impossible) to run the reactor without the cooling system on.


    “You can't make anything idiot proof because idiots are so ingenious.”
    ― Ron Burns

    Automated breeders arent so good. Problem is the low eff you get with them which you have to compensate before you would get any profit in terms of eu/uranium ore. I think better would be a dedicated 4000 heat breeder where each uranium cells is surounded by 4 depleted ones. It wont be fast but you can recharge alot of them at the same time. You would get 8 uranium cells for every 5 uranium ore this way + chance uranium cell turns into a depleted cell. So that would mean a nice +60% boost eu output per uranium ore.

    I was just trying to chase down the "timer issue" I don't think it exists. Any weird glitches may be based on tubes or machine problems.


    I tested using a vanilla MC timer (just 2 repeaters) running alongside a redpower timer, having their outputs go to an AND and an XOR gate (which output to 2 seperate counters) got the two synced up, and could never get the XOR counter to go off [well cept the time I relogged, and the vanilla timer broke :P] so all-and-all redpower timers are just awesome. I was playing around at the view limit on far (where you can see chunks unload/reload) and could still see the circuitry working.


    Though, an interesting point, when I hooked up some lamps to see the outputs better (since redstone torches would burn out) when I got about 2 chunks away the lamps started "acting funny" and would blink randomly or stay lit, or one or both would turn off... though I could still see the pointer on the timer going around. Even the redstone wires behind the lamps (including the repeaters) would appear to be in whatever state the lamps indicated, though, it was merely a graphical issue as, everything was still working flawlessly. After removing the lamps I was able to get the repeaters to stop in a similar manner (with the RP timer appearing to work normally) once again, just a graphical display anomaly and the circuitry was still intact and operating normally.


    -Also the system worked fine when I'd run Minecraft in the background whilst tabbed out (like now) with the system still simulating. *checks* Yepp AND counter full, XOR empty *rotates AND timer*. Seriously I can't break it. Or all of redstone breaks, but like I said, I could watch the thing working from far away, and it was working...

    Look, first things first.


    I already said ages ago what I knew of the timer issue, you guys really need to read more thoroughly. I said I didn't really know what it was exactly, that I thought it was more likely to be a problem with RP as a whole, not just the timers, and that it was excruciatingly rare, in addition to having nothing to do with chunk loading, log ins, etc. Did you read that or not? I hate to be so bitter, but it's frustrating. I know I ramble, maybe I can reduce the rambling to increase how much you guys actually read of my posts.


    Second, my math is correct because its not just 12, its that 12*4, because those two rows can be changed out 4 times if timed correctly.


    Rick, I understand that patterns which are more involved than simple rows of this and rows of that can be more efficient, as well as simplify things for the player because you don't have to worry about timing a change, but not so with automated refill stuff. I've been working with this for a while now, and while it is possible to create patterns in the reactor, it is much more complicated. Filling by the row is very, very, very easy. I'll show you when I'm finished. In addition, I'm making (already started) control panels for several reactor internal setups for it to automatically fill in order, creating a sort of "super cycle." I'm hoping to fit the control panels for 4 different regular cycles to fit in a super cycle, and have overriding condition cycles as well. For instance, if I ran out of coal, or uranium, or had too much uranium or depleted isotope cells.


    Also, having a pattern with that little uranium and with the uranium being that isolated has another disadvantage, which is that such cycles will have a huge drop in power, whereas my "super cycle" will only have a slight drop (in comparison, it still is a pretty decent drop though). However, because of the fact that I know I may not be able to think of the best super cycles, I am not trying too hard to calculate what will always be the best super cycle, nor the best overriding conditions that break the super cycle temporarily. Instead, I'm going to make them very programmable by even the yogscast for example. All you'll have to do is throw a lever for each row. Throwing it towards one side (with lighter lamps) will have that row be for breeding, the other side will have it fill with uranium. simple as that. add a few such panels together, and you have a super cycle controller with a little piston tape magic to cycle threw the mini cycles, and a timer on 2500 to catch any necessary re-enriched uranium.


    Lastly, Rick. Rick, Rick, Rick. If you can't find the memory cells on that crafting page, I almost want to give up. Did you even scroll? At all? They're right in the redstone section, with descriptions of what they do and everything. Just in case you don't know, they're called the Toggle latch (otherwise known as the T flip flop), the RS NOR Latch (if you don't know what that is... I don't even know what to say), and the counter. Got all that? Too complicated for ya? Geez... take a little time to scroll first... its so organized too, I don't know how you miss that stuff.


    Edit: Btw, don't expect this too soon (the automated, programmable breeder thing). I've had extremely limited computer access as of late, and it looks like it will stay that way for a while. Regardless, I've come pretty far and have most of the individual components created, I just have to put them together and remake them like a puzzle to fit into the chunk (which actually shouldn't be too hard since its all actually fairly simple now. wasn't that way before lol).

    So, I proceeded to download the .Schematic , place precisely in one chunk, and look inside
    I foudn that when I turned the reactor on then off it exploded ?
    I did not manage to get the coolant system to work properly so i will try again
    any suggestion about what i should re/place to make it functional would be helpful.

    Quote from glasstabels2

    Look, first things first.


    I already said ages ago what I knew of the timer issue, you guys really need to read more thoroughly. I said I didn't really know what it was exactly, that I thought it was more likely to be a problem with RP as a whole, not just the timers, and that it was excruciatingly rare, in addition to having nothing to do with chunk loading, log ins, etc. Did you read that or not? I hate to be so bitter, but it's frustrating. I know I ramble, maybe I can reduce the rambling to increase how much you guys actually read of my posts.

    The problem is I DID read what you've written about "the timer issue" or "rp issue" or whatever you want to call it. And I've always asked for more info because you've been very vague about it. So with the limited information I had, I ran a test. Hell the last time you even explained it, you just said you were on far render distance and 5 blocks away [now I didn't know if that was 5 blocks away from the device/timer/whatnot, or 5 blocks away from the maximum view distance since... you mentioned far render (and I usually run on normal cos I like a little fog)].


    You've also mentioned it was everything from timers slow down and start running slower then normal, to all of redpower just stops working completely.


    So, 1 foolish question: Is this a SSP or SMP issue? Because Eloraam already mentioned that she found an issue with timers on SMP and that it'll be fixed in the next prerelease.


    Since the problem is "excruciatingly rare" I suppose I could let Minecraft idle in the background simulating for over 24 hours, but idk how that'll help if I don't have the proper parameters for the conditions involved to re-create the issue. Though apparently it is completely separate from chunk loading or any sort of distance-based nonsense what-so-ever? And I might not even be on the proper platform to cause the issue (since I play on SSP).


    -- Usually if there's any problem it will find me, but I've yet to see this issue for myself. I have seen some other crazy stuff like duped buckets (but that seems fixed now that filters only run at 0.4 seconds) to ~9 buckets being bounced back for no apparent reason (though it might have been due to separate chunks). I've yet to have a reactor that was always stable through chunk loading become unstable, though I did have one I didn't even think was running (or I don't even know wtf reactor it was) explode. As well as a design that should have been stable that exploded. Currently these things are entirely too unpredictable for me to build another one legitly :P


    Ed:

    Quote

    Second, my math is correct because its not just 12, its that 12*4, because those two rows can be changed out 4 times if timed correctly.

    Sorry thought it was a 4k heat breeder. Which would only recharge 1 set of isotope cells per cycle.

    How could automatic reloading possibly work?


    Assuming you are using RedPower 2, since I am not entirely familiar with the things buildcraft additional pipe mods add.



    You have 2 filters pulling buckets. You build a complex mechanism to remove from one of those filters the bucket it has and to replace it with a depleted uranium cell. That lets that filter take out the depleted uranium.



    Ok, so now what? If you try to force a bunch of uranium cells into the reactor, most of them will end up in the invalid slots and pop back out. You have to force a huge number in really fast. So you'd have to have a counter system to count out the number of cells you need for a row and then to force them all in at once.



    Your NEXT problem is that buckets will be on the second and third row in the reactor when you try to do this. If you set up the other filter to remove the filled water buckets, you could then build a series of tubes that would count out exactly 9 empty water buckets, followed by 9 depleted cells, 9 uranium cells, 9 depleted cells, and so forth. It would put this pattern into a chest. Then, you'd have 4 transposers n the chest all attached to a 0.4 timer that would come on and flood the reactor quickly with all this stuff.


    Still would have problems. The reactor code will check for excess items in the wrong slots at intervals based on I think an iterator varible that starts counting the moment the chunk with the reactor is loaded. This would be difficult to predict. So, you'd get your stuff thrown out of the reactor at the wrong time.


    We could just wait for the patch, or simply edit the source code for industrialcraft so that a reactor with fewer chambers than 6 will have secret 'filler items' in the excess slots.

    Using junk. Look I've already figured it out, all I need to do is have computer access to a computer that I'm allowed to run minecraft on for a few minutes so I can build it. I can load junk very consistently, every single time, IF I do it by row, and do it by filling the missing spaces with junk exactly 1 redstone tick before inserting the next row of uranium. Let me walk you through it, and maybe one of you can build it, since I need to buy my own computer before this can happen it looks like, and that may take ages. I want to see this thing made already. Here's the step by step:


    1) first row filled with buckets (easy)


    2) put in 3 junk, then 1 redstone tick later 6 uranium/whatever it was you wanted in the second row.


    3) put in 6 junk, then 1 redstone tick later 6 uranium/whatever it was you wanted in the 3rd row.


    Repeat till done, adding 3 junk to each row. Technically if you managed to time it with the reactor ticks you could fit in multiple rows at a time or form patterns within the rows, but it would be extremely difficult and I haven't figured out a way yet.


    The timer issue: that was my whole point that it was vague, and I wasn't asking for you to test something extremely rare, just whether you had had the problem, and what any ideas on how to fix it were. I already mentioned that if it was just timers or redstone it could be fixed with other timing mechanisms (minecarts), but that it seemed like it was all of RP and that the only way then would probably be for eloraam to patch it. Yes, it was SSP, unfortunately, but maybe if we're lucky eloraam will have fixed whatever it is for SSP as well. If not, back to the minecarts, but I have yet to have had a problem with it again. Then again, I've barely been able to run anything as of late.


    Anyways, Bricked, please at least try a setup like I just described. From all my testing, I have yet to have had anything load incorrectly from a single redstone tick delay, although something tells me it might have to be a game tick rather than a redstone tick to guarantee perfection, which could be achieved through pistons, but would be slightly more complex.


    Lastly, maybe I don't understand how breeding works exactly, I apologize if I don't. I thought it only had to do with the amount of heat going into the actual components (depleted isotope cells) of the reactor, not the hull heat exactly, although the two are related in most designs. In CASUC designs though, they barely correlate at all, thanks to the fact that the only thing being cooled down is the reactor. Correct me if I'm wrong, I based it off the http://test.vendaria.net/ reactor testing app since I haven't had much access to things which run java lately. According to the way it runs, if there is no uranium next to the isotope cells, even if the hull heat is 10,000,000 it won't recharge the isotope at all, and if the cell is next to uranium but none of the heat goes into the hull, the isotope still charges. Correct me if I'm wrong, I haven't had time to actually run it once in actual minecraft and see for myself. If I'm wrong I apologize.


    Like I said though, I've had refilling down to a science for a while now, all I have to do is put the pieces of it together, though maybe you can do a better job considering how long it will take me. Important things to note though:


    1) The junk cannot stack (seems obvious, but is very important). It can technically have the same junk involved in different rows, as long as the rows aren't filled at the same time. I've tried building rows on rows as well so I only have to add 3 junk each time, but I can't do it in a short enough time interval so I went for the simplicity and consistency of loading rows seperately and in order.


    2) You can't load lower rows easily until the above rows are all full, because then you'd need a ton of junk.


    3) I use junk because the reactor automatically chucks it out in case it winds up in the wrong spot, and then I can just use the overflow transposer to suck it back to the appropriate junk chest, but you can use other stuff if you like. I prefer random junk, like scrap, cobble, dirt, etc. However you do it though, I highly reccommend using something that you would never put into your reactor (for me I'd never put in a cooling cell). This way, if something that was supposed to go in gets rejected (uranium), it can be detected and that row/the refill can be redone.


    Edit (forgot to mention this): getting rid of the excess buckets at the end of the cycle did stump me for a while, but I used the fact that the deployers should be empty at the end of the cycle in addition to adding filters for the re-enriched and near-depleted cells which were one tube closer to the extraction filter, and thus take priority over the deployers if the item can go to them (is valid for the filter's well... filter lol). That combined with the fact that I have 4 deployers which is more than enough to hold the extra buckets from the end of the cycle makes it very easy, although I did have to add another chest for some excess in case it didn't fit in the first, rather than putting all the extra buckets in the deployers as a standard. My newer version has enough room for all the buckets to fit into the buffer chests (one large, one small).


    Anyways the procedure is very simple for the end of the cycle:
    1) take extraction filter's filters away, so they pull out anything and everything.
    2) take out anything and everything (the filter design I just mentioned takes care of directing its path properly).
    3) pulse the insertion deployer triplet twice (to fill the top row with 6 buckets).
    4) use refill instructions above.


    Edit 2: if the refill method isn't clear (sorry its kinda spread all over the place) just ask and I'll try to make a clearer post next time around, or better a schematic of the test setup I have. I actually used hatches and pulse formers to cycle the pairs of junk and uranium rows down into the same two transposers so it would be a little cheaper and smaller in the long run.


    Edit 3: Concerning the timer method of jamming things in you mentioned, brick, I instead opted for using 2 transposers: 1 for junk and 1 for the items I actually wanted, because transposers can pull a seemingly infinite amount of items into a tube at once (or at least more than enough for it to work in this setup). I have the piles (rows) put onto a tower of hatches in advance. when the reactor is ready for them, the bottom row is sucked into the reactor, there is a 2 second delay (just to be safe) and then the hatches pulse to ready the next row.

    In case the refil method is unclear this is extremely similar to the 'dead' periods on analog CRT signals to allow the scanning beam to be re-aligned to the next line.


    So you'd load up the items across like this:


    First row:
    1 2 3 (4) (5) (6) (7) [8] [9] << in order, with the end of it being the items you'd know would be discarded.



    Allow the discard to happen on the next tick/pulse. (Does discard happen on redstone tick or reactor pulse?)


    Subsequent rows:
    Pre-fill with ( RowNum - 1) * Discard size per row (to fill in the end of cleared rows above)
    Repeat first row procedure for current row.


    Actually if you call the top row the 0th row, and the next the first then this algorithm works for all 'rows'.


    Prefill = Row * DiscardSize
    Fill
    (Ignore postfill; you don't care)


    The important question then is; can you insert 10 dummy items + 7 real items in one duration (and reliably too; how can you tell when the reactor will next reject material?)





    Proposal: When 'redstone' signaled the reactor shall not eject material from hidden slots. This doesn't seem like a big change to the code and VASTLY simplifies the current situation by making it a fully controlled (if still open) loop.


    Thank you for saying what I just did better, that was actually really helpful.


    As far as applying redstone, that doesn't apply to random junk, nor to buckets (filled or not), so I don't think it even can be said that it applies to the general array of items which apply to reactors, but maybe it applies to uranium since uranium doesn't do anything while the reactor has redstone applied. That would be an interesting solution indeed, and would probably allow for patterns to be easier to make, although I'm not sure quite yet how much more useful that would make it, as I can't think of a pattern that satisfies me as well. I don't like the idea of changing out the re-enriched uranium for depleted cells 8 times, and I don't like the idea of a low amount of EU/t like 75, but I suppose it could be technically more efficient if you were particularly low on uranium, and it would be useful to at least have the capability to use such patterns.


    Still, I'm trying to imagine a could way to program such patterns (involving row and collumn filling) with a control panel, and can't think of one, so that'd probably have to be hidden from the user, because otherwise it'd probably be too big. As such, I don't plan on doing that for a while.


    Also, to answer your question the rejection does indeed result on reactor pulse, which makes it technically possible to have many iterations completed in one reactor tick, but it would be difficult to figure out when exactly the reactor ticks. I've found that it doesn't come on exactly when it is unpowered either, nor turn off, meaning that there is a set timer for them which is seperate and it would be difficult to time things based off such a system, although I suppose that some junk could be initially sent, then it could be detected when it was rejected based on several, differently timed transposers to suck it up, and the timer could then be started based on the results. Still, I'll leave that to someone more awesome, I don't really want to deal with row AND collumn patterns really unless someone can show me a really huge benefit.


    Edit: lastly, if you were wondering with your last question as to how i would jam that many items in at once (I think that was what you were asking but wasn't totally sure), I'm using transposers which suck things from the air. When transposers suck a pile of stuff in the open, it just immediately outputs everything out the backside, all at the same time.

    The reactor probably 'ticks' exactly on the second in game. However there is no in game way of determining that alignment so the point is moot.


    In my proposal; the redstone 'stop' signal would already stop uranium reactions, and thus I see no practical benefit to allowing a reactor to be filled up. The absolute /best/ case for abuse would be filling too much space with waterbuckets, but you could just wait a bit longer and get the same effect. Actually adding a bound on the waterbucket check such that it only runs over the allowed rows would solve even /that/ case. This leaves only negative effects (like stuffing a reactor full of partly enriched or replenished but not reprocessed cells).



    As for patterns, I have one in mind, but I won't have time to test it until this weekend. I have shared it with someone else though. Now as for automated /reloading/ of the pattern; that's where controlling the ejection timing becomes critical. It's pointless for me to even try without that behavior locked down.


    As a bonus though, you needn't have the refill circuitry within the chunk...

    You at the very least need the timer for the refill circuitry in the chunk though.


    As for guarunteeing the refilling to work correctly, it would seem that if things are inserted the instant that junk is rejected (on the same tick), the insertion works, because I have yet to have a problem with that. Thus, filling by the row has been a piece of cake, and I don't have problems really with filling it with the wrong stuff. I shouldn't say that I can't create specific patterns. I CAN do it by the row, but not by the collumn as that requires timing the insertion exactly with the reactor tick.


    However, because of the fact that items being inserted at the same time that junk is rejected still works, the only reason it would stop working would be if the reactor happened to tick on a game tick, but not a redstone tick. I haven't seen this happen yet, but also haven't had a good chance to test things yet because of previously mentioned computer access problems. Just in case you happen to finish the automated breeding reactor before me, would you mind giving me a shoutout? I don't know how much of this you came up with on your own though, so if all I did was tell you whether it was rejected on a redstone tick or reactor tick or something like that then I don't mind if you take full credit.


    Edit: OHH... you mean timing for removing the re-enriched before an extra tick happens. Well, you can try what I just suggested earlier by figuring out when the transposer sucks out the item from the air, but that will only give you precision within .4 seconds. You can add transposers which are timed differently to give you more accuracy though. I don't know if such accuracy is needed simply because the reactor tick is a full second, and I don't think such accuracy will be needed. The only problem I can think of is if the reactor tick and timer ticks get off-sync after the start because of unloading and re-loading the chunk, in which case junk would have to be inserted for timing sake repeatedly, which would be a bit of a pain, but not too much, because it would only have to be a single piece, rather than a pile. Still, you are right in that such a method would create a risk of taking the place of a bucket, but I suppose that the system would just have to be robust enough to handle that then. I can't come up with many breeding patterns in which the reactor couldn't (assuming that you wouldn't run such a check when it wasn't on a breeding cycle), but I suppose that just in case you could time the junk insertion such that it is always in the unseen slots, but it would be difficult, and I can't think of how off the top of my head.


    Hopefully the timer and reactor will just both be loaded at the same time, and it won't be an issue. If it is only an intermittant issue, then it isn't a big deal in my opinion, as I can always build another small reactor to deal with any rare, almost finished enriched depleted isotopes, but only if they are somewhat rare is that ok for me.

    well, I finally got a little time with the computer, and so far at least (hopefully I'll get to see the cycle the whole way through) it appears you are right about the breeding, I apologize. I was misled by the app, but now I need to know how it actually works (and may have to have a seperate reactor for it to be of good use). Can anyone link me a tutorial for breeding? not for the reactor in general, as I don't believe alblaka goes into detail as to exactly how the breeding works. Can anyone link me to a page with all the math?


    I suppose what I've been doing is still useful for refilling the reactor automatically, but I'd really prefer a automated breeding management system, even if it does require 2 reactors. I want to both get the best possible balance I can of the rate of EU's I'm getting with the rate it uses uranium (for my power needs of course), but more importantly, I want to build it once and let it do its thing. Of course I want to also be able to change it as well as my power needs change, but I'd prefer it to be down to throwing a few levers rather than having to wait for the cycle to end and doing it all myself then.

    Quote from MJEvans

    The reactor probably 'ticks' exactly on the second in game. However there is no in game way of determining that alignment so the point is moot.

    This statement is not entirely true. As sequencers are synced to game time. A 0.25 sec Sequencer would pulse each side once per second. Then you'd just have to determine which side coincides with the reactor spitting out items.


    And, yes, I believe reactors pulse once per second [I think it's been mentioned], and I'm pretty sure that's when the items are spit out. Also I just tested a sequencer to be sure. It stayed on time with the reactor spitting out items, through world and chunk loading, so... yeah it's pretty solid. Also I got lucky and picked the right side when I placed the sequencer, happened to be the south side (if the sun rises in the east) though that may be different for each sequencer.


    @glasstables and breeders:
    I'm not sure if there's a specific post for it, though Albaka goes into the details in the nuke tutorial.
    Basically how it works out is you can figure out the number of cycles needed to enrich uranium based on reactor heat / number of nearby uranium.


    I'll just give you the ones for 3k heat (since I assume we're using this system)
    with just 1 uranium next to the isotope cell, it would take 2 cycles to recharge it.
    2 uranium next to isotope = 1 cycle
    3 = 2/3 of a cycle
    4 = 1/2 a cycle.
    http://forum.industrial-craft.…ad&postID=13642#post13642 for more details.

    So wait, just to be sure: the south side of the sequencer is always the same side for the reactor? I understand that it always stays in sync with some side, but I would be very pleasantly surprised to find that they always loaded on the same side. however, it would seem that it may not matter much based on that last post. Of course I will probably still want a breeder reactor so I have something to do with all the near-depleted cells I wind up with, but it would seem to me that there isn't much of a benefit to breeding in the CASUC designs we have. I may still make an automatic breeder of sorts though, as a reactor which is missing 2 chambers can still withstand 9000 heat with a lava bucket (missed) to spare. Add in some plating and it may work very well. Still, with things being as they are, I find little benefit in breeding any uranium I have on purpose (uranium which was never a near-depleted cell) due to the long amount of time it takes compared to both the EU it outputs and the time it takes to find more uranium.


    Sigh... Its times like these I wish the uranium UU-matter recipe was still around, even if only in a very nerfed form, like almost as expensive as the diamond. Actually, that would probably still be overpowered when used with some of these CASUC reactors, but perhaps alblaka could bring it back in a nerfed form as an intermediate. For example, you can craft x with UU-matter, and with enough x you can craft one uranium. Similar to a gold nugget maybe?

    Quote from glasstabels2

    So wait, just to be sure: the south side of the sequencer is always the same side for the reactor? I understand that it always stays in sync with some side, but I would be very pleasantly surprised to find that they always loaded on the same side. however, it would seem that it may not matter much based on that last post. Of course I will probably still want a breeder reactor so I have something to do with all the near-depleted cells I wind up with, but it would seem to me that there isn't much of a benefit to breeding in the CASUC designs we have. I may still make an automatic breeder of sorts though, as a reactor which is missing 2 chambers can still withstand 9000 heat with a lava bucket (missed) to spare. Add in some plating and it may work very well. Still, with things being as they are, I find little benefit in breeding any uranium I have on purpose (uranium which was never a near-depleted cell) due to the long amount of time it takes compared to both the EU it outputs and the time it takes to find more uranium.
    -snip-

    No, I said mine happened to be the south side [and I was able to grab it the first time] it was the left side when I placed it, though... Each sequencer might be different, or depends on orientation when placed. I actually hadn't really used them before this (I like timers better). But I just stated the findings for my tests because I figured it should work. But it's pretty easy to figure out which side syncs with the reactor, and you only have to do that step once, because it retains its time. I mean I could try to place some more sequencers to see, but I know all the sequencers I place will [or well are supposed to] share the same time.


    Ed: Ok, retested, orientation of sequencer is based off direction facing when placed. Mine happens to be synced up with the reactor on the left side [so I was facing sunset when I placed the first sequencer].
    I don't know if it will always work out that way. Once again just stating findings :) *places some more reactors* But it seems that reactors aren't timed to anything specific. Had 2 reactors that spit out items at different times. So no, a timer will not probably won't always "sync" up with a reactor, but one side will be "close" (within 0.125 seconds of, at worst)

    Quote from AkhkharuXul

    No, I said mine happened to be the south side [and I was able to grab it the first time] it was the left side when I placed it, though... Each sequencer might be different, or depends on orientation when placed. I actually hadn't really used them before this (I like timers better). But I just stated the findings for my tests because I figured it should work. But it's pretty easy to figure out which side syncs with the reactor, and you only have to do that step once, because it retains its time. I mean I could try to place some more sequencers to see, but I know all the sequencers I place will [or well are supposed to] share the same time.


    Ed: Ok, retested, orientation of sequencer is based off direction facing when placed. Mine happens to be synced up with the reactor on the left side [so I was facing sunset when I placed the first sequencer].
    I don't know if it will always work out that way. Once again just stating findings :) *places some more reactors* But it seems that reactors aren't timed to anything specific. Had 2 reactors that spit out items at different times. So no, a timer will not probably won't always "sync" up with a reactor, but one side will be "close" (within 0.125 seconds of, at worst)

    Ya, I hear you. What I really meant by asking though wasn't if it would always be the south side, but whether whatever side it happened to be at the beginning remained to be the synced side through travelling far away and reloading the world. I mean am I definitely only going to have to sync this thing only once? It would seem though that you've already answered that. Still, .125 seconds is fine, but I'm probably going to change the method I'm doing this with, as a 4000 heat breeder isn't very efficient now is it... I'll probably work on something simple that doesn't create excess heat like most people have been doing, but add filters to it so I can pull stuff out and put it back in as needed. I could do something fancy with lava buckets and water as well to try and keep it exactly a little above 9000 heat constantly, but I've already stated earlier that I don't trust RP CASUC reactors to really stay perfectly consistent or follow calculated values perfectly because of many various issues, so I doubt it would work too well. I'll still look into it though. It really would be a ton easier if there was a thermometer that could be used as a machine, and direct other machines (via redstone or something). However, I believe alblaka mentioned that the new computer things will possibly give at least some more control over reactors (don't know if it will involve shuffling things on the inside, measuring heat, or what), but if they can measure heat then it will be much easier to make a >9000 heat CASUC breeder reactor that only pulled water buckets as needed. I don't really think it would change our CASUC designs much for main power production reactors though, except that a single reactor could always do the job of two, but it'd probably be easier to have the breeder be seperate.