Of course, I post that, then run into Forestry needing a more up-to-date copy of IC2 in order to recognize its presence ... and then the updated IC2 brings back the ClassNotFound ic2.api.core.item.ElectricItem NEI crash :p
So it just re-emphasizes that it works, but it takes more active involvement on your part to keep it working.
Around build 289 or so they started making compatibility-breaking changes to the API. Using a more-recent version of IC2, with a mod that includes the old API, will lead to problems ... and using a older version of IC2 with a mod that uses the updated API will probably lead to problems too.
Aside from that, your initial premise - include IC2 in the world, but not interact with it aside from worldgen, and *maybe* harvesting ores - seems sound to me. That's what I did, personally - for a long time in 1.5.1, IC2 was just for worldgen. I've since started using many more of the features (each slowly tested, with world backups in advance for when things break horribly) - though I still avoid some of the more classically dangerous areas (crops, nuclear reactors) since something being stable in Build Y does not mean it will be stable in Build Y+1.
For the mods I use, most managed to update their IC2 APIs within a couple days, so that problem didn't last long for me personally. ymmv.
If you just want worldgen, you might want to largely pick one version of IC2 that seems to work for you and mostly just stick with it until you want to start messing with IC2's actual content. That way, you don't need to cautiously re-approach each new release, when you're not interacting with it. But once you do start using the actual content, then staying updated becomes much more important - but you do need to pay attention to the changelogs, and consider whether the changes mentioned seem more likely to fix things or (in the short term) break things.
Since you're on a server, you need to make sure everyone's on the same page about this, though - if *you* know no to mess with X system, but one guy is going to brazenly go after it anyway, that could lead to a lot of problems. And it needs to be clear that when problems do come up (for whatever reason), its largely up to you all to manage and deal with them on your own - support here is going to pretty much be limited to hoping for a kind samaritan in the stickied 1.4.7 beta thread.
That error means there's a .. circle in the chain of dependencies. ie Mod A must run after Mod B, and Mod B must run after Mod A, so it can't figure out what order to load them.
I know the Thermal Expansion release today could trigger that, though they released another version that fixed the potential cycle (but possibly broke some Forestry integration). If you happen to have Thermal Expansion installed, I'd recommend trying to update that ... otherwise, um, dig through the Forge log and hope you find something obvious?
As far as I can tell, the Forestry Bio Generator is broken. If you're driving a Forestry biofuel plant with EU run through optimized Forestry Electrical Engines at the nominally-ideal 2.5 EU:MJ conversion ratio, a Bio Generator running off the output doesn't produce enough EU to actually run the machines. If there's supposed to be a 2.5 EU:MJ conversion ratio, then the Bio Generator's output is more than an order of magnitude too low to be comparable to the MJ side of things.
iirc, that was essentially intentional. SirSengir's commented on the very different scaling of EU and MJ systems, and the Electrical Engine and BioGenerator are balanced with only the one-directional conversion in mind, and NOT meant to equate to each other. That translates into the system being lossy when run in a loop, as you describe.
When you're "just starting out" you don't have a generator and a compressor and an extractor and a canning machine.
Depends what direction you take ;). The generator and extractor are likely to be some of the first machines anyway, so it's just the compressor and canning machine that would be bumped earlier. In my case, it comes up when avoiding treefarms, solars, wind, and lava/geogens (geogens are typically my main powersource until nuclear). That made coal fuelcells seem the natural path ... but they just weren't worth it imo.
The tin cost of biofuel used to be the main deterrent to me, though nowadays that's less of an issue (since there's such a huge demand for copper, I'm left with a disproportionately large supply of tin). If you're fine with that cost, then ...
Compressor is 800 EU per item (I tested it). Wiki says the Extractor is also 800 EU per item, and no listing for the canning machine. So for a pure-biofuel cell, there'd be a 9600EU + (canning EU) cost to deduct from the 26040EU value of the fuel. So that's 16440EU, less whatever the Canning machine needs, translating to 2740EU/plantball. With a piece of (char)coal worth 4000EU ... aye, it's a lot of effort for very little payout. Straight burning the saplings in a generator would yield 1000EU per plantball (960EU for cactus/reed), so it is still a gain - probably around 2x-2.5x.
With the best (coal-based) fuel, at a little over 100k EU (gross) in a fuelcan, often ignored as not worthwhile, Biofuel doesn't have much chance in that arena.
The formulas for bio & coal fuel cells are nicely explained at http://forum.industrial-craft.…ad&postID=44599#post44599 . Old post, but still seems accurate.
The fuelcans, like the single-use batteries, seem mostly a relic of another era to me. They're occasionally useful when just starting out (if you've got an unusual set of available resources, or are just trying something 'different'), but from a raw-efficiency perspective (or min-max, powergaming, etc) they're pretty much ignorable. It's unfortunate, since they've got some nice flavor and the multi-step manufacturing would make for some nice automation setups.
The 8 EU/t from the solar panels would power any 3 of your machines, but they're only ouputting EU half of the time (unless you're using something to make it eternal day). Any buffered energy would run out overnight, and in my experience, if production exactly matches consumption without a buffer, the machines will usually flicker and work at less than max speed (I assume it's something about how the energy is packetted and distributed).
Redstone engines are much, much slower before they fully warm up (full speed is ~8x the start speed), so that probably explains at least part of your pump issue - in the pictures, the RS engines are still green which yields 1/4th their max output. Gold pipe carries 4x more liquid, rather than just 60% more (40mb/t for gold/emerald, versus 10mb/t for wooden/cobble/smooth). That said, in your pictures at least, the pipes look nowhere near saturated, so you're not being choked by the pipes yet. In any case, getting some kind of numbers for your version of Power Converters would help figure out if the system would work once the engines have gotten up to speed.
(TE Aqueous Accumulators would be a more reliable water source, if you're willing to add an extra mod.)
Though it wasn't in your list, if you have Railcraft, its loaders and unloaders make for wonderful automated breeder maintenance, especially with Buildcraft autocrafting tables.
Essentially, you have a Loader next to two autocrafting tables (one with the Depleted Isotope Cell recipe, the other with the Re-enriched -> Uranium cell recipe), set to Stock (not the default Transfer) at least one reactor load of components. It should load a unmoving (trapped/pinned by blocks, on a plain vanilla track) chest minecart, sitting on an Unloader adjacent to the reactor. The Unloader should be set to Stock the reactor with the appropriate number of components (e.g. 1 uranium cell, 4 depleted isotope cells).
Then you need a second loader/unloader pair, this time with the Loader adjacent to the reactor, set to Stock the cart with (some high number of) Re-Enriched Uranium Cells and Near-Depleted Uranium Cells. The Unloader doesn't need much for settings, just give it something to output to and manage the items as desired.
( =Loader, =Unloader, = Chest Minecart, = Reactor, = Autocrafting table, = irrelevant/spacer)
This has worked very, very reliably for me. It's even worked with a non-full reactor so far (ie filling it enough so there's no empty spaces before the uranium/isotopes, but leaving spaces after them), though maybe I've just gotten lucky with Minecraft's favored directions or somesuch.
Turns Breeders from a annoying maintenance task into a auto-magic resource generator :). The one hazard I've found is that if you connect the uranium-inserting loader/unloader pair on the side, as I have in that diagram, the Autocrafting tables are close enough to the reactor to be ignited if you're running it hot enough :p If you connect it to the top instead, that puts them out of danger (reactor top + 3 spaces, so only 9x9-size hazards would hit them directly))
I'm not playing creative... a diamond sword breaks a minecart on a single hit in 1.4.5 as well as 1.4.2. It is the 1.4.2 version of IC2 I have tested the chainsaw in, but I have experienced the problems breaking minecarts with chainsaws since 1.2.5 I think...
Stone and Iron swords break minecarts in 1 hit as well, so I assume it's a generic 'sword' attribute (haven't tried wooden or golden). I don't recall exactly when I first noticed the 1-hit sword breaking, but I think it was sometime between the Halloween Update (Alpha 1.2.0) and Beta 1.2_02, so it's been around for a long while.
(so to be clear, swords breaking minecarts in 1 hit is a vanilla survival thing, not creative or mod-related)
I'd suspect that Chainsaws not insta-breaking carts is intentional - chainsaws may make for excellent weapons, but in principle they're still axe/shears, not axe/shear/swords - the nanosaber takes the 'sword' duties. As is, chainsaws seem to be about the same as bare hands for breaking a minecart.
If a nanosaber doesn't break a minecart in 1 hit, that'd I'd hope was a bug :p
The 1.4.3 attachment to the OP seems to be missing, as the above poster mentions. I tried it a few hours ago, and again now, and it is still being listed as "File not found" (Firefox) or "Error 6 (net::ERR_FILE_NOT_FOUND): The file or directory could not be found." (Chrome). I'd guess something went awry in the upload process.
(As a side note, it seems like this *should* yield a HTTP 404 File Not Found response, but neither browser is actually showing me that - is this something different, or have the browsers just started hiding the HTTP 4xx responses?)
I would very much like to see it show stacked items, like the Heating Cells, while it's fairly easy to guess how many a breeder uses (even if it's not indicated on the thread for reactors) it does not seem to calc it correctly, nor indicate how many you need.
You can mouseover the heating cell in the grid, and the tooltip indicates the stacksize.
It does create an interesting experiment, though - designing a Mark I reactor that uses 0 gold, no more than 18 diamonds, and only single-cell uranium, with a minimum of 120 eu/t. Its easy if you go for horrible efficiency, like the original, or even if you go with 2 2x2 uranium blocks (for 120eu/t exactly), but if you go with a single 8-uranium pile (an extra 20 eu/t for 62 more heat), it's surprisingly challenging. I'm way too accustomed to relying on Overclocked Vents, and ignoring diamonds completely.
What are you supposed to do with the jar after you download it, though?
A modern install of java should let you just double-click the jar file to (attempt to) run it. Should also be a right-click option, called "Open" by default, to attempt to run the jar.
Double clicking it attempts to run the command (with a different path for the java executable if you installed it elsewhere, of course):
"C:\Program Files\Java\jre7\bin\javaw.exe" -jar "%1" %*
(%1 here translates to the name and path of the jar you're trying to run, %* just passes on any other arguments and can be ignored for our purposes)
So if double-clicking the jar doesn't work, manually running the above (either in a command window, or via a shortcut) should work. For example, assuming the jar is called "ICReactorPlannerV3.jar" and is in "c:\download\", you'd want to run:
"C:\Program Files\Java\jre7\bin\javaw.exe" -jar "c:\download\ICReactorPlannerV3.jar"
Beyond that, you could manually call the appropriate classes in the jar, but if the above doesn't work, there's probably some larger issue that's the actual problem.
They changed Redstone too, but that will not be a large Problem, as it does that internally far away from the used Functions.
As I understand it, the main redstone changes got pushed back as well, which probably helped limit the impact. ( tweet )
Edit- And I confuse a Generator and an Iron Furnace, whoops ><
I don't understand how you would say that the breeder is useless and I would lose too many uranium.
The OP's Efficient Breeder charges 84 depleted cells per uranium cell. (84 depleted cells + 1 uranium cell) / 8 depleted cells per uranium = 10.625 uranium. Subtract off one recharged depleted cell to account for the uranium cell spent to run the reactor, and you get 83 uranium cells out of 10.625 uranium, or ~7.9 uranium cells per uranium.
Your reactor charges 5 depleted cells per 3 uranium cells. By the same accounting, that translates to 2 uranium cells per uranium.
That's the "loss", that you turn each piece of uranium into only 2 uranium cells, whereas hot breeder can come very close to the limit of 8 uranium cells per uranium ore. Whether that's *important* or not boils down to a playstyle preference, but the incredible efficiency of the hot breeders gives them a large appeal - a single, badly-managed cycle will still come out ahead in terms of efficiency, will still yield a mountain of uranium cells, and thus will allow you to run the reactor in 'power' (as opposed to 'breeder') mode more often, yielding better average EU output.
His is efficiency 7 vs my 6.
So is 4 million EU worth 168 copper, 32 tin, 121 iron, 4 gold, and 12 Coal?
imo, at least, that's why yours wouldn't replace it. Sometimes you care more about efficiency than anything else, and that reactor is the list's entry for that scenario.
And if you're arguing based on UU-matter-equivalency, run the math on the neutron reflectors - they gain you surprisingly little, as their production consumes most of the EU they produce.
----
My current favored reactor:
http://www.talonfiremage.pwp.b…fjml70991g9orp0z9ksa34glc
250 EU/t, 4.55 efficiency
706 copper, 104 tin, 327 iron, 34 gold
The real gain, however, is that it only consumes 8 copper plates per cycle in the uranium - that's less than 2 quads would use, while producing more power at higher efficiency. If we use 400k EU as the cost of a copper plate (the cost of the UU matter alone, ignoring processing), that means we lose only 3.2m EU per cycle, yielding an effective efficiency of 4.25.
Compare, for example, with the Reactor9 from the OP: http://www.talonfiremage.pwp.b…adh05nlzbpykw84kwczan05q8
280 EU/t, 4.67 eff
769 copper, 99 tin, 331 iron, 64 gold
That consumes 12 copper plates per cycle, or 4.8m EU, yielding an effective efficiency of 4.27. Once we include processing costs to make those plates, it would drop further.
Edit - Total cost of a UU-matter copper plate is ~436.5k eu (using an Electric Furnace) rather than the 400k eu used above. With that revised number:
* My reactor loses ~3.5m EU per cycle for an effective efficiency of 4.23 (4.228)
* Reactor 9 loses ~5.2m EU per cycle, for an effective efficiency of 4.23 (4.230)
The problem seems to be that cooling cells don't store enough heat to make them worth using, since your going to need to use an exchanger anyway you might as well use a vent instead. If its not an MK 1 its going to be an MK 5 with a ridiculous cooldown time, and if it isnt an MK 1 or 5 than a component vent or 2 will fix it.
That does seem to be the core problem with cooling cells - a 60k coolant averages out to a regular heat vent, so they only shine in a Mark III or Mark V. Without RedPower, Mark III & V are far less appealing, especially given how slim the gains are now. I'd disagree about the "ridiculous cooldown time" part, however - the incredible heat output of adjacent quads tends to mean you've got an impressive cooling system, so once the reactor shuts off, all that can be applied to the cooling cells.
----
I started out disagreeing with you, but after doing a bit of study I could possibly agree that when duel/quad lifecycles are fixed the copper required won't be too much. This doesn't go for reflectors though, those things just aren't worth the copper.
For Copper Plates, it looks like they each cost 400k EU (or more accurately, ~430k EU including the Recycler - still need to factor in macerator and compressor to be truly accurate):
So a Quad costs 2m extra (5 plates * 400k EU/each). A 2x2 of single-cells is 3 eff, as is a quad, meaning you lose 2m with the Quad. Adjacent Quads is 4eff, gaining you 4m over using 8 cells (3.5 eff) ... which is exactly as much as you spent on Copper Plates (excluding processing). So to actually get a *gain* from Quads, you either need more of them, or a more complex arrangement (e.g. a quad with adjacent single-cells). That's much worse than I'd expected, so thanks for getting me to look more closely at the numbers >< It does still provides a relatively efficient copper->EU conversion, though, which can be circumstantially useful, and of course it does create a more compact reactor layout, allowing for more cooling components.
Ignoring processing costs (macerating, compressing, recycling), a Reflector costs 4.2 UU, or ~700k EU. Each Reflector seems like it would yields a raw 1m EU extra, translating into a ~300k EU gain. While the processing costs will eat into that, I suspect the Reflectors are still a gain overall, but probably not a large enough gain to be worth the hassle. I expect the Thick reflector is a net loss or negligible gain, as the 400k EU copper plate would probably consume any actual gain from the four reflectors.
All of this, of course, presumes you need to account for the materials consumed. If you're just burning what you dug out of the ground and would otherwise sit unused in a stockpile somewhere, then most of these 'losses' could evaporate. That's largely a playstyle preference, but useful to keep in mind with respect to the value of the feature to players overall.
----
I didn't see you disagree with my statement about suggesting that cooling components should be more efficent then cooling the core. I'm thinking now thats really the main point of what I want to change. If storing heat in coolant cells and slowly cooling them was better then just grabbing heat from the core, things would be more interesting.
Something to make reactor design more 'interesting' would certainly be welcome. Personally, I think the Component Vents are the primary source of the problem, because they provide a unique and incredibly powerful capability (moreso, imo, than the Overclocked Vents, if only one of the two were present).
You essentially seem to be suggesting a world which heavily favors Mk II, III, and V reactors over Mk I, which I agree would be more appealing. How you'd actually balance that, I have no idea, and figuring out how to make such a system *work* is a large obstacle.
For both breeders and non-breeders, the uranium can dump its heat into one of two places - an adjacent, heat-holding component, or into the core. Most designs have the uranium dumping their heat into the core (in part because the uranium might be surrounded by other uranium, and in part because for the larger reactors, any component directly receiving all the heat would quickly melt). Thus, you need all those components with core transfer to extract the heat back out of the core, so you can spread it to your cooling components.
(You can also use the core exchange to shuffle heat around the reactor. This mostly shows up with Overclocked Vents, where you can potentially wind up pulling more heat out of the core than you can cool locally, so you put some of it back into the core with Exchangers to be re-extracted by components in a different area of the reactor.)
The core of the designs is homogeneous - a grid of component vents and overclocked vents - but the edges are where the variation comes in. If you've got ample gold and space, then you just remove the outer overclocked vents and you're all set, but the 'interesting' cases are how you handle it otherwise, how you shuffle heat around the edges. Right now those designs are all frowned upon, since their costs are enormously compared to the (incorrect) 'cheap' overclocked vents, but once that display issue in the planner is fixed, I have hope Reactor Exchangers and the like might get a lot more use in the highlighted designs.
Before, the bulk of your non-casuc reactors were various combinations of heat dispenser-cooling cell 'plus' shapes, (the coal balls are just for spacing)
Successful designs were mostly about how best to pack those around the uranium. Now, you're mostly deciding which resources you want to spend as you design the edges of your component vent-overclocked vent grid, exchanging between gold, copper, and iron, depending on which style of cooling you prefer, with gold being the most space-efficient.
I do miss the Mark II and Mark Vs, though. I figure the lack of RedPower doesn't help (since it makes Mark Vs sooooo much easier to manage), but there just aren't many places to store heat for Mark II and Mark III to take advantage of. All the Mark IIs I've made have basically been Mark I reactors with one piece removed - and that cost savings is negligible overall. If there were some way to automatically swap out heated components for fresh ones, that'd be very useful ... but it would basically be a CASUC that used a cooling reactor instead of ice compressors.
----
Duals/Quads (assuming the lifetime bug is fixed - and they have acknowledged it's a bug) and reflectors are about which resource is more valuable to you, the Uranium or the copper. In principle, copper is renewable via UU matter, whereas uranium is not. So the premise of spending copper on increasing the output of the uranium has appeal (I *think* it's still a net gain, even with remaking the copper out of UU matter). However, if you've got ample uranium, then of course they would have far less appeal.
----
Edit - The lack of full, 6-chamber designs seems to me to be because of the way heating scales. With Quads, your heat skyrockets as you add more adjacent uranium, so you quickly go from a reactor that you can cool with ~2 chambers, to a reactor that even a 6-chamber can't cool with diamonds. The 6 chamber designs seem to mostly be multiple copies of 0-, 1-, and 2-chamber reactors stuck into one 6-chamber reactor, rather than really creating something uniquely larger. The single-cell uranium (ie non-dual/quad) reactors seem to be the only real area for 'true' 6-chamber designs, and they haven't gotten much attention in the 'good reactors' threads.
Are you any close to fixing this bug? I'm pretty sure it's why the planner is claiming my heat exchangers are melting
Edit: I take that back, still seeing melting heat exchangers where there are no heat injectors: http://www.talonfiremage.pwp.b…99hgcbu76nl690l1t8mglkbjq
The bug is with IC2 v1.106 - the Reactor Planner is just accurately reflecting that behavior.
And that linked reactor melting makes sense to me, because there are two platings *after* the melting reactor exchangers. Once the hull gets past 12000 heat, those exchangers will see the hull at over 100% heat, so they'll try to match that percentage ... which means they'll melt themselves. And with the ordering of the exchangers versus the heating cells and uranium, the hull will go over 12k heat - only slightly, but a slightly melted exchanger is still melted.
If I understand what you're saying right, that's intended behavior.
Though the reactor updates all its components once per second, in one batch, it does *not* update all its components 'simultaneously'. Each time the reactor updates, it goes through the reactor components in sequence, starting from the upper-left, and processing the whole row before proceeding to the next row. Thus, components that are processed before heating components will see a different situation than components afterward.
For example,
(Reactor Heat Exchanger) - (open space) - (Quad Uranium Cell) - (open space) - (Reactor Heat Exchanger)
When that reactor is first started, the heat exchanger on the left will see the hull at 0 heat, whereas the one on the right will see a 96-heat hull. As time goes on, the distinction matters less and less - as the overall heat grows, the small delta between the two exchangers becomes relatively small.
Overall, this behavior does drive a lot of reactor design, since being unaware of it can lead to some components 'mysteriously' melting while others have ample heat capacity left, etc. It's also why most (though not all) reactors put their uranium cells in the top-left corner, and any components that are supposed to retain heat in the bottom row - that setup leads to behavior that many find to be more intuitive. It's certainly not required to do things that way - and there can often be savings from organizing things differently - but it's a useful bit to remember.
