Posts by glasstabels2

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.

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 Cadde

The site you are using for your reactor calculations is outdated. Just be aware of that, three things have changed since that was last updated (AFAIK) and that is Buckets now cool 250, not 500. Ice now cools 400, not 200 and the reactor outputs 2x the energy.

I knew all that, I only used that because its the only app i can use from my ipad. I mainly use it just for visualization. I have very, very limited computer access, so most of my posts are done from my ipad, and very little of my work is actually done in MC, but is planning.

But ya, I knew all that, all this still applies. Look at my post and you can see I plan on using 2.5 buckets per second for a 625 heat reactor.

There is one thing though, I was pretty sure that ice cooled 300, not 400 now. Not sure though. But ya, the only reason I use that is because I'm stuck on an ipad. It kinda sucks, but as soon as I get on the computer next I'll show you guys what I have already made. Might be a day or two though, it really is that bad.

Edit: also, ice doesn't really apply to me, simply because I don't like the ice reactors because of the massive set-ups of compressors required and/or having to hack the items in. They make for something cool to look at, but aren't very practical in a legit world compared to bucket CASUC reactors.

Quote from Cadde

I have made a video demonstrating it, i made it for some other guy so i might talk about things specific to the thread where it was first posted.

http://www.youtube.com/watch?v=9SQCc3N71FM

EDIT: Some explanations are probably in order. The "links" (those things that draw 1 EU and 12 EU) are a BC->IC2 conversion addon by the modder Power Crystals.
I am using Additional Pipes for BC 2.2.5 which is important to be able to only extract empty buckets.
It is a overflow loop system, any buckets that can't fit into the reactor core will get dropped at the reactor surface and sucked up by the obsidian pipe.

