Getting a CASUC above 6000 heat automatically...possible?

Yes, it is possible. Though it's /annoying/.

As we've already demonstrated in other threads, ice cooling is bloody expensive; a CASUC breeder probably can't sustain ice-cooling for it's self. (The power eff is 1, but the heat eff is 5).

Therefore you need to build what I explored in the later part of my CARUC thread, and what I'll likely do next in IC2 while waiting to find out if I need to abandon it until the new year, or if I should tough it out through the weeks till Xmas and a hopeful, at least partial, release that's 1.0.0 compat.

The breeder should be designed to produce some multiple of 250 in heat every (stable time, short interval) seconds. You'll want an RP2 timer or l33t level normal redstone timer delivery buckets at /precisely/ the correct interval to keep it balanced. You're threading a needle between 9000 and ~9800 (it can get a bit hotter without damaging surrounding equipment, but not much and THAT hurts you too). The new 250 buckets actually /help/ in this aspect since it's now far easier to deliver a /measured/ burst of cooling instead of doing it every N seconds.

I need to re-explore the design for this...

I'm thinking an auxiliary chest with 3 lava buckets in it, and a transposer that pulls them out and injects them into your cooling loop at the beginning of a cycle. Use a timer or item detector/counter to start the reactor when it's ready.

I'm thinking about something similar for my breeder... I have a buffer chest that stores full buckets before they're sent to the reactor, and if I use a transposer instead of a filter (a bit more dangerous if "foreign objects" get into the chest) I can just put lava buckets in the first 5 slots and delay the reactor start an additional 5 seconds. It's neutral heat when there are depleted cells in it, so it would put it up to 10k, wait for an additional 3 water buckets to get it down to 9250, then start the reactor.

Quote from BrickedKeyboard

Well there is one thing that will help : the energy shields addon is now stable enough that it could be used to protect your base from the explosion when your cooling system misses a bucket.

What's wrong with Reinforced stone?

Quote from Cadde

What's wrong with Reinforced stone?

expencive, and not particularly durable to serious explosions (need 3 layers, that takes a LOT of resources)

