Lols, I almost made a suggestion to Red Power that was already implemented. This may be helpful to some of you working on your RP Reactor systems. If you didn't know already, you can place redpower wires on machines with inventories using shift+right-click to place. Will probably help with wiring nightmares.
Posts by AkhkharuXul
-
-
I recently found out that transposers can take a seemingly infinite amount of items from the air in one pulse. This doesn't allow for any more speed in empty buckets being taken out, but helps a ton with my refill stuff, and wiring what was becoming a complicated and jam packed area. I have reduced my transposers to 1 now, and reduced the amount of time it takes for buckets to get from the transposer to the buffer chest to 0, improving my design greatly. I'll post it when I have the rest of the refilling stuff figured out, but figured you guys could benefit from the information, as it might be a little while before I get the rest of the refilling stuff figured out. If everything goes as planned it will be out tonight, but to be realistic it will probably be tomorrow, especially since I'm trying to get it to fit in one chunk as well.
Yeah, I noticed this as well (on accident when trying to use a transposer to suck up buckets that could land on a tube, and it would pull all (if not most -because of placement) of the buckets that were spit out of the reactor. My system still ran 2 but one was really just a unpowered failsafe one. *confused look @ problems trying to get it to fit into one chunk*
I'm still a bit annoyed about the slowdown going from pr2 to pr3b
It's like, you can add a second filter to pull... which increases the cooling to 5 buckets / sec... I'm tempted to fool around with Zeldo's advanced wooded pipe, but that would cause even more problems as the redstone engines would always have to be hot. [And I'm not sure what the max speed on redstone engines is...] If I use just buildcraft for the cooling system and redpower to fill buckets... I could go up to 5 chambers on the reactor.... [Then again I could pretend the RP machines can be connected to buildcraft pipes by using an obsidian pipe next to the RP machine? :)] -
If you're looking for a Mark 1: http://www.talonfiremage.pwp.b…uy=1o10101001501521s1r11r
As far as Mark 2, not sure how much efficiency you can get from a 2-4 chamber reactor.
-
I know what mcedit can do to redstone and lights so you always have to put some redstone torches and/or lights to update the blocks so they work normally. Through in complicated redstone circuits this can be a problem sometimes. Also dont forget to put it in 1 chunk i forgot that the first time and now I got another nice hole in my test world and destroyed that pesky npc village.
As for the classification part i dunno how you want to test it in a less time consuming way. I tested mine about 20 times and if i look to what it should do in theory it should never ever blow up so if we are going to make such classification there should be a cap at which it will be declared failsafe. But it will still take lots of time.
Also if a filter is wired to a 0.4 sec timer it can only cool 1250 max per tick. This is just simple maths since 0.4 sec means 2.5 buckets per second and each bucket cools 500 heat so 500*2,5=1250.
Lols I think we need to get some of the quirky behavior out of them before we start classifying them. Cos my filter on a 0.2 second timer is still only cooling 1250 (so I have to assume it's only pulling 2.5 buckets / second).
[Apparently it was a RP2pr2 vs RP2pr3b, they're just slower now (0.4 seconds)... or it's due to my lack of overflow loop but idk how that would affect it [other then it could cause filled buckets to jump out of the filter instead of the reactor :P] -
Quote
personally I wouldn't worry about 1 filter designs, simply because of all that theoretical stuff, but in addition because even if they ran at the theoretical maximum, the extra chamber you gain does you no good because you can only handle 1250 heat. The only way I can think of to increase it further would be to have overheated redstone engines on a wooden pipe, and use the pipe for both extraction and insertion, but without a filter on the wooden pipe, it would be near impossible to get working and keep working, as it would pull out the wrong buckets all the time, and be really unstable. Of course there's probably a mod that has wooden filter pipes, but none popular for SMP servers that I know of, and I want this to be possible for more than a few people, and on the server I play on.
Edit: also, I found that each filter/deployer system does much better if there is an extra deployer for each filter, but it doesn't actually complicate it much or make it much bigger because of how they can share water troughs.
Idk what you mean by theoretical maximum. My first CASUC reactor ran stable at 1500 heat... for ~3/4 of a cycle before I said "ok, enough baby-sitting this thing, the only way it'll break if there's some distance-based chunk loading issue" ... So I tested, and it exploded, and I said "Yepp, I thought that might happen."
[Though that cooling system was just 1 filter, 1 deployer and 1 transposer. (and may have occupied more then 1 chunk, cos I didn't even think to try to line it up with one and was built legit. And blew up my entire world :()] -
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.
One. [The other four just move filled buckets around like your system. Like I said it's limited to 2.5 buckets per second using a similar wiring method to yours. So 1250 heat cap.] It's a 4-chamber reactor I was able to get it to handle this much Uranium:
http://www.talonfiremage.pwp.b…yc=1210101011301521s1r11r
[But didn't feel safe enough to try to unload/load the chunk in that state]Ed: Um, as far as loading times and such, I know before my filter would extract faster... making it fill the deployer and then bounce the empties back into the reactor... causing the reactor to not be able to take in full buckets... then BOOM! [least I expect that's what happened considering I was able to reproduce the results with non-reactor tests; as well as by the amount of empty buckets I found in the crater] -- I should test if 1 filter feeding 2 deployers would fix the situation. Cos it might [or would at least give twice the storage before catastrophic failure].
-
Oh, wow. That would be /very bad/. So if the number of non-'fresh'-uranium cells is greater than the inherent cooling of the reactor, redstone cooling periods will not help. Additionally a previously hot reactor that completes with the same situation will continue to heat up...
Yeah I noticed that bit before your planner got revamped cos I was like "why did it go to really weird numbers" then realized I had more isotopes then passive cooling.
Would be a way to grief people in SMP, just load up their reactor with nearly-depleted uranium cells -
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]
-
Display More
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?
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
-
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] -
Display More
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.
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
-
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.htmlNow 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]
-
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.
-
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).
-
Use 3x2 water and put the deployer in the middle so it can suck up 2 water source blocks instead of 1.
Yepp I think he was already doing that, I use 3x3 to try to get the water to replenish faster (not sure if it does or not)... then ran 2 deployers on 3x5 water
btw, the last 2 reactors of mine had 3 rows of water and 3 rows of uranium and still exploded...
-
Guess what, it blew up.
@glasstables: I ran a filter (sucking just empty buckets) on 0.2 seconds and it instantly jammed a deployer that was on the same 0.2 sec circuit. Because the depolyer would have to wait for water. So I assume that the filter was faster [which is why I haven't gone to 2 filters on the reactor yet]. I think the real problem is that RP and IC load/unload at different times or something.... I just know that I can make a system that run flawlessly as long as it's in a loaded zone (pretty easily too), but anytime I leave/re-enter the zone it'll explode (well your schematic was the best so far, in it did load once.. but then was unable to withdraw the extra empty buckets from the reactor). So it definitely must be that the filter stops pulling buckets... causing the reactor to over-heat and explode. Tempted to try an allocator for the withdraw to see if that makes a difference (but it would require installing yet another mod) [Or I could just use a detector kill switch].I'm tempted to cheat and just put one of zeldo's teleport pipes near the reactor so that the chunk always stays active
(I know player once mentioned is_simulating.. vs is_loaded so ... idk if that has anything to do with it, I'd actually have to look at what happens when a chunk loads... but I'm not going to do that. [And it's odd that (well for me anyways) it's only loading/unloading that occurs from distance, as I was able to logout/login several times and never had a problem that way] -
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 ever .4 seconds, even with a .2 timer hooked up to them.
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 powerFigured 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.
-
So, can anyone remind me why we cant macerate charcoal? How is this much different from growing diamonds via charcoal dust?
Cos you'd only need 1 stack of wood (64 items) to make a diamond? Vs ... ~3600 items through the scrap process?
... Don't complain too much of they might take diamonds off the list of possible scrapbox items -
So what would be a case where wiring together multiple devices increases the EU/s cable required?
More specifically, could I have an unlimited number of MSFUs feeding into a single glass cable, where the EU/t transfered could reach infinity while not causing the glass fibre to overload?
Correct, though, obviously the number wouldn't be unlimited and wouldn't approach infinity on the power output (as I'm sure your computer probably couldn't handle the load and melt down first). Not to mention the logistics of trying to connect that many MFSUs to a single glass cable.
But the cable used, just has to be able to support the highest output amongst all devices connected to it. So the only way to fry a glass cable is to hook it up to the high-voltage side of a HVT, or connect it to a single nuclear reactor that produces more then 512 EU/t.
-
That's great, however you could make your targeted material, the diamond, out of a trickle of power and 544 scrap fed to a massfab. Though if the 1 in 25 rate for scrapboxes is correct that's would be more efficient at 225 (on average) plus lots of random junk as a bonus.
Someone tested the chances on scrapboxes, I think it was 2% for most items (including diamonds)... so that would make it ~ 1 in 50 not 1 in 25.
QuoteI used it to feed like 20 recyclers and a autocrafting table so the scrap got turned to scrap boxes automatically. Now i have redpower i think you can use the scrapboxes with deployers. Then ad a sorting system and voila a fully automatic cactus to diamond and other stuff converter
You can have dispensers "use" scrapboxes (to get the item out) [since IC2 1.15 I think]. So just IC2 + BC gets you to automatic scrap-plants