The reason i am using that particular IC->BC energy conversion mod is because those links allow sending energy once every tick (that's 20 BPS maximum) unlike BC's engines which will send power at most every 0.65 seconds (13 ticks) and that is what makes the whole thing work.
There are other power conversion mods that add engines that cycle fast enough for an 8 BPS system using a engine but those engines draw OMGWTF amounts of power.

Display More

Haha right as I posted I thought about the additional pipes solution from a while back.

I know how that works, even though I took a long break I did do a lot of CASUC work right when they were starting up. I was thinking you were using redpower only. My bad. I always forget about additional pipes. Not that it isn't a cool mod or anything, but I don't use it, so I forget that it is a possibility. btw, if you didn't know, I actually did work on a CASUC reactor way back with allocators, though I never got it to work and stopped when i found out that allocators don't work in SMP, because I like my reactors to work on my favorite servers.

Cool idea using the energy converter for more consistent application of power, though what you would need 20 BPS for I have no idea haha. I like the redundancy in your system making it safe though.

Here, have an internet!

Edit: I noticed you had an issue with lag thanks to the way the obsidian pipe sucks the excess up. You might try a single transposer firing once every second, or half a second, because it sucks up everything all in the same tick, which should significantly reduce your lag I think.

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.

Quote from Cadde

We already kinda have in inofficial system in place.

I call mine a 1740 8 BPS CASUC (1740 EU/t, 8 buckets per second CASUC)
Mark rating is irrelevant for CASUC designs these days. So is efficiency since most of them have around 4 eff anyways. (Thus they get the EA rating)

For ice CASUCS that would be 1820 6 IPS CASUC (1820 EU/t, 6 ice per second CASUC)

EDIT: Changed that 64 ice per second down to 7 since 64 is just overflow.
EDIT #2: Had one chamber too many on the ice CASUC... Numbers have once more been updated for correctness...

Display More

Umm, just wondering but how on earth did you make a 1740 EU/t, 8 BPS design before you were able to use RP retrievers? Just wondering... I'm just getting back into this. Still, that doesn't make any sense unless you were a beta tester of the latest IC version and had before the rest of us or something, because I can't think of any way to make a 1740 EU/t, 8 BPS reactor without 5 chambers, meaning you would need the insertion and extraction point to be one and the same. Am I missing something from being away so long?

I plan on never letting the reactor heat up or cool down while it isn't running, and just having it maintain the same heat the whole time. That way I never have to supply more lava buckets. I also plan on using pistons to control the air blocks around it so it can either slowly heat or slowly cool as necessary. Otherwise, I plan on having 3 lava blocks, 4 fire blocks (on netherack), and otherwise only solid blocks surrounding the reactor. I do not plan on using the fact that transposers and the like can fire about 2.5 times per second, because I plan on syncing the machine to the reactor so I can replace the uranium at very specific times. It should just make life easier to have 3 transposers emptying buffer chests at 1 time per second, with the 3rd transposer being controlled by a flip flop (well, actually I used a self-resetting counter so I can avoid making a pulse former on the end of the t-flip flop). Anyways, their output will be put in the air in front of one final transposer, in order to suck them up all at the same time.

I also plan on just having 3 retrievers run as long as the reactor is on, or even constantly, as they only appear to use up power when they actually pull something, not just from dry firing.

The main problem is the uranium management. Before I found out about the fact that they don't finish at the same time despite having the same number of uranium contacting them and (obviously) the same hull heat, I had been planning on changing them at fixed intervals as they finished, but now it appears I will need to make an attempt constantly, every reactor tick. This may be a bit more difficult, and makes it particularly hard to calculate the actual output of the breeder, as there will be many partials when the uranium is changed.

Which brings me to the other issue I have with them finishing at varying times. Initially, I had planned on having the finished isotopes stay in on the final tick of the uranium, so I could extract the decayed uranium and insert new ones, using the isotopes as placeholders. Now, that may be impossible, we'll see.

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.

Well, a long time ago I was talking about an automated breeder, and was mostly done with one before alblaka had even finished the whole invalid reactor slots thing.

Now that retrievers are here, I had started working on one in 1.8.1 again (today was my first day back working on it in a long time), and wanted to test something.

Earlier, I had found in the test.vendaria.net app (the only one that lets you step through it afaik) that the breeding cells all went at different rates of each other, regardless of the number of uranium cells they are touching or the heat of the hull, and I found that the lower the heat of the hull, the more differing the rates were for all of them, although I found that no matter how high the heat of the hull was that they all go at different rates. I believe this is a bug (maybe somehow related to how dispensers didn't shoot things with even probability for a while?), but at first I thought that maybe it was just something wrong with the app, as that isn't the best test app in the first place. However, I just tested it (right as alblaka made his update post) in MC 1.8.1 using this inside set-up: http://test.vendaria.net/index…XXUIPIPUIUIPPXXXXXXXXXXXX
with no air blocks around it, and 4 fire blocks so it could have exactly 250 heat, and I could feed it exactly 1 bucket per second. I wasn't going to complicate things just for a test.

And the results were: all of them save the top 2 went in different orders. (excluding the bottom two which only touch 1 uranium and are only there for heat) it started with the bottom left, then the bottom right, then the middle left, and finally the upper 2. This poses a serious problem to automated breeders, and may be a problem with breeders in general. I doubt I'm the first to notice this though, and am looking for people with more experience with the bug. If I am the first to find it, I will probably report it as I learn more about it. It is still of course possible to have a fully automated breeder, but a bit more difficult, especially if the result is that some are left at the end of the cycle which are just barely not done breeding.

Why am I working on an automated breeder you ask? because now that IC2 is on 1.0 and there are retrievers in RP which many many people who play IC use, there will be a ton of reactors which look like this: http://test.vendaria.net/index…UXUUUUUXUUUUUUUUUUUXXXXXX
and this (more efficiency): http://test.vendaria.net/index…UXUUUUUXUUUUUXUUUUUXXXXXX

those will be a piece of cake to build tbh. btw, to those building them, a word of advice: when using retrievers, I have already tested and found them to have one problem/mirable: once an item is pulled, it still follows normal tube distribution as long as it goes to one of the retrievers which is valid, and if many at different distances fire at the same time, all items will go into the closest retriever, but the retriever's buffer empties instantly as though it were a transposer sucking said items from the air. This means that all but one of the retrievers don't even need somewhere on the back end to put the items, because they will never go to those retrievers unless they are equidistant, allowing them to be remote and the design to be greatly simplified and compact.

Also, I found that one (blutricity) solar panel and batbox can power roughly 32 retrievers day and night constantly, but only if there is no weather. plan accordingly.

Finally, if you are to build one, you must know that the entire design needs to fit in one chunk. otherwise, if you walk away and only some of the chunks it is residing in are unloaded, there will be issues.

Anyways, the point is that those will be pretty easy to make (much moreso than the old CASUC reactors), and will provide an astounding 1740 to 1770 EU/t, but will take a LOT of uranium to power them for any length of time. Therefore, a good breeder may become necessary to keep what I believe will be a common design running constantly, or anywhere near constantly.

If anyone already has a breeder design, I'd love to see it, but for now I don't need so much a design, (as I already have a pretty good one that i made without the reactor itself yet that should be able to handle this: http://test.vendaria.net/index…PPIUIUIIUIUIIPIPIIIXXXXXX )

Moreso, I need information about this breeder glitch for the moment. I still plan on finishing above, already mostly made breeder, but the uranium management system will need to be different depending on your answers here and my testing.

Quote from Rick

Its less automated than my reactor. You need 1300 stacks of ice/cycle.

and that's without even mentioning the fact that it uses teleport pipes, which many people dislike because they're pretty cheap and overpowered. Still, I am hoping to see you find that mod for generating ice en masse, lolz. it should be pretty easy once we have the official game and can generate tons of snow with snow golems.

Now...
If you're looking for automated refilling:

If you look on this thread on post 151 and the next few, I explain it there, but it is a bit confounded by my rambling: http://forum.industrial-craft.…d&threadID=2071&pageNo=8&

Basically, in order to automate the refilling, there is first a problem made the the reactor not having all 6 chambers. Things filling it think it has full rows of 9, but when they put the items into the 9th slot and such, they just get chucked out by the reactor on its next tick (once every second). However, if more items are thrown in at the same time that it chucks the extra stuff out, the new items stick. Therefore, since reactors work exactly alongside redstone ticks (1 reactor tick for every 10 redstone), the "junk" can be inserted 1 redstone tick earlier than the next row, and the reactor can be filled row by row. However, due to difficulties timing the reactor, I recommend doing each row individually, rather than trying to go fast enough to build one upon the other. If you do so, the items inserted (for filling the whole thing with uranium, just as an example) would go something like this:

REDSTONE TICKS:
1) (# of missing chambers)*(row number-1)*junk inserted
2) 6 uranium inserted

11) see 1
12) see 2

