Posts by glasstabels2

Quote from AkhkharuXul

Upon making my "safe" version of this reactor (one that survives chunk loading/unloading) using 2 transposers, 5 filters and 2 deployers... I see that it can't really handle more then 1250 heat [2.5 buckets per second] ... which is odd considering I'm running on a 2 second timer. But I wired mine up more like yours, glasstables. So .. I'm thinking that there might be a difference between direct and indirect power on the filters [cos my extraction filter would jam the system before... I thought that the "fix" was the tube splitting now, to be able to evenly fill 2 depolyers with 1 filter... but then I noticed the slow-down. [Before there would never be more then 2 empty buckets in my reactor]

How many filters are hooked up to the reactor for extraction? I have never gotten the whole 1 filter thing to work out beneficially. That isn't to say that I haven't gotten it to work, but it doesn't work beyond 1250 heat because like I said earlier, the filters still can only take out 2.5 buckets per second. The only difference in increasing the timer is a change in how early the respond to taking out empty buckets, not how many they can actually take out. This improves how many they actually take out, but only to something still slightly below the theoretical perfect due to the way things work out. So without the .2 timer, its even worse, but with a .2 timer its pretty close to the theoretical. Still, with it only ever being able to reach even a theoretical 2.5 buckets per second with only one filter on extraction, you can actually get more EU/t by decreasing the chamber by one, putting another extraction filter on (and pair of deployers to go with it), and just going nuts. I know its so much overkill at that point, but you still get more out of it than you could with just one. Also, overkill is probably better in this case, tbh none of these designs are lacking in amazing amounts of EU/t, but a lot of these designs are lacking in safety and reliability.

Well, I didn't set up nearly enough t flip flops (I think for the future I'm going to just have a chest full of cobble stacks or something, and pull out one at a time, would be a much better counting system). Still, I've been at this minecart test for almost the whole cycle now and... lemme check up on it (gotta get out of the minecart). Still working! I made sure to check every part of the system too, as I know looks can be deceiving if one doesn't check everything. My frequency was about once or twice per minute, so not too much, but we've made a huge leap guys!

Edit: now I finally realize why the IC stuff seemed to get ahead of the RP stuff very slowly. it wasn't the order they loaded in, it has to do with the 2.5 buckets per second only being a theoretical maximum, as in, only if those buckets appear perfectly timed for the extraction stuff to grab, which will obviously not always be the case, even if it is sometimes the case, thus the cooling system loses ground, but very slowly, making it difficult to see at first.

Quote from AkhkharuXul

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

agreed, fitting them into a chunk sizewise isn't much of a problem, its moreso the planning ahead of time (if building this legit) that makes it more difficult, and remembering to keep whatever size you do have inside the same 16 by 16 area, not split. Don't worry about multiple floors, I can't imagine any of these being that complicated, although my automated reloading system looks like it might have to be kinda on its own above the thing (or below it), but thats an additional system to be added later in my mind.

Also, thinking about the rating system: we would still need a way to compare various frequencies and counts of it working, so I would say it should be something like the frequency (per minute) times the percent of counts in and out of the chunk out of how many times one can possibly enter and re-enter within one uranium cycle.

An couple examples of tests of the same reactor might look like:

frequency: 4 (once every 15 seconds)
count: 200 (out of a potential of ~667)

so 4*(200/667)= ~1.2

However another test:

frequency: 2 (once every 30 seconds)
count: full length (~333)

comes out to a rating of 2. This way a perfect count on any frequency equals that frequency. Of course it might be more convenient to measure in time of 100 seconds instead of 60 since it fits better into the uranium cycle, but obviously there's a lot to still sort out. Food for thought though.

Quote from AkhkharuXul

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 More

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.

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.

Quote from Rick

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.

Quote from Rick

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.

Quote from AkhkharuXul

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

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.

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.

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.

Quote from AkhkharuXul

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 More

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

Quote from AkhkharuXul

Idk what all this .2 timer stuff is about. Mine always ran on .2 timers (even with prerelease 2) ... but the deployers don't fill faster then 0.4 anyways cos the water has to replenish.
I still have to finish the reactor I was working on... I got a little carried away and it's a bit convoluted [I discovered glass panels]...
now I just need to figure out how/where to hook up the redstone power

Figured I'd run the filters on 0.2 timers and the deployers on 0.4 just to be safe. [But when I was testing loading/unloading the chunk via distance would cause ~9 empty buckets to bounce back to the buffer chest... not sure if that'll be a problem. Or well, it'll be a problem but only a ... 4 second problem (maybe only a 2 second problem)? Which might be a problem with an 8 second reactor.]