So does building a reactor X_X I honestly don't bother doing this sortof stuff but now that ice cooling is better than water buckets I've found a system (I've only done small scale tests and non CASUC reactor designs) regardless how big the factory may be(BC teleport pipes hint hint wink wink) if you have enough resources most any reactor design is possible.

Quote from Ranakastrasz

expencive, and not particularly durable to serious explosions (need 3 layers, that takes a LOT of resources)

It is expensive for a reason... even though nuclear reactors doesn't produce nearly as many EU's as i would expect them too.
I see reinforced stone as part of the reactor itself, without it you are at the mercy of the reactors habits of making holes in your base. The same way, without cooling or a shutoff system, a MK V reactor is going to be very expensive to operate as you have to rebuild it every minute or so.

Quote from BrickedKeyboard

Plus, on my server I see no reason for an arbitrary maximum explosion cap

Please... I don't mean to offend you but rather point something out that i feel is odd with that logic.

E=MC² and Each action has an equal and opposite reaction.

Point is, if one is to use energy to shield against a nuclear explosion you need equally as much energy in the shield as the energy produced in the explosion. (At least that's how i think of it)
So a shield should use more energy than the reactor itself to contain the blast. Leaving the shield up constantly means you are losing power to run the containment.

Reinforced stone is using resources that has accumulated energy in them. (hard materials are just that, natural diamonds take millions of years to form?)
When making reinforced stone you abuse this slow process to your advantage. If you configured your reactors on your server to explode more violently you increased the number of resources needed to contain the blast.
Aren't you cheating yourself then by using shields to contain the blast (shields being cheaper to make than a reinforced stone containment?)

I just finished construction on the CASUC breeder in my new Evil Lair, and I'm happy to report that the automated startup procedure works perfectly.

You just put 5 lava buckets and three or four water buckets in the buffer chest (lava has to be in the first 5 slots). When you turn on the cooling system, there's a timer/RS NOR combination that allows the first eight buckets to cycle through the reactor, then automatically starts it. It pegged the heat at 9270, and it hasn't budged yet.

Control room (no ceiling yet because the main CASUC reactor will be stacked on top, so both reactors and the controls are in the same chunk):

Reactor:

I've finished adjusting my own version of a CASUC auto-start perfect breeder on MJEvan's server (IC2+RP2 1.8.1):

http://www.talonfiremage.pwp.b…h=1a161010111010101001019

PICS:

It looks a bit ugly, but I was kinda just working around where the reactor was already placed (Yay for RP2 bundled cables).

It features an automatic emergency shutdown system (which has already prevented one explosion when the wire to the water injector got broken accidentally). After the shutoff trips (either from a problem or the end of a cycle), pistons open to increase the external cooling, so the reactor can cool down on its own between cycles, despite the 20 isotopes still giving off heat.

The redstone stuff does require that the reactor be at 'zero' heat when it's started, but since there are no heatsinks inside, it'll usually be completely cool again just from the time it takes to swap out cells between cycles.

The nifty part (at least I think so ) is that all the redstone controls have been condensed into just 2 manual inputs: the on/off switch, and a reset button (which only works while the reactor is off). When you push the reset button, it resets the RS latch to stop the clocks (which feed the shutoff and startup counters), resets the startup counter, and resets the shutoff counter via a 0.2s clock and another RS latch. Then, when you switch the reactor on, the clocks start, the counters start ticking, and the CASUC system waits 36 seconds to start injecting buckets, leaving the reactor running stable at 9520 (higher temp allows some wiggle room for when isotopes finish somewhat unevenly).

This is all contained within a single chunk, with plenty of room to spare. It could be made prettier, but it works beautifully as an easy-to-use, set-and-forget, maximum-efficiency breeder.

I'm quite glad you were able to fit that inside of that test chamber. The area he built it in is a 16x16x15 high (the floor already had a layer which would have been a pain to remove) chunk which has 3 thick Re-Enforced Stone walls and a semi-complex zix-zag entrance to prevent any explosions from escaping. The entire setup could probably be condensed in to half a chunk. Since I didn't do the work you'd have to ask Chronophaser if he's interested in sharing a .schematic of this. However this is effectively a small divergence of the breeder I was planning (I had planned to just keep it hot, stop bucket flow+reactions and automate swapping the enriched uranium cells /quickly/ but that needs RP4 stuff so I'd been holding off for 1.0.0 compat IC2).

I see people are using timers to clock their reactors. Please be careful when doing so since timers are not world synchronized!
For anything that is re-occuring you should be using sequencers (they ARE synced to world time) to prevent any random de-sync which could cause a lot of problems further down the line.

This problem with timers especially shines through when you have them set to a short delay as each re-start of the timer, that is 0, has a chance of this de-sync happening.

well the problem with sequencers is that they tend to be difficult to exactly sync with the reactor tick because there is no way of stopping them temporarily once placed to my knowledge (hoping I'm wrong).

I hear you with the timers though. Personally, I prefer to use a item detector. In case you guys didn't know, RP tubes take exactly 8 redstone ticks from my testing, so you can time your reactor based on that. In good breeders, it may matter to know exactly when the reactor tick happens, and from my testing it should be possible to change out the isotope cells the exact tick they get charged, so that there is no down time. I still have to test though to see if that works with lag. Not sure as to the best way to test it yet.

Anyways, I made a quick post (still a ton more info to put in the thread yet) about what I've done here, and a serious bug with breeders: http://forum.industrial-craft.…page=Thread&threadID=3319

I have yet to put a lot of info, screenshots, explanations, etc. in there, but I will update it when I have the time. take a look though.

No, you cannot stop and start sequencers but you can adjust their timings by using a repeater. (and a pulser after the repeater if need be)
Obviously, adjusting the repeater to cover more ticks than the sequencer is counter productive.

But it is very much possible to sync it with the reactor (if you know some redwire fu) and then you have solved the issue with timers.
And if you want to turn off the output from a sequencer (simulating the function of a timer) then simply add an AND gate after the pulser.
Each gate adds a delay of one redstone tick (that's 2 game ticks) but you already knew that... Just saying in case.

Quote from Cadde

No, you cannot stop and start sequencers but you can adjust their timings by using a repeater. (and a pulser after the repeater if need be)
Obviously, adjusting the repeater to cover more ticks than the sequencer is counter productive.

But it is very much possible to sync it with the reactor (if you know some redwire fu) and then you have solved the issue with timers.
And if you want to turn off the output from a sequencer (simulating the function of a timer) then simply add an AND gate after the pulser.
Each gate adds a delay of one redstone tick (that's 2 game ticks) but you already knew that... Just saying in case.

well i did already know all of that, but I was really hoping you could turn them fully off. I know you can use an and gate (though I would have gone with a multiplexer), but tbh I find it very annoying to have to put varying amounts of repeaters on varying times each time I build a new reactor, and it makes it slightly more difficult to test whether it actually is synced perfectly. Possible, just annoying. I am lazy though haha. And my pretend ocd likes things to work the same every time.

speaking of solutions though, I suppose my item detector may be susceptible, I haven't properly tested it yet. If it does fail the test, I can always use the sequencer. I think I might just do that from now on.

Of course I'll always be waiting for eloraam to just synch timers to the world time, but if she hasn't done that yet, she probably won't ever I don't think.

I don't think timers where ever meant to be used as system critical components like that. They are a "lazy mans answer" to a problem.
Sequencers work with

if (worldTime % Interval) == 0;
And is checked once every game tick.

Timers with

internalTicker++; If (internalTicker >= interval) { internalTicker = 0; sendPulse(); }

And timers have an update interval that isn't once every tick but once every redstone tick or more. Hence the de-sync issues.

Quote from Cadde

I don't think timers where ever meant to be used as system critical components like that. They are a "lazy mans answer" to a problem.
Sequencers work with

if (worldTime % Interval) == 0;
And is checked once every game tick.

Timers with

internalTicker++; If (internalTicker >= interval) { internalTicker = 0; sendPulse(); }

And timers have an update interval that isn't once every tick but once every redstone tick or more. Hence the de-sync issues.

Display More

good to know, thanks. now, does that mean (and i think it does) that a sequencer with a time of 1 second (10 redstone ticks) will always have one side that is exactly synced with the reactor? or does that only mean that each of the sides will always be on one of the same 10 redstone ticks per reactor tick?

Becasuse world time returns a number for every 10 redstone ticks, right? I do know a decent bit of java, but have to admit i haven't looked at the code for MC or the mods much.

Anyways, if the worldtime does return "seconds" so to speak, then couldn't you just have a sequencer set to 4 seconds with a pulse limiter/monostable (i prefer to use counters which reset themselves because they are more useful later in other projects since you can't uncraft circuits) on each side? then connect the other end of all the monostables and ta-da! it pulses every second exactly one tick after the reactor tick, and will work no matter what even if mcedited, picked up and put down, etc., and won't be side-dependant.

but of course that all depends on your answer to my earlier question.

Quote from glasstabels2

good to know, thanks. now, does that mean (and i think it does) that a sequencer with a time of 1 second (10 redstone ticks) will always have one side that is exactly synced with the reactor? or does that only mean that each of the sides will always be on one of the same 10 redstone ticks per reactor tick?

Becasuse world time returns a number for every 10 redstone ticks, right? I do know a decent bit of java, but have to admit i haven't looked at the code for MC or the mods much.

Anyways, if the worldtime does return "seconds" so to speak, then couldn't you just have a sequencer set to 4 seconds with a pulse limiter/monostable (i prefer to use counters which reset themselves because they are more useful later in other projects since you can't uncraft circuits) on each side? then connect the other end of all the monostables and ta-da! it pulses every second exactly one tick after the reactor tick, and will work no matter what even if mcedited, picked up and put down, etc., and won't be side-dependant.

but of course that all depends on your answer to my earlier question.

Display More

worldTime is the number of game ticks that has elapsed since the start of the world. Which happens to be 20 each second. (0.05 seconds)
A redstone tick happens every other tick (to allow for other updates to happen between redstone ticks, otherwise redstone intensive stuff would really bog the game down. (A mod was made a long time ago that made redstone operate on each game tick. Which not only made the game very sluggish but also caused a lot of issues with redstone torches etc. Either way it's besides the point.

It is important to know that any RedPower component set to a .05th of a second will run one cycle .05 seconds early/late and the next late/early. With a timer that makes the issue even worse since it needs to reset. Running it at 250 ms intervals means it will "tick" once at say 300 ms and once at 500 ms since it's first activation. A sequencer on the other hand will not have this problem, instead it will be set to "EmitSignal = 1, 2, 3 or 4" for each side (I made that up now) in a half redstone tick and the redstone will activate 50 ms late on odd cycles. But since it never needs to reset itself as it is synced to world time it never experiences any of the desyncing issues.

To answer your question(s) in short:

* worldTime is the number of GAME ticks elapsed since map creation. That starts the very moment you click "create world" in the menu and it starts generating the new world. To get Seconds from map start you take worldTime / 20. To get Hours, Minutes and Seconds since world time you do the same kind of math, for instance, minutes would be ((worldTime / 20) % 60) and so on.

* worldTime doesn't return seconds, it returns 50ms intervals passed since map creation. But that isn't the entire truth. If you suffer an FPS that is lower than 20 FPS at ANY stage in the game then your real life second just turned into a fraction of a minecraft second. Hence why, if you start a new world and start a stopwatch at the same time. Then set off a bunch of TNT til your PC lags and pick up the blocks. Your in game statistics will show a time elapsed that differs from your stopwatch.
That is also why making real life clocks (that is a clock that is synced with real life) is really hard. There is always the odd game tick that is "skipped" for whatever reason. (or as they say, late)

* A sequencer set to 1 second with a pulser on each side of it will pulse exactly once per second on the wire around it. (Every 10 redstone ticks)

...

Now i will have to look at the IC2 source... *sigh*

updateTicker = randomizer.nextInt(tickRate());

That will be your BIGGEST problem. So i was slightly wrong in that the reactor uses worldTime but still, timers are NOT to be trusted.
And what really happens with Timers isn't that they de-sync. It's that they sync, it is irrelevant to the problem at hand but i strive to be correct whenever i can. You can observe the same effects with BuildCrafts Redstone engines. Even if you start them with a 1 tick delay between each of them they will sync up with each other when they turn red. That's just the way things work and to find out exactly what is going on behind the scenes i would have to read a lot more source code. (And I'm not going to be doing that, i know Timers suffer from the issue but sequencers don't)

OK, before i finish this post off. The above random.nextInt(tickRate()); means that reactors will pick a random tick (between 0 and 19) on which to run on. That updateTicker is increased each game tick by one. So you need to figure out which of the 20 different game ticks the reactor is using no matter if you are using timers or sequencers. Build one and sync your machines to it, then remove the reactor and build it again and you will notice that it isn't in sync with your machines anymore. (20 BPS doesn't sound so bad anymore does it? )

Oh well, i am tired. I am sure that, with the information given, you will be able to find a way to make it work.

Quote from Cadde

worldTime is the number of game ticks that has elapsed since the start of the world. Which happens to be 20 each second. (0.05 seconds)
A redstone tick happens every other tick (to allow for other updates to happen between redstone ticks, otherwise redstone intensive stuff would really bog the game down. (A mod was made a long time ago that made redstone operate on each game tick. Which not only made the game very sluggish but also caused a lot of issues with redstone torches etc. Either way it's besides the point.

It is important to know that any RedPower component set to a .05th of a second will run one cycle .05 seconds early/late and the next late/early. With a timer that makes the issue even worse since it needs to reset. Running it at 250 ms intervals means it will "tick" once at say 300 ms and once at 500 ms since it's first activation. A sequencer on the other hand will not have this problem, instead it will be set to "EmitSignal = 1, 2, 3 or 4" for each side (I made that up now) in a half redstone tick and the redstone will activate 50 ms late on odd cycles. But since it never needs to reset itself as it is synced to world time it never experiences any of the desyncing issues.

To answer your question(s) in short:

* worldTime is the number of GAME ticks elapsed since map creation. That starts the very moment you click "create world" in the menu and it starts generating the new world. To get Seconds from map start you take worldTime / 20. To get Hours, Minutes and Seconds since world time you do the same kind of math, for instance, minutes would be ((worldTime / 20) % 60) and so on.

* worldTime doesn't return seconds, it returns 50ms intervals passed since map creation. But that isn't the entire truth. If you suffer an FPS that is lower than 20 FPS at ANY stage in the game then your real life second just turned into a fraction of a minecraft second. Hence why, if you start a new world and start a stopwatch at the same time. Then set off a bunch of TNT til your PC lags and pick up the blocks. Your in game statistics will show a time elapsed that differs from your stopwatch.
That is also why making real life clocks (that is a clock that is synced with real life) is really hard. There is always the odd game tick that is "skipped" for whatever reason. (or as they say, late)

* A sequencer set to 1 second with a pulser on each side of it will pulse exactly once per second on the wire around it. (Every 10 redstone ticks)

...

Now i will have to look at the IC2 source... *sigh*

Code

updateTicker = randomizer.nextInt(tickRate());

That will be your BIGGEST problem. So i was slightly wrong in that the reactor uses worldTime but still, timers are NOT to be trusted.
And what really happens with Timers isn't that they de-sync. It's that they sync, it is irrelevant to the problem at hand but i strive to be correct whenever i can. You can observe the same effects with BuildCrafts Redstone engines. Even if you start them with a 1 tick delay between each of them they will sync up with each other when they turn red. That's just the way things work and to find out exactly what is going on behind the scenes i would have to read a lot more source code. (And I'm not going to be doing that, i know Timers suffer from the issue but sequencers don't)

OK, before i finish this post off. The above random.nextInt(tickRate()); means that reactors will pick a random tick (between 0 and 19) on which to run on. That updateTicker is increased each game tick by one. So you need to figure out which of the 20 different game ticks the reactor is using no matter if you are using timers or sequencers. Build one and sync your machines to it, then remove the reactor and build it again and you will notice that it isn't in sync with your machines anymore. (20 BPS doesn't sound so bad anymore does it? )

Oh well, i am tired. I am sure that, with the information given, you will be able to find a way to make it work.

Display More

Ya you could've skipped a lot of the explanation there bud, I know a lot of how the ticks work, just not which worldtick described.

That aside, I see the problem. In fact, if it can be any of the 20 game ticks per second, then a sequencer and normal redstone in general could potentially be off by a single game tick, which could be a problem for me. I may have to use pistons to power things, just to get them to be on a game tick which is not a redstone tick... I'm surprised that the reactor ticks aren't necessarily in sync with the redstone ticks, but oh well. I think the easiest thing to do would actually be to sync the reactor, which would be pretty easy with 20 retrievers and some piston wiring, only thing is to keep it in one chunk so it doesn't resync crossing the border as things are wont to do. However, if it doesn't work give me a retriever which is on a game tick, I think I'd just replace the reactor till I got a redstone tick. Not sure what the best thing to do on SMP would be...

The trouble isn't so much with normal CASUC reactors, because (as you know and have shown), you can always just cram way more than are supposed to go in, and you'll be fine, but with breeder CASUC reactors, which need more precision. Of course, it still should work just fine without the reactor being perfectly synced, but it might be a bit more annoying to manage, and won't allow for the uranium to be changed out the instant it decays like I'd prefer to do. If it has to be a game tick behind though, so be it. If I can do it the instant it decays though, I'm hoping I can do it without stopping the reactor for a second every time I have to change the isotopes out.

Ugh. I really have no idea how I might build this on SMP practically speaking though without potentially using some piston powered wires to get it on a game tick, instead of a redstone tick. And are you sure RP stuff emits the signal alternating every other pulse like that (the late/early, early/late stuff)? Because I've already made a test using retrievers to sync the reactor, and when I use a piston to power 2 different rows of repeaters, you can tell that one fires just before the other, but it definitely isn't a full redstone tick later either because it is still visibly faster than a 3rd row which I set up which is a full redstone tick later.

Also, I've set up a timer in the past using 2 RP timers on the same line of redstone dust, and having one timer be turned on from piston timing (if you didn't know, when pistons connect wires, they take 3 game ticks to connect the signal, but have an instant disconnect), and the line definitely goes on every game tick, and tries to go off, but it isn't visible because the duration of both the timers' pulses is still 2 game ticks, so it is only ever off instantaneously. I was sure that it was going off because you could tell if you connected a door or other output. If I managed a pulse limiter that only sent a pulse for a game tick though, I'm sure it would go on and off every single redstone tick. I do remember it syncing back up to normal redstone ticks though once I unloaded and reloaded the chunk or world.

But based on my testing, I'm pretty sure that while the pulse length remains 2 game ticks, I'm sure they can be offset. They will reset whenever they get the chance (crossing a chunk border and the like), but they will stay as long as they don't cross the chunk border or otherwise become loaded and unloaded, meaning a single piston ought to be able to sync a sequencer to a reactor's tick, even if the server's reactor tick (which is unlikely to get changed) is stuck on a non-redstone game tick.