and so forth. If you want more complicated patterns involving control over both rows and columns, I recommend instead that you leave all but one type of item in the reactor as place holders so to speak, rather than ever trying to refill the whole thing. This can be achieved by putting a transposer on any extraction filters, and changing the filter of the filter so to speak. However, if you plan on making a CASUC reactor with bucket overflow like Rick's, BrickedKeyboard's, or mine, then you will need to trigger the transposers with an inverted pulse, so that they stay on and don't accidentally catch the overflow during normal reactor operations.

btw, does anyone know the specific heat at which reactors start creating lava and/or fire? it'd be really helpful to know whether it was useful for such hot breeders, as I already know that water will already evaporate before 9000 heat on a 4 chamber reactor, although it will probably still be useful for detecting whether a 6000 heat reactor has gone too far.

Edit: also, does anyone know if deployers can use screwdrivers to change the orientation of things, or for that matter wrenches as well? and finally if they can place tile entities? could lead to some interesting machinery... and maybe help with improving the reactor stuff, although for now I only have fairly abstract plans for it, not real uses.

Quote from AkhkharuXul

@glasstables

Yepp Math is right.
@4k heat = 4.5 + 2 + 7.5 + 6 = 20 cells / cycle [ 2 swaps mid-cycle]
@6k heat = 9 + 4 + 15 + 12 = 40 cells / cycle [ 7 swaps mid-cycle]
@9k heat = 18 + 8 + 30 + 24 = 80 cells / cycle [14 swaps mid-cycle]