I'll hook some power into my reactor [and then save a backup] then test it out to see what happens. But so far every redpower reactor I've had has exploded.

My filters and transposers have always run on .2 timers, but the actual item empty rate, even on a .2 timer was still .4 seconds for me, as in, there was no advantage. same for deployers, they ran on it, but only because the .2 timer hit at the same time as the .4 when it was ready again .4 seconds later.

I have no idea what rick is talking about, but would love to see it working. I doubt it will on my world though, as my filters can't empty stuff that fast for sure. If they could, this all would be a million times easier.

I assume that whatever rick has is in PR 3, not 3b, and that they will probably not work on .2 again later.

Yes, it is frustrating that they all seem to blow up so far, although we've certainly come a long way. The only thing now is the loading issues, but with a robust enough system we should be able to surmount those. If we can, then these ought to be able to be run as if they were mark I's, as that is how they run without the loading issues. I will try more deployers in my next design and see if that takes out the last of the bottlenecks. I also really hope rick gets back to us on what all this .2 stuff is, as I've been testing a lot to be sure, and it seems that mine definitely still only can respond every .4 seconds.

Rick, just tested filters and umm... what version of RP are you on? I'm on Prerelease 3b, and unless I've installed something incorrectly or something really weird is going on, my filters only respond once every .4 seconds, even with a .2 timer hooked up to them.

Quote from Rick

While messing around with redpower 2 pre3 i noticed machines work properly now when wired to a 0,2 timer. This would mean double cooling capacity. Currently modifying my reactor and testing it out.

Edit: it works it now easily cools http://test.vendaria.net/index…UXUUUUUXUUUUUXXXXXXXXXXXX
use 2 deployers through they dont work as fast as filters/transposers do.

Edit2: Made a new reactor with detector block does require some wiring to make the sensor system automatically turn on after a certain time as you can see in the screenshot here:
http://imageshack.us/photo/my-images/217/20111028014338.png/

So to start the reactor this would be the steps you have to take:
-Load the reactor with uranium
-Hit the lever
-Win

Display More

I see that there's only one transposer/filter involved in extraction, and I was wondering: how does it fare with logging out, leaving the area, etc.? From what I can tell you are cutting it within a one bucket heat range of closeness, although that should be at least decently safe. Please tell me how it goes. Also, if you guys wouldn't mind making schematics or providing world saves, I am a big fan of those, as then I can see it working. Also, if either of you would prefer world saves to mcedit schematics, I can use those instead if you like, its just as easy either way. Personally, whenever I take screenshots I find that it barely captures what I want it to, or what needs to be seen. In addition, I can't play around with it, or add my own adaptations.

Quote from AkhkharuXul

No the buckets is a bug with redpower. I think it's when items a filter sends get bounced back, but the container it's pulling from is full. Then it starts doubling them I think cos it tries to pull a whole stack, but that would be bounced, so gets duped.... it only takes a few seconds to get out of hand and have an extreme amount of duped items. [not sure if it still happens with RP2pr3]

@glasstables2 I have MCEdit, but I only use it to fix corrupt saves. I loaded the schematic up with that but it was just pink blocks, guess I'd have to import it to a world to "see what it looks like"?

Edit:

So I loaded up your reactor to test it. When I turned it on, it would cycle through the first 3 buckets on the top row ... is that correct? Went 300 blocks away; came back and... it only had 2 buckets of water in it, the rest were empty, and it seems like the filter extractors weren't able to keep up as it wasn't gaining more filled buckets (I took a screenshot but it's just like full, empty, empty, full, empty, empty buckets on the top row. So I figured if I repeated the 300 blocks away and coming back [to get the chunk to unload / reload again] that it would blow up... and it did. [Is it because I might not have placed it on a single chunk? --- I really dislike MCEdit so I didn't bother going "where are the chunks at" :)]

Edit2: Maybe you gave the wrong schematic, cos this one doesn't have a buffer chest between the filters (that pull from the reactor) and the deployers. [Made sure to place it inside just one chunk this time... exploded after going away from it and coming back] (it's just the two levers, the one next to the timer to start the cooling system, let it fill up, then the lever to turn on the reactor... right?)

Display More

