Posts by Someone Else 37

Quote from Anaerin

A few points.

• You can make 5 logic matrices at a time in a crystallizer.
• You don't need the machine filters on all the inserting-into-the-reactor routers, just the one that inserts into slot 0. The other connected devices (the other routers) don't have any slots higher than 0, so a router attempting to insert into slot (say) 48 on another inventory will automatically skip it.

And on that note (and because I'm probably insane), I'm going to try making a setup like this. Wish me luck!

1. I probably knew that, but didn't think about it.
2. Ah, interesting... If all the production reactors are in one tower, so you don't need to use furnaces or anything to connect them, that could work very well. Just make sure that you don't wind up dumping things into an ME Interface or something.

The usual convention for naming reactors based on their size refers to the number of EXTRA chambers placed around the reactor core- so the core alone is a zero-chamber reactor, and the largest possible is a 6-chamber reactor.

Thus, a nuke with 9 columns in its GUI is referred to as a 6-chamber reactor.

Water, ice, and other inexpensive single-use coolants no longer work in reactors. You could, technically, make coolant cells, wait for them to burn up, and replace them, but I determined a while back that such a system can, at best, produce about 24 (Or was it 42? I don't remember) EU/t while also constantly consuming lava and enderpearls, with GregTech installed without a couple of the nerfs. You'd probably be better off with geothermal generators.

However, as Nonotan mentioned, the next best thing is CRCS- the Constantly Reapplied Coolant System (as opposed to the CASUC- Constantly Applied Single Use Coolant- systems you're used to)- where the idea is to pop the coolant cells out just before they burn up, cool them back down in another reactor (that contains no uranium, of course- just heat vents and exchangers), and pop them back in for another cycle. Automation is difficult, of course, but can be done. And Applied Energistics helps a lot.

Useful resources:

The DDoS thread, for ideas about coolant-cell based CRCS (there are lots of them)
The CRCS Tower of Power- for those who want to get a really insane amount of EU/t out of their power plants
An Insane MOX CRCS build, for use after you've already burned quite a lot of uranium (and are running IC2 Experimental)

Quote from willis936

Hey Greg, love the mod.

I've started building vertically for space efficiency. When coupled with factorization's router, applied energistics, and "barrel" style layouts (1 EU cable in the center surrounded by 4 of the same machine on each layer) you can make some very compact designs.

My suggestion is including a transposed mode for your multiblock structures. What I mean by that is making the component layout not necessarily in the x-z plane. In particular the fusion reactor. The other machines like the blast furnace could have some strange looking designs come out of it for advanced machine casing efficiency (number of advanced casings per machine block). This would ultimately be a more aesthetic change but could have some interesting consequence. I'm also not familiar with the ins and outs of minecraft and modding so I don't know how practical building multiblocks in the x-y or y-z plane even is from a coding perspective.

I support this, but not because my reactors would then have a smaller footprint- I wouldn't be able to wrap a vertical fusionreactor around as big of a steel Railcraft tank.

No, I want to be able to interlock fusionreactors chain like chain links. Because I think that would be cool, not because it would have any effect on the compactness of my setup or on the convolutedness of the wiring and piping. Heck, I would probably build four vertical reactors locked into one horizontal one just because.

Quote from abculatter_2

1. make a ring of tesla coils, just like the end portal.
2. place lava underneath it, also like the end portal. THIS IS IMPORTANT!! It's probably also a good idea to just put lava everywhere you can, so long as it's exposed to the coils.
3. Now, the wiring has to be done very carefully, or else you'll just die: start with the coils farthest away from your power source, and make sure all of the coils are connected BEFORE you put in the last one. Oh, also, the voltage has to be at least 512 eu/t. Minimum. Yes, I know the wiki says they'll explode, but they shouldn't if you do it right.
4. Step through the portal you just made and kill the ender dragon.

EDIT: Oh, also, I just remembered: You cannot do this in a creative world, nor in creative mode. Has to be survival.

Is it OK to wear quantum armor?

Also, try making a Mystcraft age with the Sky Biome and going to 0,0. Or combing the Tome of Alkahestry from Xeno's Reliquary with a bunch of diamond blocks.

There's also a way to get those eggs using Magic Bees- but, frankly, finding a Sky Biome page and killing a dragon is probably easier for most people.

Edit: Fixed a formatting derp in the post.

Quote from Aven

Hi, I have the same Problem with the reactor planner, although I gave it my permission, it won't work properly. Is there another way to access the posted designs?

If you tried updating your Java (both the browser plugin and the standalone version for your desktop) AND tried the standalone version of the planner I don't think there is.
[Direct link to Talonius's download link, in case the website instantly redirects you to the Oracle/Sun Java download page]

But if you can run Minecraft at all, your Java is probably up-to-date enough that the standalone reactorplanner should work.

Yeah, try updating your Java, and if that doesn't work, your browser most likely has a button somewhere (if there's a red thing at either end of your address bar when you look at the reactor planner page, try clicking it) to make it run Java anyway.

Assuming, of course, that your browser supports Java. If it doesn't, I can only recommend downloading the standalone jar- presumably, if you can run Minecraft, it should work.

Quote from Voltara

I was wondering what kinds of blocks don't melt? i saw someone said wires don't (assuming glass fiber) and i was wondering if tile entities like levers or stuff from other mods melt? Basically is there a list of things that can melt, or a list of things that cant?

I've heard that they recently changed it so that hot reactors don't melt things into lava, just start fires. So, if you don't build your power room out of wood or wool, you should be OK.

If you're going to go all-out with condensators, you might as well do something like this:
http://www.talonfiremage.pwp.b…6ksm8atlqvvuvh2sicdiw7u2o
which chows through nine thick neutronreflectors and nearly three thousand lapis every cycle.

But really, condensators are a big traps, because the lapis required to refill them takes a serious amount of UU-matter- and thus EU- to produce. I'm not sure how much EU a lapis costed before the UUM revamp in IC2-experimental, and I'm even less sure now, but I can almost guarantee you that it's not trivial. Same goes for neutronreflectors.

If you're using genetically modified ExtraBees in alvearies, then you certainly could produce the lapis every three seconds that you need to run any condensator-based reactor, but that's outside the scope of IC2, so we usually ignore it.

Although, I must point out, efficiency 3 wasn't half bad back in the days before multicells. Now, though, you can almost get to efficiency 7 without reflectors- so 4 or 5 has been "not half bad" since Minecraft 1.3, I think. Correct me if I'm wrong, though, as I wasn't a part of the IC2 community back then.

First off, when using the reactor planner, please send us a link to your design (See that "Copy URL" button there?) rather than a screenshot. It's actually easier on both ends- it only takes a few clicks to post a URL on the forum, and only a few more to put it back into the reactor planner.

For the record, here are the links to your designs:
http://www.talonfiremage.pwp.b…ph5wrzw2eq7unk0k1hgan5n9c
http://www.talonfiremage.pwp.b…g3vweyqatwsmlxbpb1q3rwtfk

Second, neutronreflectors are big traps. They're rather expensive, and the only way to replace them when they wear out is by using quite a lot of materials each cycle, and those materials require UU-matter to make, if you want to run your reactor at high efficiency indefinitely without using using expensive and/or unreliable mining methods, bees, or anything else outside the scope of IC2. UU-matter requires a large amount of EU to produce, which seriously hurts your efficiency. I don't know the exact numbers, but the cost of replacing four thick reflectors every cycle is surely a large portion of the energy the reactor actually produces, probably reducing your effective efficiency to 3 or 4.

Third, your reactors are incredibly expensive for reactors that can't match the output of two of these efficiency-3.3 reactors.

But, I'm not saying that your design won't work- it won't explode or anything- I'm just saying that your resources would be better spent on reactors that produce more energy at lower efficiency.
The Official Reactor Plans sticky thread contains a lot of good designs- I'd suggest looking there.

If you want high efficiency AND high EU/t, your only option is the Constantly Reapplied Coolant System (CRCS for short, check the DDoS thread for more information), which requires a fair amount of knowledge about how reactors work and a lot of automation. It's not for those new to IC2.

Very impressive system you've got there. A single GT fusionreactor produces about 46000 EU/t, after subtracting the power draw of the processing machines- not even twice what your probably much cheaper (at least in Chrome) MOX setup produces.

Your heat vent cooling tower isn't as impressive as the rest of your system, though, since the component vents cannot transfer any heat. You have several components that aren't actually doing anything.

A better plan is what KenKen originally used in his HVC rig- an otherwise empty reactor stuffed with heat vents. Such a 1-chamber reactor can cool 480 heat per second, using nothing but 24 overclocked vents. Since the overclocked vent has the highest heat dissipation rate of any component, there's just no way to dissipate more heat per second per slot. As for cooling them faster, just use a few more- they probably won't cost as much as your component exchangers.

Also, just to make sure, you are accounting for the fact that my cooling towers will never completely cool any cells, correct? I see Fuzzy Busses in your screenshot, so I can only assume that you did. I take it that they're set to extract 75% cooled cells?

The latest-generation cooling toward Shneeky mentioned are of my design, and are linked below.

Version 1: 1 chamber, cools 2 cells at 120 heat per cell per second, 240 heat per second total. This is the most compact tower, in terms of cooling per cubic meter.

Version 2: 5 chambers, cools 4 cells at 124 heat per cell per second, 496 heat per second total. Basically the above design stuffed into the same reactor twice over, and is slightly more cost-effective- Somewhat less than double the cost of Version 1, with slightly higher cooling efficiency.

Version 3: 6 chambers, cools 4 cells at 144 heat per second per cell, 576 heat per second total. This is actually the theoretical maximum cooling rate per cell, since no single component can pull heat from another faster than the 36 heat per second of the component exchanger. I'm not certain as to how its cost-effectiveness compares to that of the other towers.

The heating cells in these designs stand in for cooling cells- I just used the heat cells for testing purposes. I can't recommend this sort of testing for all cooling tower designs (particularly in cases where component vents are adjacent to the cells), but nobody seems to have cast doubt on my towers yet.

The caveat to these towers is that they will never actually dissipate the last 100 heat or so- which AE Fuzzy Busses can work around easily enough. Just yank cells out when they're 75% cooled. The 99% thing on the fuzzy bus is a bit of a misnomer- it actually only pays attention to whether the damage bar exists or not, so it's not helpful.

Another tip: Use a Buildcraft gate to only let the production reactor (or reactors) run when all slots in its inventory is full. May not be entirely failsafe, but it's certainly better than nothing. And it could prevent problems if enough heat gets dumped into the hull to melt the reactor instantly (think MOX), which Nuclear Control just can't do.

Two arguments in favor of different MOX efficiency conventions:

1. Base the efficiency numbers on EU/t alone, as outlined by Omicron above. After all, many people will use AE to automate their reactors in everything except gathering uranium ore, and won't even see the system swap cells around. This would be the most useful to the typical player, I think. It's certainly easier to calculate.

2. Base the efficiency numbers on how much fuel actually gets burned up in the reactor, with respect to total EU gained from that material, assuming that players have access to a Thermal Centrifuge. As I don't know the various recipes myself, someone will need to fill me in here:
- How much U235 and U238 go into a regular nuclear fuel cell?
- How much U235, U238, and Pu does a spent regular fuel cell return when centrifuged?
- How much U235, U238, and Pu U238 go into a MOX fuel cell?
- How much U235, U238, and Pu does a spent MOX cell return when centrifuged?

The efficiency could thus be described along the lines of
TotalEnergyProducedPerCyclePerCell / (MaterialOut - MaterialIn)
which would actually return three numbers, one each for U235, U238, and Pu. Since these are all necessarily proportional to each other for any given fuel type, only one figure need be given, except in the case of hybrid reactors.

[double-posting so my update actually gets seen, unlike my edit above]

I think I've finally worked out most of the kinks in my tower-refuelling script.

Changelog:
1. The program now runs itself in an infinite loop, so need to use an additional startup script.
2. Instead of checking for a redstone signal every minute (or however long), the turtle will respond and start its refuel routine the instant it receives a redstone signal at the back. It waits passively for a redstone update, so no worries about lag.
3. There are now two versions of the script- one for Shneeky's double-stacker design as before, and also one for the more efficient 8-quad-cell solid-core design (that Shneeky might have called a "Pocket Reactor"). The only difference is in line 3, if anyone's interested.

Installation:
1. Check the post above (as well as the OP) for info on how to set up the towers.
2. In the turtle's GUI (make sure there is an Inventory Module attached to its right-hand side), type one of the following commands:
For the double-stacked design:

pastebin get sju45rSF startup

For the solid-core design:

pastebin get drP7DMi5 startup

3. Hold "Ctrl" and "R" on your keyboard for a second to reboot the turtle. You should see the "TurtleOS 1.5" text at the top of the screen, but no command prompt.
4. Send a redstone signal to the BACK face of the turtle when your fuel cells have expired, to instruct the turtle to refill them from your AE network.
5. How you detect when the reactors have burned their fuel is up to you, but I recommend running a Mass Fab or some other machine with a constant power draw off a BatBox or MFSU set to "Emit Redstone When Empty". Just make sure that this doesn't interfere with the splitter cable.

Also, I've noticed a bug where the Charging Station sometimes glitches out upon world loading, and eats EUs without charging the turtle. This may or may not have something to do with the turtle powering the redstone torch through the charging station.

Routers from Factorization can do this, although you'll need a separate router for every single slot you want to fill. This can get expensive quickly.

Althernatively, there is the Inventory Turtle, from ComputerCraft and MiscPeripherals. It is by far the most versatile slot-targeting item transport device I know of. It can even be supplied with eight different item types from one single ME Interface. The main downside is that it requires programming in LUA- which is not a difficult language to learn.

However, if you only need to supply items to specific slots in the reactor once (i.e. you want a thing to automatically set up a bunch of reactors) and the reactors have no empty slots or stackable items in them, you can use a normal turtle (or fancy Redpower sortron (or MiscPeripherals Interactive Sorter) trickery) and drop the items into the reactors in the correct order.

Since you're using the 1.4 version of AE, you're going to have a really hard time getting AE to extract or insert the coolant cells- as the import and export busses (if I'm not mistaken) cannot be configured to accept any range of damage values- and even if they can, it'll consider everything with some damage the same as anything without damage, which is not useful. Since you're on 1.4, though, you have access to Redpower. You will need to use timers, but there's simply no other way to do it without something that can match a range of damage values, and I don't know of anything that can do that other than ME Fuzzy Busses. There is discussion on how to set this up (this is also why a production reactor design that heats cells uniformly is important, as Shneeky explained) in the DDoS thread.

Also note: DO NOT just use a Redpower timer to trigger your coolant swap, as those like to reset occasionally (which can lead to craters). Have a 1-second timer pulse a counter to keep track of the number of seconds elapsed since the last coolant swap.

Sodium-Potassium coolant cells are identical to helium coolant cells in everything except texture and crafting recipe.

As to cooling towers, the fastest one I know of is this one of my design, although the 1-chamber cooler also of my design that Shneeky linked above is almost as fast and a lot more compact. The downside of these is that they will never quite completely cool anything, due to the nature of component heat exchangers. So you'll have to pull out the coolant cells after enough time has passed that they should be mostly cooled- not a huge problem, since you already needed to set up a timing mechanism to swap the coolant cells in the reactor itself.

If I remember correctly, centrifuging 16 uranium dust results in 16 uranium cells, 4 thorium cells, one tungsten dust (or was it a wolframium cell? Same thing, anyway), and one plutonium cell. So that's one way. You'll need to process 1024 uranium dust (16 stacks!) in order to refuel this reactor. Maybe not quite entirely feasible.

Doing so will also leave you with 16 stacks of regular uranium cells. These can be burned in other reactors for many times as much energy as the plutonium.
The depleted cells can then be bred, and eight re-enriched cells can be centrifuged for one plutonium cell, four thorium cells, and three depleted cells than can then be bred again. You probably are better off building more breeders and processing the depleted cells from your Tower of Power. Also note that thorium (prior to the nerfs in the last GT updates for MC 1.4- which version of GT do you have?) can make some excellent breeders.

Finally, a Buildcraft gate set to "Inventory Full" >> "Redstone Signal" is a very effective method of preventing heat buildup in CRCS reactors. Using Nuclear Control to turn off the reactor after heat has begun to build up can be very dangerous for OC vents- the vents suck the heat out of the reactor hull, so Nuclear Control turns the reactor back on before the coolant cells get replaced, so more heat builds up before the vents can finish cooling themselves off, and eventually the vents melt.

I suppose there is a small chance that the reactor will tick before a BC gate can turn it off, but that's what heat vents are for.

This design of Zombie's creation is a surprisingly effective beginning reactor. It's as safe as a reactor can be, takes up only one block, and produces just as much EU/t as five geothermal generators.
There are, of course, more efficient, powerful, and expensive reactors out there- look at the sticky reactor designs thread that has already been linked.

Also, CRCS is a very advanced and expensive system that likes to turn production facilities into craters if you don't know PRECISELY what you're doing, and sometimes does so even if you do know what you're doing. If you're new to reactor design, I would recommend sticking to mark 1 designs.

Quote from ShneekeyTheLost

I wonder if the latest version of Logistics Pipes can assist. Set up a Supplier Pipe to keep x 60k cooling cells and y nuclear material. As long as you don't have nuclear material and cooling cells pulled at the same time, it shouldn't get its wires crossed, although it is something of a risk I suppose. I believe LP can sent requests through an ME Network.

Ehhh... Although I agree that that might work, I wouldn't want to run that risk. Although getting a coolant cell and a uranium cell swapped would probably not be catastrophic, such a Logipipe-managed reactor would not be reliable enough in my opinion for commercial use.

Some problems that my thought-experiments indicate could come up, in no particular order:

1. Coolant cell gets pulled (by ME Fuzzy Bus, I assume), and enough time passes before Logipipes can replace it that the reactor explodes.
2. U-cell expires and leaves some depleted cells, LP tries to restock before AE pulls the depleted cell, either a U-cell or a coolant cell drops on the ground because it won't fit in the reactor. I'm not sure if this can actually happen in the current version of Logipipes, now that pipes don't usually drop things.
3. Several U-cells burn out at the same time several coolant cells get pulled, LP replaces the cells in the wrong places, leaving one U-cell adjacent to only other U-cells and maybe an OC vent (but no coolant cells), the OC vent melts, and the reactor explodes.
4. LP fails to restock uranium cells because it can't access the ME Molecular Assembler Chamber with U-cell recipes. Yes, I'm fully aware of the existence of workarounds to this problem (i.e. using Logistics Crafting Tables to craft quad cells on demand, using an Export Bus to craft quad cells and pump them into a chest with a provider pipe on it, using AE components to keep quad cells stocked in the AE network itself, etc.).
5. Supplier pipes turn out to work like precise busses, and refuses to mess with 75% cooled cells at all.

I think it's actually number 3 that I'm most worried about.

Side note: I'm currently writing a LUA script for an Inventory Turtle (introducing two MORE mods, ComputerCraft and MiscPeripherals) that replaces whatever happens to exist in the particular slots in the production reactors with uranium cells. Most of the code is written, but it keeps crashing when it tries to actually swap the items. I'm relying on AE flooding the whole reactor with coolant when the uranium cells expire and Buildcraft turning the reactor off when there's a space in it to prevent explosions.

EDIT: I've completed the LUA script. Setup is a bit complicated, as this is actually the first LUA program I've written aside from "Hello World!" and some short-lived programs intended to help me learn how some things work.

1. Position your Inventory Turtle (make sure that the inventory module is installed on the RIGHT-HAND side of the turtle) atop a Charging Station (facing upward), below the production reactors.
2. On your turtle command line, type "pastebin get FHWBDsAj NukeFuel", without quotes. This is for Shneeky's single-chamber double-stacker design.
3. Type "edit startup".
4. Type some simple startup script, such as:

while true do
  if rs.getInput("back") then
    shell.run("NukeFuel")
  end
  sleep(60)
end

5. Hit "Ctrl" on your keyboard to bring up the menu. Press "S" to save, then "Ctrl" followed by "E" (not at the same time) to exit the text editor.
6. Give the turtle some fuel to get it started, type "refuel all", then press and hold "Ctrl" and "R" for a few seconds to reboot the turtle.
7. You should see the "TurtleOS" thing, but not a command prompt.
8. When your nukes run out of fuel, give the back of the turtle a redstone signal, and it'll kick into action within a minute.

And because a picture tells a thousand words...

This shows the entire setup. Note the Fuzzy Export Busses on the LEFT side of the reactors, and the turtle on the RIGHT. The cobblestone at the top is also crucial- it tells the turtle when to stop.
Not shown around back (because I forgot to put them in) should be some Buildcraft gates, set to "Inventory Full" > "Redstone Signal". These turn the reactors off when there's a space in them, preventing explosions while swapping coolant cells. Make sure that these do not turn off the Fuzzy Export Busses, which are configured the same way as Shneeky's.

This is the GUI of the Fuzzy Export Busses. The only thing different from those in Shneeky's design is that they are "Active Without Signal"- so the turtle can turn them off. This isn't a problem, because if one coolant cell gets pulled while the (surprisingly fast) refueling is taking place, the BC gate will detect the empty space and turn the reactor off.

This is a closeup of the bottom of the tower. When it needs fuel, the turtle sends a redstone signal through the MiscPeripherals Turtle Charging Station (which is facing upward), turning off the redstone torch, allowing the splitter cable to transfer EU.

The ME Interface is set to keep four quad uranium cells stocked at all times. There may be problems if the ME network can't restock those cells faster than the turtle pulls them out.

Quote from ShneekeyTheLost

I don't trust routers to be able to handle this kind of situation. Every time I've tried, Bad Things started happening.

Use them or don't- the choice is a little diamond, iron, and time, or a ton of quartz.

Anyway, here's what I set up to automate just one layer of my layout with the OP's design inside each reactor.
Keep in mind that the two routers shown here reactors will happily manage all the nukes in the entire tower.

VERY IMPORTANT: Place all the non-fissile components into the reactors BEFORE you hook up the routers. If you wish, you may use the routers and your AE system to populate said components for you- but this can get a bit complicated (and time-consuming), so I don't recommend it for anyone who's not already familiar with routers.

You see two routers, with a Precise Export Bus and an ME Interface in between. Note that both routers are touching the block of nukes- this is very important, as it allows the routers to inject fresh double cells and remove depleted cells when the old cells expire.

The router on the left is configured as follows (all pages of the GUI (click the "--" button to change pages) are shown in one image):

Note the Machine Filter and Speed upgrades. The speed upgrade is not very important in this case- but at four dark iron, four sugar, and a cake, it's not terribly expensive. Thoroughness (dark iron and soul sand) could be another option, if you want the router to completely fill the first reactor before moving on to the next one, rather than putting one uranium here and another there. But that's a matter of preference.

The export bus is configured to fill the left-hand router with double uranium cells, crafting as necessary.
The Interface is entirely unconfigured, and will instantly import any items pumped into it into the ME network.

The other router uses an Item Filter, a Speed Upgrade, and an Auto-Ejector Upgrade. Speed, as before, is optional, while Thoroughness and Bandwidth could be other options. Bandwidth (Dark Iron, Blaze Powder, and an Egg) would make it pull each stack of depleted cells at once, instead of pulling each individual cell one at a time. It would be a small speed boost, seeing as double cells only produce pairs of depleted cells, but a boost nonetheless.

IMPORTANT: Be sure to configure the Item Filter with a depleted cell BEFORE switching the router to Extract mode. If you don't heed this warning, the router may well devour your pre-configured reactors one by one, and dump them into your ME network. Also note that the ME Interface is on the northern side of this router- which also happens to be the side marked with a blue line in-world. Handy trick, that, and one that would be useful in most mods that implement blocks with side configurations in their GUIs.

And, finally, from this one layer of a rather powerful nuclear tower, I get

2160 EU/t. Yes, I know that MFSU will eat most of it, this was all a demonstration.

Quote from Shakie666

You know, even though this is a great design and everything, it bugs me that it only has an efficiency of 5. Isn't it possible to squeeze some neutron reflectors in there to make it 6?

You certainly could do something like this, but neutronreflectors are expensive- GT's iridium reflectors hideously so; and the basic ones incur an additional running cost, which could end up decreasing the overall efficiency if you replace them using UU-matter.

Additionally, with more power comes more heat- the design I linked produces a whopping 2688 heat per second, which would require 11.2 of my 2-chamber cooling towers at the very dangerous minimum to keep running. That's also 22.4 coolers if running plutonium in the latest versions of GregTech, according to Omicron's data [read: if Greg didn't change it again without saying anything].

As a side note, I'm currently learning LUA so I can program an inventory turtle to repopulate the production reactors with uranium cells, after AE goes and fills them in entirely with coolant cells. Because using eighteen routers to manage far more nukes than anyone would ever be able to use is ridiculous.

Quote from ShneekeyTheLost

No, look a few posts up and you will see that I've got a 4 cell 5 chamber design which holds 4 cells that cools about 148 per tic tht uses them. In fact, it's really the only way to achieve more than about 16 cooling per tic. No, I was more concerned with how many OC vents are 'shared' by multiple exchangers.

I was referring to the designs with one component vent and three component exchangers (probably the very design you've cited)- the exchangers transport most of the heat to the OC vents, and the component vent finishes off the last little bit of heat. Not so in my design, hence the problems.
Regardless of how many exchangers are adjacent to most of the OC vents, the design seems to work. In fact, this very feature may help cool one cell even faster when the other cell isn't there or is at a lower temperature...

[testing]This seems to be the case. The tower seems to be able to transfer heat between the top and bottom halves faster than it can pull heat from either cell.[/testing]

It was also just about the only thing that I could do when trying to stuff as much cooling power as possible into a 2-chamber reactor. I figured that the more exchangers I put around each vent, the more heat could be transferred to each vent, so it would dissipate heat faster. It was my intuition speaking to me- and apparently it was right, for reversing the top half of the design does indeed reduce the cooling speed of the tower. I suspect that having component vents adjacent to each other is a significant efficiency hit, as they can't dissipate heat from each other.

Quote from ShneekeyTheLost

You can use 99%, which is around 600 heat and still bypass that problem.

Did you test that?
Turns out that the 99% thing is a bit of a misnomer (as I had suspected)- it behaves the same way as Redpower Filters, and only pays attention to whether the damage bar exists or not. If programmed with a fully-cooled cell and set to 99%, a Fuzzy Import Bus on my cooling tower will never do anything.