80 cells from 10 would be pretty amazing [The # of swaps might be off they were just quick guesses in my head]

Good, thanks a bunch for checking that for me. I got 8 for the number of swaps. That's a bit over the top, but hey, for a return of 80 for 10... and 80 for one cycle... that'd be pretty amazing. I mean it isn't nearly as hard to get an equivilant 8 for 1, but I figure that if I'm gonna have a super reactor, I'm gonna want a super breeder to power it. However, like I said, I'm gonna just go for the 40 first, because it'd be pretty hard to get the 80 to work I think. It might also be pretty hard to get the 80 to work if the redstone and reactor ever load at different times, but according to your tests with the sequencer it would seem that that isn't an issue, right? So everything should be calculable (how long it will have to increase it's heat after swapping stuff in order to be back at the proper heat). Should be interesting...

On another, less related note though I don't plan on tackling this soon, too much craziness with a new legit world. ever heard of the plains seed? I never had either, and put it in just for fun, but apparently it's well known, go ahead and try it if you want the hardest place to have a legit world ever (at least for industrial craft). I was doing pretty well till i realized i had no rubber, and thus realized I'd have to travel really far to get it. I figured it wouldn't be a problem though with the nether! boy was I wrong... 11000 blocks traveled (real world) and several portals later, I finally struck land.

Edit: not sure about the number of swaps actually because of how some are surrounded by 3, rather than 2 or 4.

Edit 2: you were right, it's 14 swaps, although I think it actually may be 13 because one of the swaps for the ones surrounded by 3 should coincide with EVERYTHING during the swap for everything at the half cycle, because their recharge time is 1/6 of a cycle.

Quote from Rick

Updated first post with my test world. Also includes the older reactors which i blew up for fun after i didnt needed them anymore. Reactors are located in the desert near the spawn.

Btw for ppl worrying about lag issues iam sure this reactor lags alot less than having 1280 solar panels.

Couldn't agree more, not to mention that its cheaper and the fact that it is only in one chunk allows for much greater lag control with the render distance settings.

I mean, if my crappy hp computer can handle 16 running at the same time and still be mildly reasonable, I'm pretty sure everyone else will be fine with just 1.

I actually have been looking more into breeding and may make a CASUC reactor that breeds at a higher heat than 6000 using the filling information I've aquired through testing, but I don't plan on doing an OVER 9000!!!!! reactor until I'm a little more sure that alblaka either is or is not going to include heat measuring machines with the computer stuff. If he does and they can control redstone (I assume they probably will), CASUC breeder heat management will be a piece of cake.

Still, a 6000+ heat reactor with this pattern (don't worry about the external options, i didn't mess with them much): http://www.talonfiremage.pwp.b…d=1a101010011010101r01019

ought to breed 40 uranium in a whole cycle, while only taking 10, leaving 30 for the 640 EU/t pattern we've been using, although if one of you could verify my math that'd be great, as I'm obviously still new to the breeding stuff. I believe that at 9000+ heat it breeds 80? if so that'd be fantastic if it worked.

Like I said earlier though, I'm really looking forward to a machine which can measure the tempature and control redstone based off the results. If it can, the easiest, fastest thing to change the heating would be pistons controlling whether there are air blocks or normal blocks around the reactor, then water blocks, then whether there's lava. In addition, you could also always change the rate of buckets going in, pull out or put in a cooling cell or reactor plate (for a .1 change), etc. I REALLY hope that heat measurement was included in what alblaka meant in his blog post.

Quote from AkhkharuXul

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

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

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

Quote from AkhkharuXul

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

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

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

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

Display More

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

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

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

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

Quote from MJEvans

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

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

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

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

Display More

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

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

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

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

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

Quote from MJEvans

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

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

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

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

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

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

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

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

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

Display More

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

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

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

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

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

Quote from BrickedKeyboard

How could automatic reloading possibly work?

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

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

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

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

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

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

Display More

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

1) first row filled with buckets (easy)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Quote from AkhkharuXul

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

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

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

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

Display More

Look, first things first.

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

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

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

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

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

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