deployers only suck water from 2 blocks away unfortunaly. I used 2 deployers in my system and made the pipe system so that the buckets get distributed across them.
Yepp, and same. I know they only suck from 2 away, but I figured the extra block of water at the end might help that second block of water respawn faster (probably doesn't though).
Tested my system and its working 100%. Unless chunk loading also stops my system it cannot explode with normal use (meaning never fill top 2 rows with uranium).
I would assume chunk loading also stops your system (unless your detection shut-down works). I just reloaded mine and put in just 2 rows of uranium, the rest water, and ... still explodes on chunk reload.
So i flew far away to unload the chunks then flew back at diferent speeds and repeated alot of times but i just cant make it explode. I did it like 20 times but it just keeps running normally. So far it seems this system works.
Through what i noticed is that the buckets seem to stop moving while the chunk is getting loaded could this explain the meltdowns? The item detector prolly shutsdown the reactor while the chunk is loading thus preventing a fatal meltdown in a few seconds (from 0 to 14000 heat takes only 13 seconds in my reactor and since its already at ~4000 heat).
MCedit file:
http://www.2shared.com/file/3V5UhoLH/Tamed_mk5_reactor.html
Now have fun if it explodes post it here and describe when/why it exploded 
So i flew far away to unload the chunks then flew back at diferent speeds and repeated alot of times but i just cant make it explode. I did it like 20 times but it just keeps running normally. So far it seems this system works.
Through what i noticed is that the buckets seem to stop moving while the chunk is getting loaded could this explain the meltdowns? The item detector prolly shutsdown the reactor while the chunk is loading thus preventing a fatal meltdown in a few seconds (from 0 to 14000 heat takes only 13 seconds in my reactor and since its already at ~4000 heat).
MCedit file:
http://www.2shared.com/file/3V5UhoLH/Tamed_mk5_reactor.html
Now have fun if it explodes post it here and describe when/why it exploded
Loaded it into a new world, it exploded before I even found it. Loaded it in to my existing world, made sure it was all working. Went ~300 blocks away and came back... to an exploded reactor. These things just explode.
I like what you did with the transposers though
Edit: If at first you don't succeed, try and try again.
So... I've MCEdited this thing into the first world about 5 times now. It explodes every time. Even when I would spawn it in the air... The row of filled buckets stops and then BOOM!
I've seen this thing run once, and it was running, working fine... so, idk wth is going on with it exploding right after MCEditing it in.
Edit 2: Loaded it in a couple times more, this time placing my player directly on top of the device before saving and exiting out of MCEdit... both times the empty buckets weren't being pulled out (noticed the second time... but it exploded before I could find the kill switch or where the empty buckets go.) [but I could see power going to the filter that was supposed to grab them]
Display MoreLoaded it into a new world, it exploded before I even found it. Loaded it in to my existing world, made sure it was all working. Went ~300 blocks away and came back... to an exploded reactor. These things just explode.
I like what you did with the transposers though
Edit: If at first you don't succeed, try and try again.
So... I've MCEdited this thing into the first world about 5 times now. It explodes every time. Even when I would spawn it in the air... The row of filled buckets stops and then BOOM!
I've seen this thing run once, and it was running, working fine... so, idk wth is going on with it exploding right after MCEditing it in.
Edit 2: Loaded it in a couple times more, this time placing my player directly on top of the device before saving and exiting out of MCEdit... both times the empty buckets weren't being pulled out (noticed the second time... but it exploded before I could find the kill switch or where the empty buckets go.) [but I could see power going to the filter that was supposed to grab them]
Are you in RP Pr 3, or 3b? that would make a lot of sense if you were in 3b.
Rick, I'm sad that it doesn't work anymore, but there's no going back for me, on to progress! Thankfully, you did alert me to something very helpful nonetheless: While filters in 3b can only pull out an item every .4 seconds once they've started, they can start on either part of a .2 timer. As such, huge improvements were already made to my systems by changing the timer, as now, instead of a worst case scenario of the filters waiting up to .35 seconds after something happens to respond, it has been reduced to .15 seconds, so more than half of the response time has been taken away, and on both ends. That has worked wonders for my bottlenecks. I threw together a new version in the last 30 minutes to an hour to see if I could fix the kinks, and the result is attatched (both schematic and world file). See if you can get it to blow up, but make sure you don't accidentally drop any items near the transposers, as that will clog the system up. If that happens, explosions there don't count. This new version of mine should also be a lot easier to hook up a hv transformer to, but sadly they don't respond to wrenches in creative mode, so you'll only be able to hook that up if you mcedit it into a survival world, as I'm too short on time right now to change the world mode myself.
Edit: world wouldn't upload as an attatchment, really sorry 
also, if you're having trouble knowing how to fit it into one chunk, just look for the "chunk align" box to the left after you click import and choose the file. this will allow it to only go into the one corner of any chunk. In addition, you'll notice that certain lines of the gridlines seem darker for some reason: these are the chunk boundaries.
Hope that helps. I also made the switches on the reactor system such that the reactor can only be turned on if the cooling system has been on for a little while. I plan on making a very good failsafe that also provides debugging as to what part of the system failed, but I'll have to get to that later, as this is coming to you from school during a free period of mine.
Also, you guys might want to add one more system to your failsafe systems: keeping a single water block in the reactor range. I've found that it guarantees that it gets evaporated as soon as the reactor would have evaporated any water, and can be used with a water sensor (boat style) to detect any slower overheats which might not get detected by the other systems. See what you can do with that. Otherwise, I really don't care about failsafe systems until we can get these to hold up to testing better than they currently are holding up. I think we can do better, and taking the time to put failsafe's into cooling systems which already aren't reliable yet is wasting time that we could be spending making said systems more reliable. I suppose one way to make it reliable would be to lock the player in till it was done lol.
Next version should have some big changes that allow for much more control of everything, I'll probably release my version 3.0 late tonight.
Display Morealso, if you're having trouble knowing how to fit it into one chunk, just look for the "chunk align" box to the left after you click import and choose the file. this will allow it to only go into the one corner of any chunk. In addition, you'll notice that certain lines of the gridlines seem darker for some reason: these are the chunk boundaries.
Hope that helps. I also made the switches on the reactor system such that the reactor can only be turned on if the cooling system has been on for a little while. I plan on making a very good failsafe that also provides debugging as to what part of the system failed, but I'll have to get to that later, as this is coming to you from school during a free period of mine.
Also, you guys might want to add one more system to your failsafe systems: keeping a single water block in the reactor range. I've found that it guarantees that it gets evaporated as soon as the reactor would have evaporated any water, and can be used with a water sensor (boat style) to detect any slower overheats which might not get detected by the other systems. See what you can do with that. Otherwise, I really don't care about failsafe systems until we can get these to hold up to testing better than they currently are holding up. I think we can do better, and taking the time to put failsafe's into cooling systems which already aren't reliable yet is wasting time that we could be spending making said systems more reliable. I suppose one way to make it reliable would be to lock the player in till it was done lol.
Next version should have some big changes that allow for much more control of everything, I'll probably release my version 3.0 late tonight.
Yeah, I figured out how to work it
I like the repeater as a virtual gate ... though the delay seems long enough that if you shut off the cooling system with the reactor running, I think it'll blow up. [wasn't going to test it as it survived 5 distance-based chunk reloads (which is 4 more then any previous system]
The fact I found odd: All of my systems failed due to empty buckets getting broken in some manner (hence I thought there should be a chest buffer on the empty bucket line) ... your system doesn't have that and still it works. [Mine was completely backwards to that, no chest on the filled bucket loop, and a chest on the empty trail [though it serviced both] Maybe with the automatic splitting from T's [Would up the empty bucket log to 18 instead of 9 before catastrophic failure] I'll be able to run my original (with a Chest on the full loop) and it'll work?
I must say, that is a LOT of transposers. Though I like the symmetry the system has. (and the fact that it has no failsafes, other then redundant systems -- and yes I'm running 3b and the 0.2 timer seemed fine) [Anyways I've got things to do.]
I wanna call this one safe ... well as safe as any Mark V reactor can be
One more thing I forgot: deployers actually suck water from 5+ blocks away. I discovered this from sucking lava from the nether actually, I was doing some geothermal stuff. The thing is, water generates so fast that they never will get one from even 3 blocks away I don't think. In times of lag though, it may be useful to have the third water block.
One more thing I forgot: deployers actually suck water from 5+ blocks away. I discovered this from sucking lava from the nether actually, I was doing some geothermal stuff. The thing is, water generates so fast that they never will get one from even 3 blocks away I don't think. In times of lag though, it may be useful to have the third water block.
I knew my third water block was there for a reason! [I didn't think they pulled past 2, but I never tested it... with air blocks in the middle]
Yeah, I figured out how to work it
I like the repeater as a virtual gate
The fact I found odd: All of my systems failed due to empty buckets getting broken in some manner (hence I thought there should be a chest buffer on the empty bucket line) ... your system doesn't have that and still it works. [Mine was completely backwards to that, no chest on the filled bucket loop, and a chest on the empty trail [though it serviced both] Maybe with the automatic splitting from T's [Would up the empty bucket log to 18 instead of 9 before catastrophic failure] I'll be able to run my original (with a Chest on the full loop) and it'll work?
I must say, that is a LOT of transposers. Though I like the symmetry the system has. (and the fact that it has no failsafes, other then redundant systems -- and yes I'm running 3b and the 0.2 timer seemed fine) [Anyways I've got things to do.]
I wanna call this one safe ... well as safe as any Mark V reactor can be
My lever system: well, you can kinda tell I just threw that together at the end, lol.
Chest buffers: well, I found that it was much more important to have the chest buffer be one with full buckets, as that is what is getting chucked out of the reactor (into the air) when you shove that many buckets in, so its more convenient to have a full bucket chest buffer in the first place, at least for overflow designs.
Transposers: ya I know, but I wanted to be sure. There's tons of redundancy all over the place in the system, and the transposers were no exception, although when I first tested it it actually hurt me because there were too many buckets in tubes on their way back to the buffer chest, and not enough actually in the buffer chest at times. I may make a second buffer chest next time, or just reduce the amount of transposers to something more reasonable. I remembered though that you can put wiring on them, and since I had a good deal of blocks with wiring on them in the appropriate positions already, I figured why not?
Symmetry: I was actually going for that, and moreso than compactness this time. Realistically only one of these would ever need to fit in one chunk ever, as only one of these super-reactors would ever need to be owned by anyone ever. Therefore I've been leaning towards making this easier to build. This is the result, its a lot less jam packed and a lot easier to remember and wire, including if you screw up. In addition, the chest is actually accessible, so if junk accidentally does get sucked in, you can get it back out.
Actual amount of redundancy:
Extraction from chest/Insertion to reactor: 7.5 buckets per second
Extraction from reactor: 5 buckets per second
Potential fill rate: 10 buckets per second
Actual amount of buckets needed (theoretically, which we all know doesn't work out so well): 3.
You leaving it at 5: well, I'm sad to here that, as you've been a fantastic tester of this stuff, and have been much better at finding the problems with our creations than us, which is good because it drives progress, and stops ourselves from stopping development too soon and blowing up all our bases lol. Still, I understand what you mean, after having that many blow up... In addition, there are better things to do in that there's hardly any good system of using all this energy right now, so I'm working on that. Like I said, I hate MF'ing without the proper amount of scrap. I mean, without scrap, you're pretty much wasting ~85-90% of the energy, which is absolutely ridiculous, and I can't imagine why people do it, especially with a finite resource. Anyways, just keep your eyes peeled for version 3.0, it should have a lot more features than just a cooling system.
Wouldn't you be able to build the entire thing in a single chuck if you go vertically? Might be it would also be more convenient, since AFAIK it's mostly easier to fit something tall than something wide in a base...
Probably requires more thinking into layout though, arranging everything into floors and suchlike ... But it would be beast 
Edit: Chunks always origin at the X/Y axis right? So everything dividable by 16 is a chunk border?
Heh, glad to help. Soooo want to nerd in on this BC+IC thingie, but I'm not ready to give up on school ... Just yet 
Edit: The moment you relize you probably shouldn't post too much when you are sleep deprived
The shutdown system of my reactor is build (purely by luck i didnt intended it) precisely in a chunk so that could explain that it just cant explode. When the chunk with the reactor is loaded the emergency shutdown is loaded too at exactly the same time thus making is impossible to blow up. Good point to remember for a tutorial iam going to make later on.
Just mcedited your reacor in my world gonna check it out. Very nice compact design only things to note are too much transposers and no containment chamber if it blows up it will destroy your entire reactor and its surroundings. I try to isolate the redstone circuits and cooling system from the reactor if it blows up they will remain intact (through i failed on last one with only 2 layers of reinforced stone but you get the idea :)). But the way you used the 3th dimension to fit your design in 1 chunk is nice.
That shutdown system stuff is important, but I have to admit that I'm not at all fond of a system where you need to plan for it to blow up... at all. I know that's naive of me, but still, I can hope. I plan on using lamps for debug, and including which side had a problem for debug's sake. For instance, I'll probably have a grey lamp for if it was a problem with the empty buckets, a blue lamp if it was with the full buckets, and a green or brown lamp, or maybe a red lamp for the slow overheat detection system (still not sure about the color, maybe brown for the boat which it uses).
As for the incompletion with the lack of reinforced stone and whatnot, I just hadn't gotten to adding it, of course any design in a legit world would have that, but I wanted to test whether it blew up at all before worrying about protecting things from it, because I really don't like the idea of it blowing up in the first place. I've protected things before and know how a lot can be saved (especially if there are obisdian pipes that are protected at the bottom which are opened up by the explosion to catch the remains), but I don't like the idea of having to rebuild it all the time, nor even debugging it or restarting it. In fact, if I ever get around to version 4.0 or 5.0, those ranges of versions may have ways of not only stopping themselves in case of a problem, but solving the problem and restarting themselves. I like my automatic stuff to be as fully automatic as possible, all that I should have to do is supply the uranium (if that). Sadly, it would seem that since the uu-matter recipe for uranium has been taken out, I really will have to supply the uranium, but if things go as planned, I won't have to handle the uranium or load the reactor myself. I've been getting pretty good at figuring out exactly how and why items act the way they do (concerning what sticks and what doesn't in the lower rows).
Too many transposers: like I said, there were already going to have to be blocks with wiring on them where most of those transposers were, and since you can put wiring on transposers I figured why not. Soon I'll be seeing how much I can reduce them, but I assume that there needs to be at least one for every transposer/filter inserting buckets so that it can begin running the cooling system without the reactor running (in other words with no empty buckets coming out). I also have noticed that buckets tend to pop out towards the side they go in moreso, so that side becomes more important, which is another reason why it worked out well to put the insertion on the bottom, although I can't really claim that I had been thinking about that at the time.
Compactness: thank you. Its not as compact as the last design, but its much simpler and perfectly symmetric. My favorite thing was making the deployers water troughs share middle water blocks, and I will probably have even the pairs share some in the next big version, as I will probably need to open up the design anyways. Therefore, I will most likely move the deployers either above or below the reactor. This also opens up another checkpoint for a failsafe detection system. It doesn't really make it more foolproof, as the other failsafe systems would have been effected by the same problem, but it does make it easier to identify exactly where the problems are, as it adds more options to the debug. I really like the idea of a debug system, especially with our failures being when we were far away. Therefore, it was really difficult to troubleshoot compared to most projects, because it worked perfectly when you were there, then mischievously blew up only while you weren't there to see what went wrong. This way, hopefully we'll gain much more insight every time something goes wrong. I highly encourage you to adopt a similar style so we can get as much information from as few failures as possible, even if those failures' explosions are successfully avoided. If those explosions are successfully avoided, then we'll get even more information out of it. Its all about how much info we can get on this stuff, what bugs/quirkiness there is to it, and how exactly that quirkiness plays out. I think that very, very soon (at the rate we're going), we'll have these easily as reliable as any mark II, or even some mark I's out there with no downtime at all. That's the goal for me, to make a mark V reactor's output, but with no downtime and no maintanence, as well as easy wiring at the start, although that isn't quite as important since we only will have to build it once. Of course simpler usually does actually work out to better in the engineering world... and it makes it friendlier to others who want to build it.
We learn alot of stuff from each other this way i mean i was thinking a bit too much on 2d planes :). I need to make a design that fits in 1 chunk and has a containment chamber of atleast 4 blocks thick to prevent it from raping your entire base if it explodes. No mater what you do risk will always be there even with my system. Its not foolproof for instance which in smp environments can be quite handy (just imagine a noob destroying a critical wire and blowing everything up...).
But we are pretty close to the 'perfect' reactor now i think :).
we certainly do, I'm glad my friend showed me this topic. right now i'm working on adding transposers and tubes to my extraction filters so I can change what I'm pulling out/putting in so that I can refill the reactor automatically, potentially (though it will be quite the project) handle automatic breeding swaps mid-cycle, and add another layer of safety to the shutdown by being able to actually extract the uranium and replacing the uranium slots with full buckets, instead of just the empty buckets. This will also make it ready to go again much faster in certain cases, but I still have to play around with it. This was actually what I was going for in the first place, but the first step was getting the cooling system working at least decently enough for it to be reasonable to apply it. I think we are close to that point if not at it, but I need to go home and do some testing to be sure first. I hate to go so slow and really want to move on to that really cool stuff, but I hate backtracking even more.
Edit: also, can't you get blocks protected in SMP? If that is a problem though, I would suggest looking into making a coded door and a problem for them if they get it wrong so many times or something. As for protecting against griefers, there isn't much you can do besides hiding it, and while that's easy physically, word of mouth will make that nearly impossible. Therefore the best protection against griefers is to make sure the op on the server or somebody protects those blocks. Funny (at least to me), I've found that since you can put lava in mine, it should be fairly immune to griefers if all they can do is access it but can't destroy it. I suppose that if they put in more uranium in the bucket slots that there would be a problem there, but the empty bucket detection would catch it, and if all goes as planned in the next version, it will actually be able to remove said griefing uranium, and fill that area with full buckets.
One more thing: Since these reactors are really a class of their own, I'm not sure they should be classified by the normal sense, but in order to classify them, we need a standardized test. I suggest a minecart track that puts you into and out of range of the reactor repeatedly, hooked up to some t-flip flops counting how many times you made it throw, and maybe a line stopping the flip flops from counting whenever the reactor blows up. Then we can classify them based on the number of loads/reloads they can handle, and the speed at which it is unloaded/reloaded. I'll post a schematic or world file (if I can get it to work) of what I have in mind once I actually build it. I definitely don't think it's appropriate to classify these based on the number of uranium cycles they can handle, as they can very easily handle infinite cycles when you're standing right next to them, but many of these designs can handle only a few seconds when unloading and reloading often enough. They really are not dependent on the cycle number whatsoever, but I have noticed that the number and frequency of reloads is both the only major cause for problems, but also a fairly accurate and measurable response in most of these designs, although we might need to average a few samples to get the real measurement. I'm not sure what else should go into this class of super-reactors (like automatic loading, automated breading, how many options are handle-able for automated breeding, etc.), but I think we should pioneer a new name system for this class, as the old one doesn't apply well at all. When close though, these reactors are essentially the "perfect" reactor in the sense of the old class. They are perfect breeders (within an equilibrium), extremely high efficiency, and mark I in terms of cycles they can handle, but only up close, and pretty much all of these designs are such up close. The key difference isn't any of that, but instead how much lag and loading they can take.
Anyone else feel free to add suggestions for the naming system, and the name of the class as a whole. I personally like acronyms.
Edit: I can make this standardized test on my own, but I don't know the exact render distance's... well... distances lol. I can probably look them up, but if anyone told me that would make things rather convenient. So far I have a straight line of track with powered rails on both ends, and a detector rail at the end with a one way turn so you don't count twice every time you go in and out. To make sure it stops counting after the reactor blows up, I have my cooling timer in such a place that it will be destroyed upon failure, and a slower timer hooked up to it, such that the destruction of the first timer will allow the slower timer to pulse, which sets an RS latch which was powering the closer end of the track back to unpowered. Let me know if you guys come up with any better ideas, but i think this will make a great standardized test. The only thing I'm not sure of how to alter as well is speed of chunk loading/reloading, but I suppose we can do that with the amount of extra track on each side of the border of loaded and unloaded. More track on each side (with it being centered on the border) means more time between each load/unload for recovery.
Display MoreLoaded it into a new world, it exploded before I even found it. Loaded it in to my existing world, made sure it was all working. Went ~300 blocks away and came back... to an exploded reactor. These things just explode.
I like what you did with the transposers though
Edit: If at first you don't succeed, try and try again.
So... I've MCEdited this thing into the first world about 5 times now. It explodes every time. Even when I would spawn it in the air... The row of filled buckets stops and then BOOM!
I've seen this thing run once, and it was running, working fine... so, idk wth is going on with it exploding right after MCEditing it in.
Edit 2: Loaded it in a couple times more, this time placing my player directly on top of the device before saving and exiting out of MCEdit... both times the empty buckets weren't being pulled out (noticed the second time... but it exploded before I could find the kill switch or where the empty buckets go.) [but I could see power going to the filter that was supposed to grab them]
I just realized: Rick, did you take the MCEdit copy of it while it was running? I forgot to tell you guys (if you didn't already know) that a lot of the redpower machines get stuck and can't get unstuck if they were copied while they were in the on state. That's part of the reason that all my schematics thus far have had completely unused uranium in them, etc.
Display MoreWouldn't you be able to build the entire thing in a single chuck if you go vertically? Might be it would also be more convenient, since AFAIK it's mostly easier to fit something tall than something wide in a base...
Probably requires more thinking into layout though, arranging everything into floors and suchlike ... But it would be beast
Edit: Chunks always origin at the X/Y axis right? So everything dividable by 16 is a chunk border?
They fit in a chunk pretty easily, actually. Or at least mine does, it's like 5x7x4 or something silly (not counting the bits of red wires outside, retaining walls for water, etc ;)) - could actually be smaller, but I'm using a 3x5 pool of water for my 2 deployers 