Well, its possible i gave you the wrong schematic. Also, it seems I have lost it somehow myself by trusting myself in having the most recent version and deleting my world. I am now having the same problem (even though I'd been testing this for hours earlier). However, if RP machines now respond to a .2 timer, I would want to redesign it anyways. Also, it was so incredibly jam-packed that I kinda wanted to redesign it anyways. I have something big and secret as an improvement to reactors as a whole, although our bucket style cooling systems will be the easiest to adapt it to.

Personally, I love MCEdit. Unless you have a touch pad, it is very easy to use, especially once you learn the ropes, and saves tons of time with big structures, as well as with big tests.

It is a bit sad that somehow I took the wrong schematic, but I suppose there isn't much loss. Still, I was looking forward to taking a break from the cooling system (since it looked fine) and working on other improvements. Oh well. Seems there's never any end to troubleshooting sometimes, but this new timer speed should make life a million times easier. I will also be looking forward to the computer things to control reactors in the future, although I don't think it will make our systems particularly obsolete. Also, the emergency system wasn't hard for me to install, though I did have to space things out a tad to get it to fit. It wasn't a big deal though, so I'm sure that if it becomes obsolete it won't be a big deal either. Especially as long as it works.

However, I think that even with the new timer speed I will look into adding more deployers, as that seems to bottleneck whenever chunks are unloaded and reloaded as you pointed out and I just saw myself recently. Deployers are cheap. They may add more space, and my next version may or may not be able to fit so many into a single chunk. In reality though, these reactors we're making burn through uranium more than fast enough for one reactor to be more than enough to keep up with, especially if you tend to go afk or plan on installing this on a server where it will possibly run when you aren't there. I want to make one robust enough to go on a server, although that may or may not be as easy.

Quote from Rick

With the new item detector block the previous safety mechanisms will prolly get obsolete but i gotta make one first

How you get so many buckets lol? Failed hacks?

Ya, the item detector makes things a piece of cake. The nice thing about it is that with any version of this system, all bottlenecks lead to one problem and one problem alone: no filled buckets heading towards the reactor. Therefore an inter-tube item detector is perfect. I was going to attempt it with having the buckets land on a pressure plate before continuing, but this allows me to keep my design just as compact and simple.

As to escape routes and other preventions, I actually am planning on putting a teleporter in mine, and everything should be operable from that teleporter or very near by. If its about to blow, it automatically teleports the user to a safe nearby location whether they want to go or not. As far as saving the nuke, I try to keep the bucket system running in hopes that whatever kink it was will be unkinked once the reactor is shut down. The nice thing about item detector emergency stops is that we can detect when the cooling system has a problem before it actually effects the heat of the reactor. In other words, the length of tubing, even if short, allows the reactor to be shut down while the last of the full buckets (from before there was a problem) are still on their way.

Edit: There is one bottleneck though that does cause the same problem with full buckets not heading out, but not as quickly, which is empty buckets not being extracted as quickly. As such, this is the most dangerous bottleneck because it may stop full buckets from reaching the reactor long before they stop heading out, especially if there is a chest buffer. I don't suggest not using the chest buffer as it helps a lot, but what I would do is have a shut-down detection system on both extraction AND insertion if there is a problem with extraction.

Edit 2: I checked going far away in all directions, multiple times, in increasing intervals of 300 blocks, and have yet to have a problem. Mine has never, ever blown up, and I am now running 64 at a time for greater sample size for testing. Still no problems. To be honest, I would call mine a mark I at this point. I can literally throw lava buckets in and it comes back to its equilibrium within 2 seconds or so. I think that that is proof that it can handle most any situations, and even a griefer who thinks he's funny by throwing lava buckets in lol If you come up with anything else for me to test that may be a problem, let me know. Otherwise, I'll get to working on it legit and a way to use all that energy so it doesn't go to waste. I hate MF'ing without the proper amount of scrap, you wind up using almost 10 times the energy, and since uranium is now a finite resource (since they took out the uu-recipe), I'd rather not waste mine, even in an extremely efficient reactor.

Edit 3: after running 64 at a time for a very short time, I found that the lag was too great to do anything else whatsoever on my computer at all, so I've reduced it to 16. Still, even with that insane amount of lag, it didn't blow up.

You know how the file attatched says v. 2.1? my initial version was very similar to what you just described. It seems to me that using the theoretical 2.5 buckets leaves room for the reactor to get ahead of the cooling system in times of lag, but not the other way around. Also, the full bucket glitch with the filter has been fixed, but that only occurred if the "pressure" was full in one tube, meaning you had a bottleneck somewhere as it was.

If you were using hacked buckets, RP machines AND nukes don't like them, but you can save an inventory of non-hacked buckets in TMI and be fine.

Finally, as to how on earth a schematic is not useful but crappy screenshots of an overcramped, barely visible guts of a machine that you can't see moving, my mind is full of f*ck. If you don't have mcedit yet, GET IT ALREADY. I was actually a bit frustrated that neither of you had schematic files and world saves, as then you can actually SEE WHATS HAPPENING AND TAKE IT APART TO LOOK. Instead, you ask for screenshots of a very compact machine which at no angle can you see even half of whats going on. Nevermind the fact that you're given a still of something moving, and its obviously better to see its dynamic actions rather than static pictures. Get MCEdit, download the schematic, and take your own screenshots if you want them so bad.


Also, if you were using tmi buckets, or other hacked buckets, they won't interact well. However, you can save an inventory of non-hacked items in tmi and it's fine.


Finally, as to how on earth a schematic is not useful but crappy screenshots of an overcramped, barely visible guts of a machine that you can't see moving, my mind is full of f*ck. If you don't have mcedit yet, GET IT ALREADY. I was actually a bit frustrated that neither of you had schematic files and world saves, as then you can actually SEE WHATS HAPPENING AND TAKE IT APART TO LOOK. Instead, you ask for screenshots of a very compact machine which at no angle can you see even half of whats going on. Nevermind the fact that you're given a still of something moving, and its obviously better to see its dynamic actions rather than static pictures. Get MCEdit, download the schematic, and take your own screenshots if you want them so bad.

attatched is a .schematic of my version. i didn't realize other people had been doing this, so its called G.lass's A.lternative C.ooling S.ystem, thus the file name. Mine never ever blows up upon even rigorous unloading and reloading, because it fits entirely in one chunk. in fact, it can fit 4 into one chunk horizontally, and up to 60 if you put them vertically (although that dimension can probably be made slightly more compact). It does 640 EU/t, and can probably do more, but I prefer to leave the buckets in the top just in case. It uses 2 deployers, each with a 2x3 pool in front of them, because after much testing, my personal findings were that deployers can in fact go faster than water if on a .4 timer. It also uses 2 filters emptying the chest, and one tube leading to it from the reservoir chest, which has 2 filters hooked up to it as well. The chest also allows for a large buffer, I don't know if you guys had that. Also, if yours fit exactly into one chunk and still was blowing up with the unloading/reloading thing, it may have been the water. water doesn't reupdate upon reloading, so it needs redstone/redwire powering a block directly next to it. My design already had that, so I never experienced it in the first place, but just something you should check.

There are improvements to be made though. I probably do not need as many transposers sucking out excess as I have running, but I wanted to be sure. The main improvement that could probably be made is to put a delay on the extraction filters, so that the empty buckets are pulled out just before full ones are shoved in, so that they aren't ever in the way, because then they wouldn't be going at the same time. Still I don't see how we'll ever be able to get more than 1250 heat per tick safely working with more than 3 added chambers, as 1 filter can only handle extracting 2.5 buckets per second, and even then, I don't think RP time and IC heat ticks always coincide that perfectly, so it would probably have to be slightly less than 1250 heat to be safe.

Also, I don't know what you guys' systems are like, but reloading mine is a piece of cake thanks to the reservoir in the chest. all you do is put the uranium in, and switch out the second row of water where needed (it will fill up without the uranium in the way). then, put the water back in the system at some point in time, but it doesn't really matter when as long as its before the next cycle. with all the transposers i have running to get the extra buckets, i just throw them in a hole in the glass near them, although in the schematic i gave you I don't remember if the hole is there, or if there's any extra glass. I have two schematics, one with some reinforced glass protecting things just in case, and the other with it stripped away. I don't know quite how robust you guys' are, but mine is good enough to handle random items being thrown in the reservoir accidentally, along with buckets of lava about every couple seconds. You can know when its fully ready for another bucket of lava when the three buckets of water reappear full in the top right corner. If you do throw lava in for shits and giggles though, make sure to leave the bucket of water you get from it in your inventory, as throwing too many in can add up over time to too much being in the system.

With allocators, it should be possible to make it much faster, as allocators can fire up to 5 time per second (more using the torch trick). I don't know if the torch trick can be used though because it would probably shut down the reactor. Still, that would amount to quite the improvemet per missing chamber, and would basically double the potential heat.

Edit: be sure to turn on the cooling system (switch at the bottom) before turning on the reactor. Also, here's the layout inside if you're too lazy to use the schematic: http://test.vendaria.net/index…UXUUUUUXXXXXXXXXXXXXXXXXX
Also, I've been testing with the top row partially full of uranium. so far, 3 has blown up upon rigorous loading and unloading. I may continue testing 2 and 1 (if 2 doesn't work), but I'd rather leave it be for now, because its already at a very convenient 640 EU/t, which is exactly 1 high voltage + 1 medium. (512+128).