Posts by MJEvans

BB1 = tier 1 storage (Batbox)
BB2 = tier 2 storage (MFE)
BB3 = tier 3 storage (MFS unit)

There always is; Just not necessarily where you're mining.

I've hit expanses of deadzone (just cobble and other junk) before; you're at the mercy of a pseudo-random number generator; not a regular pattern of sparseness.

Quote from Kane Hart

Clearly Cactus is Over powered. How about something like to much crap starts causing the machines to break and you must also repair it! Prevent automatic cactus farms!

Actually it already does that; buildcraft pipes rather suck when it comes to overfull destinations.

However, once again you're loosing sight of the fact that this is a /compressed/ time simulation. All of the boring mundane stuff is supposed to be skipped over since it's just pure grinding and has nearly zero creativity.

Quote from WarChicken78

I really don't see that point, since the ML us completely useless as a weapon in IC². I had to shoot a skeleton multiple times (about 6 I think) before it bit the dust. And that's ok - it's menant to be a tool, but when I use it, it runs through about 4 smoothstone and then dies off. With all the positioning to do a straight tunnel, I'm faster with the mining drill.
This was way different in IC1 - it had a higher range and way better penetration. I even used it to cut away large land overhangs. Loved it.

You /are/ using the correct mode for those tasks, right?

The 'mining' mode is sort of shallow penetration but lots of shots.

There's another mode (stupidly expensive, but realistically so; damn thing needs a bigger battery) that can be used to lase a tunnel.

Quote from Kuudere

http://forum.industrial-craft.…page=Thread&threadID=2483

Not using it, however. +Mining speed makes it seem non-legit, and mods that change IC functionality in general (besides the non-fail wrench, because fuck that) don't taste good to me.

100% agree on the upgraded wrench being fail-proof.

The increased mining speed is also something that wasn't needed; the drill it's self is supposed to be the limiting factor.

That automated cactus farm looks like a better and better idea.

This isn't supposed to be grindcraft; it's supposed to be fun. You want people sweeping solar cells all the time in a compressed time simulation? That's not fun, that's crazy.

Try Redpower2 you get all the neat tools you need to do things quickly.

It endlessly cycles. This is the alpha version of my design. JUST enough to test it to make sure the concept works. Zero built in safety features of any kind; sub-optimal component placement. It's also to teach me about the various quirks of actually building it.

Now I know what I want to do with it. Next comes optimizing the layout of the parts, and then switching from a completely open control loop to a closed loop (counting out-coming buckets and making decisions). However doing that would tune the design to a specific configuration.

If I did tune it, I'd probably sacrifice a little short term efficiency and go for this:
http://www.talonfiremage.pwp.b…=1i1010101120101021e01r19

It has an /exact/ excess heat of 2 buckets per second. This means I can get it up to whatever temperature I like and then breed there with stability. However I'd want to use a completely dedicated timer for the insertion and constantly keep everything else ready. One-mis-fire and that system /would/ blow. I don't think I'd do that until the 'empty row rejection' issue is solved one way or another. Of course that might also change the design I consider 'optimal'.

x.x Keep practicing.

My own design for that used 8 IHDs, 3 uranium in a row middle of the second row, and the rest was cooling. The IHDs were stacked in a <> kind of pattern along the sides of the reactor (a column in the center and two on each side).

A -better- design for that is the one that uses 1 less IHD than mine, replacing it with hull-plating. It used a column of three in the middle almost at the top; plating above that, and then fit in as many IHD+3 cooling cells as possible.

Bucket return is what's covered in picture 2, and stage 2 of overflow return is covered in the third picture. (filenames 1 and 2 respectively; start counting at 0.)

The reactor is only able to throw the buckets out of the face with the pipe, so the two filters cover the buckets that collect at the bottom of the containment area and on top of the pipe.

Stage 2 collection nabs the buckets it manages to fling in to the cube of pipe that goes through the vessel wall. That's the two filters outside.

