Display MoreMC crashes when I try to run 3.1, but runs fine with 3.0
Error report:
I see it says i need 1.2.4 of forge, which is what I am running.
I've gotten the same error message. It seems to happen when I had ScotTools installed. The patch ScotTools requires seems to rename the MCForge version number back to 1.2.3, so even though I'm using 1.2.4 underneath, probably this addon can't see that with the new name.
I'm no Rocket Scientist
but I think it would make more sense for the Uranium thing to yield Tritium or Helium-3, which are radioactive, unlike deuterium.
I know, but then there'd need to be a use for Tritium in the Fusion reactor.
Although...
there ARE two fuel slots in the GUI. Maybe it can require a deuterium cell AND a tritium cell in order to fill it. Generate Deuterium the normal way, and need Tritium as well. I also came up with another possible idea for Tritium cell creation. Perhaps this mod can modify the fission reactor to produce tritium cells from any water cells put into the chambers after the completion of a cycle. I'm not sure how long the cycle times of the two reactor types compare, but having a small reactor dedicated to tritium production should be able to keep up with the demand from a fusion generator or two.
Since I decided not to bother with making a fission reactor, I have a big-ish stock of Uranium taking up space in my chests. Would it be possible to make a machine that takes the water cells and lets the Uranium pumps its neutrons into them to make the Deuterium cells? I also didn't much care for the low ending output of the deuterium extractors, or all the empty cells to manage. I know this isn't quite how it works, Wiki says that's more for Deuterium to Tritium, but this is Minecraft, accuracy need not apply.
I had two ideas on how it would work:
put the uranium cell in the center, have a ring of water cells surround it. Wait a while while the fuel cell ticks its way down to depletion, while the water cells become deuterium ( perhaps with a intermediate stage or something)
The other one is more like a furnace GUI. put uranium in the bottom, water n the top, deuterium comes out the side. It'll consume the whole Uranium to charge the enrichment bar enough to do maybe 8 cells at a time or something.
miner already have this setting, valuable ores section
I've found this in the config. I'm not completely sure how it works, though. I see the first numbers in the pairs are the ores' blockIDs. Are the second numbers in he pairs the seconds the miner will spend to dig the ores? If so, than it seems this thread has no point, as IC2 already had what I was looking for. (Wish I had been able to find more info on the config file.)
Why does silicon have to be some kind of block? Can't the silicon products just be items? There's thousands of itemID slots, aren't there?
I've found that in certain area, EE and IC2 play very well together. EE lets you turn cobble into redstone and coal to make your machines, and even provides lava for your GeoGen. Once you're collecting diamond for your dark matter, convert your diamond ore into gold ore, and then macerate it to get twice as many diamonds than placing and digging the diamond ore to get your diamonds.
When I was pumping up an oil pocket with this, I had buckets and empty cells in my inventory. It seemed that after the buckets were filled with oil, it started filling cells. Unfortunately, it turned the oil into water cells 
I see the idea for BC oil -> coalcell has been shot down already, so would it be possible for the pump to ignore filling cells just for oil?
And, I have a suggestion: have a key to toggle between modes. normal mode fills buckets / cells, secondary mode empties them into the BC tanks. If you have a set of combustion engines in such a location you don't want to / can't make a pipeline to it, it's be nice to be able to quickly suck up lave from the central storage tanks, then quickly fill the lava tank. As of now, this device can only do half of that, I think. Fill up an INV of buckets in seconds, but have to manually empty them into the tank.
Of course, there'd have to be a way to check what's in the tank, first, to be able to fill with the right liquid. If the tank is empty, then just use the first liquid stored in inventory.
Also, maybe include being able to fill tanks from cells. Not sure if it should return empty cells or not. Perhaps after any buckets are emptied, consume cells to keep filling tanks to balance it out a bit.
Edit: and howsabout compatibility with the batpack?
Reading Wikipedia on processes for making electronics-grade silicon, the only process that I thought could loosely translate into the technologies available in minecraft was the zone melting process, involving heating only a section of the crystal to force the impurities to gather on one end, which is later cut off. That's why I suggested an electric or better furnace, to get the required temperature levels and heat control. Of course, it'd be a shame not to also make use of more of the wonderful devices in IC2, so there's certainly the space for more steps. At least there's plenty of IDs for items, so making levels of partially-processed silicon would only be a bother for coding.
And, let's not forget that electronics-grade silicon could have more uses than just for our solar panels. I suggested that maybe using it as the corners for the Advanced circuit recipe. Or, perhaps, combine silicon, tin wire (high-end components nowadays operate at a level ~ 5V) , and a rubber / carbon casing to make semiconductor-level components for something-or-other.
I had another solar-panel idea that could be integrated with this one. I was thinking of a recipe for a higher-tiered solar panel with the recipe of:
Where the furnace was the generator, the force-field was Notch's glass panes, and the iron ingots were a new item for IC2, Silicon crystal. Since IRL solar panels have different efficiencies depending on their manufacturing methods, I was thinking that using actual silicon would produce more energy than a carbon-based panel. The silicon would be processed from sand, perhaps by smelting glass in an electric or better furnace for a few rounds to progressively burn off more impurities. Silicon could also be used in the future as a component in advanced circuits and maybe other things as well.
The full-chambered reactor didn't work so well, since Buildcraft's pipes don't recognize the added reactor chambers as a pipe target, and leaving one side of the reactor open has the same problem as before. But, thanks to Alblaka's explaination, I see this isn't IC2's problem. I guess I'll just to stick with a 0.5 less efficient better-cooled reactor unless BC's pipes get smarter.
Additional clarification: the 'rejection' isn't like the normal problem with BC, where something is full when the item tries to go into it. In that case, the item falls loose when it hits the end of the pipe. What's happening is the cell is accepted into the reactor just fine, but then is immediately spat out of the top, like it would if you tossed coal into it or something of that nature.
I think I see what you mean. I'd always been using my diamond drill for the miner, and forgot that it depended on which drill it was equipped with. Does that mean the drill would have trouble with other mods' blocks even without the miner? ( I don't have any custom-ore-supplying mods to test this with.) If that's the case, that does present a bit of difficulty. It wouldn't do to give people chance to make a super-drill by setting the speed for all the blockids to max.
Although... perhaps there could be some integrated limits on what the config file can do, such as a maximum drill-speed limit, and ignoring any blockids that match the vanilla / IC2 ores to prevent changing the drill's normal performance.
Another idea that may or may not pose a bit more hassle is to make a third drill style, with some fancy material set (advanced alloy, advanced circuit, energy crystal?), that can be used for all configurable custom needs, leaving the the original drills as they are.
Initially, I had it pumping into the top of the main reactor. In my little test, I tried connecting the pipe to both the top and the side of both the reactor and the side chamber. As expected, the pipes ignored the side chamber, but connected fine to the main reactor. However, no matter which entry point to the reactor the cells came in from, they were tossed out after the top row was filled.
As for each chamber being treated as a separate inventory, I thought the chambers' inventories were organized vertically; three columns for the main reactor, and one for each additional chamber. The pipes were filling only the top space of each column before rejecting more; all four columns, the three main and one extra, had one cell in the top, so it wasn't ignoring the external chamber's part.
I was trying to automate a -SUC reactor by having BuildCraft pipes keep feeding it with a steady supply of fresh coolant cells to replace burned ones. For some reason, it seems only the top row of the reactor's inventory will accept cells. I built a little test setup with a reactor with one external chamber. I got 4 cells along the top only. Any additional cells piped in are spat out of the reactor as though it were one of the items that don't belong in a reactor. Is this a bug with the pipes, the reactor, or just something to prevent automation?
Not sure what part of this would make anything faster. Just figured if someone added something like the Fossils mod, that they would like to be able to have the miner actually drill for fossils, rather than just happen by them while aiming for other ores. Or, if someone really wants to spend the EU, and doesn't have Buildcraft's quarry, to be able to dig all the dirt/gravel/cobble under the miner.
Although, not sure if Fossils is the best example. I think it drops bones when dug, not a fossil block. I'm not sure how the miner handles digging. If the miner having the difference between metal ores that drop ore blocks and stone ores that drop items is hardcoded, that may be a hassle to add compatibility with mod ores. On the other hand, if it just looks to see what the ore is supposed to drop when dug, and produces that, it might be easier to implement.
Basically, it's adding a config file [mainly a list of blockids] that sets the target blocks the miner will dig for as it's running. That way, if someone happens to be using a mod that adds new ores, they can make it so that the miner won't ignore them.
