Posts by MJEvans

Are you sure that's the safe temperature? I thought it was 10K for the reactor core, then 1k for each chamber added. So 0.7 * 14000 should be 9800.

Quite; while your probably won't blow up (for a while; I suspect the cooling water may evaporate enough for it to slowly heat up), it will swing through the zone where the reactor hurts the user. My reactor design replaces exterior water cooling with a little internal cooling and the IHDs also act as dampeners for the thermal swings to keep the reactor in the sweet zone without going over 70% max temperature.

The latch is needed to turn off the warmup circuit which stops bucket delivery entirely. When I actually have the time to properly build this it will be more clear.

If your pulse ratio is 1:whatever you might be safe, but then again you're also counting on that /exact/ quantity of cooling each and every tick. In my case it was 3 ticks on and 2 off so it would show aberrations sooner.

When you get to this level it's easier to just use UU mater to make glowstone. I'm sure you can find the recipe if you look in the right places.

Second easiest way, place item in inventory; edit inventory. Information is right there.

Bukkit, at least, can do multiple worlds. The teleporter pipe mod and other systems, I have /no/ idea how they'd even begin to address multi-world communication.

I was initially planning a master clock for 4 reactors, so toggling the clock there was not a design consideration. Each reactor has (was planned, only one was built) individual controls for all the options (force reaction every tick, water on/off, warmup clock, and master off+cool).

I honestly don't see how a toggle latch would have any fewer issues than the RS latch. I'm leaning towards every so-often the reactor evaporating the block coming down from the source block and causing a void to flush across it just long enough for at least one cooling to be absent. The redpower2 waveform issue (is it off by one/two on length, delay/sync etc) I could probably spend a whole evening wiring up a crap-load of latches delays and redpower2 light blocks to capture a snapshot of; but I don't really want to expend that level of effort when there's a more promising design that has better specs anyway.

It also has two major advantages I've learned since last build.
#1 redpower2 logic can live on walls.
#2 I seriously just cannot rely on exterior water-cooling (except maybe as an emergency shutdown thing) if I want any modicum of reliability. I haven't seen it happen but that makes the most sense.

Here's the python2 script:

The important part is that I've used values to simulate a redpower2 clock, counter and sequencer.

warmup_cycles = 46 << counter
warmup_len = 13 << one sequencer side
warmup_len2 = 39 << three sequencer sides

(every other for the bucket, the clock, actually a second clock for filling the water buckets/extracting would be more reliable)

Using Redpower2, instead of buildcraft, why not combine a timer and counter? The timer constantly pulses while the reactor is on, and the counter ticks up/down based on the timer. When it's done you'll need some kind of latch (RS or toggle) that also forces the reactor off. A toggle of either kind might be used to switch from count-up to count-down and reset things again.

Edit: -much- more data.

This is the automated warmup timer I'll probably build for my self and my modification of the design later this week/weekend.

Here is the python2 script I used to calculate the values:
-- Oops too big I'll carry over in to a new post --

Here are the values until it stabilizes:

I'm likely abandoning the idea I was working with here in favor of the more resource and more promising to stabilize effort here: https://forum.industrial-craft.net/index.php?page…d&threadID=2760

The issues I suspect I was running in to may have been:
* synchronizing the redstone pulses to the reactor (doubt it),
* evaporating water (seems plausible),
* or accurately forming a redstone clock of exactly 3 seconds to 2 seconds high/low (or inverse) using an RS latch and two timers (might be the case, but I tried a large number of off by a few mS adjustments).

http://www.talonfiremage.pwp.blueyonder.co.uk/reactorplanner…1201521s1r11r19

Ok, so this requires preheating the cooling components you toss in. They don't need to be exact but they do have to be fairly close. 9250 to 9650 is ideal (it must be that temp when /starting/) up to 9999 for the cooling components will work (as long as your reactor is < 9500).

It uses only air cooling externally, so no fear of water evaporation. The internal cooling cells are to make up for the loss of external cooling. The IHDs act as buffers to stabilize the reaction between 9000 and 9800 over 2 cycles.

This design may address the reason I /suspect/ my redstone gated breeder is unstable; actually since the timing is no longer dependent on synchronizing redstone to the reactor it fixes it also, thus making both possible design issues in my current setup vanish.

The only issue is heating it up; the hull it's self is easy enough, but the cooling components inside are impossible to heat quickly enough. Even stuffing it with IHDs, the IHDs would catch up but the cooling cells to match the missing external cooling would take more time. A single shot startup is not possible.

I've simulated it with a crude python script and this design does not loose any components over 99999 cycles.

PS: the 9800 limit is so the reactor doesn't try to hurt the player. Otherwise I could care less as long as the components don't melt.

Design goals:

Heat using uranium.
Short heating time.
Minimal cooling component* (Mostly for short heating time)

Traditional breeders use a vast array of cooling components; each of which must be brought up to your desired breeding temperature. This is why the reactor planner says you need a gazillion buckets of lava to heat the bloody things. They are also extremely slow to heat up, or use multiple uranium cells. That's why I've been experimenting with this design:

http://www.talonfiremage.pwp.blueyonder.co.uk/reactorplanner…1501521s1r11r19

As you can see, it produces an excess heat of 20 per active reactor tick. Cooling is supposed to be 34 per inactive tick (less 4 for the isotope cells). This naturally leads to a 3:2 ratio. It runs at 60% of traditional breeder speed, but higher efficiency of fuel and less babysitting (when stable).

The IHDs are required for a single-run startup timer (if the water in is piston-blocked off; which is a must for speed), the excess IHDs only moderately increase the cost of producing the reactor but make that process far safer. The current startup time would thus be desired-temp * 7 / 37 (*for fully cold components; 6 heat sinks inside and the reactor vessel).

I'm not sure if it's boiling water around the reactor, or if it's the fault of redpower2 timing, but using 2 timers and an RS latch to switch between the two I have not yet achieved the predicted perfect ratio.

An alternative approach which might also work is building a reactor with zero external cooling and CASUC/CARUC style bucket cooling, I might try that next if unable to nail this down.

http://www.talonfiremage.pwp.blueyonder.co.uk/reactorplanner…1201521s1r01r19 << Note the lack of any water blocks around the reactor (unlike the other recent thread about a CASUC breeder I looked at after coming up with this design from just the 'casuc breeder' title.) Mine also only enriches 16 per instead of 20, but won't swing so violently through the hurts-player 70-85% thermal region.

Over an ideal cycle my design's internal components (10) will help the reactor vessel by containing 75 of 200 heat for each tick... However that's a really crazy network to conceptualize given the multiple sub-components interactions. I'll have to write out a proper simulation of it later tonight.

That's when you abort and rollback to your last backup. You -do- keep backups, at least of your test worlds, yes?

The crater left behind by my very first failure was... spectacular.

Very -eep- on the /time thing. Could make my latest project boom.

I feed the RP2 signal through a normal minecraft repeater before hitting the reactor.

About timing... It's still not quite right. I'm using a few other gates to control waterflow+clock gating. That part is correct. Where I'm getting in to trouble is not knowing the propagation delays for RP2 components. It doesn't actually matter anywhere except my source-clock; that's using two timers and an RS latch to alternate with different up and down periods. So far I've only been able to get a slight lead or slight loss of heat even though it's supposed to be a perfect breeder (on average).

Except as noted elsewhere; IC2 nerfs water and obsidian. Obsidian now has a blast resistance of ~60 instead of 6000, and water is not 500 (50?). Re-enforced stone or go home (I hate re-enf glass because I can't reuse it).

I use a bash script to automated mixing things together.

Due to the crappy assumption of modloader (which is also used in the server version of modloadermp), I have to also add the mods to my minecraft.jar to make sure there aren't ordering issues, just 'I already have this' warnings. The files themselves are still necessary in the patch folder to satisfy modloadermp that the mods were in fact present.

Would this be what's causing the losses with glass cable as well?

I made a test with an MFS Unit and two wings of 16 panels using; 32 solars, 10 glass fiber, 1 MFSU.

Daytime run, expected energy value: 417600, total value attained: 374920.

There are two possibilities I see.
1) Not sending partial packets at the start/end of the day.
2) Some odd cable length loss calculation.

I don't think it's #1, as the worst case losses for that would make the final value 384832 or greater.

Edit:

Tested with 3 solar panels at one end and a batbox at the other end, of 36 TIN wire.

1 full day's collection of energy: 3952

That is approximately 1/10th of what it should be. It seems as if you are calculating cable losses in floats instead of applying a more accurate formula.

You should calculate bursts as: Normal packet if traversing the cable type * number of packets; all of which can be determined via integer operations. There should be no floating point at any point in that chain of calculation.

BurstFreq = floor( min(cable_type, storage_type) / normal_packet ) << 'integer' operations result in the floor already
ResultForStorage = (BurstFreq * (normal_packet - (int)cable_length/(int)one_loss_cable_length))

If you use a special insert/extract pipe or other mod, than core + 5 chambers is possible. If you use Redpower2 there is no such entity and you must instead attach both a filter (to remove empty buckets) and an incoming pipe for full buckets; thus limiting you to 4 extra chambers.

I've posted pictures of my RP2 prototype CARUC (the coolant is REUSABLE/Recyclable, not single-use) reactor which should show you the various stages you'll want. Obviously use ReStone instead of glass and mind the 5x5 block (core in the center) exclusion area for your source blocks.

Actually if a CARUC/CASUC goes up that's something like 40exp power + like 5 * 30 for all the uranium... about 200EXP power? 3-4. maybe 5 if you get unlucky about which direction things want to jump, blocks thick is probably necessary.

Yes, true for SSP. However I wouldn't trust SMP to never split it further. A 16x16x16 block sounds particularly tasty for alignment to me. Something that /may/ have changed with the ability to use > 128 high as a global setting (it's in the release notes that the groundwork is in /place/ for that).