Ejected buckets are sent /immediately/ back to the reactor thanks to the smart pipes of RP2 (it's the shortest valid destination).

Here's the version that blew up because the buckets weren't getting around fast enough; I've revised the cooling loops further since then, but still want to make major changes.

This is a close up of the changes I made since the first run; it restores a feature I took out because the filters got contaminated. I no longer care if they suck up a bucket to self-config. Instead they add in instant retry/spamming.

I've since added filters symmetrically on the sides of the incoming pipe about where I was standing when I took this shot.

This is an overhead shot I took when Q-boot jumping.

If a torch won't work, why should a repeater?

MK-II-5-CARUC EA Breeder: 305eu/T eff 4.48

http://www.talonfiremage.pwp.b…=1j1010101120101021e01r13

Due to Constantly Applied Reusable Use Coolant, this reactor /actually/ is stable (4000 to 4500 +/-500) when the cooling system is functioning properly. No cooldown time is necessary. the reactor planner is trying to cool it down to 3000c instead of 4000c.

I currently have this running on my SMP server; it uses 3 filters for the reactor complex. 1 filter for the sideload buffer of buckets for the pneumatic tube delays (My initial design has a /lot/ of room for optimization), 3 chests (2 for the sideload), dual deployer (to fill the buckets)/filter combos a filter to feed the reactor and a filter for pulling empty buckets that end up in the wrong place back out of the main buffer.

In short: it uses 2 deployers and 6 filters. Everything is timed off of a single redpower timer with 0.2 pulse timing.

The only problem I actually have with the current design is that buckets get kicked out in to the same space that the pneumatic tube feeds them in. I'm currently considering additional filters to suck them back in to the loop.

I just had a particularly rough first startup of my first actually built CASUC reactor.

The important part is that I tried to control the reaction (prevent it from ticking uranium) by placing a redstone torch on block directly adjacent to one of the additional chambers.

Side view, ignoring the rest.

My understanding of redstone torches is that they should 'energize' whatever block they are attached to, the block they occupy, and the other 5 blocks directly touching the redstone torch's block.

http://wiki.industrial-craft.n…php?title=Nuclear_Reactor

• Apply Redstone current to the reactor (or one of its chambers), causing it to stop generating heat and EU for as long as the Redstone current is active.

My observations do not match the above behavior; it runs even with the torch in this position. Is this a bug or mis-documentation?

As an additional note; I think my current design is stable, but even with the revised reload spammer I don't trust it since the reactor can kick buckets out in to blocks where RP2 pipe exists (and thus it's not picked up by a filter).

A more pneumatic tube optimized version of my design with built in safety counters and using /that/ to gate bucket delivery (one out, one in; with a reserved 'overload' count to keep in flight) would yield better results, but I'm happy enough to let this try to pass the initial run and see if the concept is stable at all.

Using some adjusted settings I am able to get it performing OK for my self and a friend within 1024MB of 'dedicated' memory OVZ (burst is up to 2048 on that); however I have trouble telling how much of that is /needed/ and how much is just garbage collection bloat it isn't doing enough to rid it's self of. If your four friends are understanding then probably the same specs would work out. If they're demanding, ask them to chip in an extra few dollars so you can upgrade it to 2048.

Asking about /where/ to host it depends entirely on your skill level. If you're looking for a hosted solution I'm sure many here can tell you where NOT to go. If you want to run your own + etc, there's really only a small list that make sense.

Harder to setup without RP2 (but you have that) is the 7 to 43 second one:

http://www.talonfiremage.pwp.b…y=1o101010010010101001019

You might also use an active-disable switchplate to force the reactor to stay on in order to keep it over 9000; however if you do that you should have the thermometer addon.

Ignoring speed this should do the job:

http://www.talonfiremage.pwp.b…i=1k101010010010101001019

It /REQUIRES/ 20 redstone pulses (1 second) op time to 815/5 * 20 redstone pulses of cooling time. Yes, that's right, a single reactor tick would take a total of about an hour. It's insanely slow but that's the only way to get maximum efficiency out of it as a pure breeder.

Here's a core + 1 chamber design. It wants a brief 1:5.25 ratio. Running it for 4:21 should be safe (the 5 to 25 numbers quoted are rounded down).
http://www.talonfiremage.pwp.b…6=1o101010010010101001019

Note this presumes 9000 initial starting temperature and constant operation to hold that 'perfect breeding' temperature.

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...

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.

Tin occurs <40 (hit f3 for debug to get your X,Y,Z; among a lot of other stuff you won't care about, f3 turns it off again)

'You' are about 1.6 high. So when you are 'standing' at 41.6 the block beneath your feet has an upper side at Y=40; it's lower side is Y=39.

http://www.minecraftwiki.net/wiki/Redstone_Ore

Redstone can only be found (naturally) beneath level 16.

If you follow the how to get started in the IC2 wiki it /does/ mention a 'journey to the center of the earth'. As an alternative you could quarry or use a buildcraft miner, but the quarry requires a mess of diamonds to make... so you're probably better off trying to find a route down that is safe for you.