miner already have this setting, valuable ores section
Except that is done outside the game; which means that if you find out you are low on dirt/cobblestone for some reason, you have to either dig it up yourself, or exit the game, edit the file, re-enter the game and hope that your other miners are turned off. I personally like the idea of customization ingame.
U-238 is combined with flourine and gassed to produce less than 5% U235 for reactor use, continuing the process will eventually bring the yield up to 90% (weapons grade).
In my opinion, this would give the electrolyzer something to do. My suggestion is to have the following steps:
- Mine U-238 from the ground (the little green balls, yay)
- Macerate to produce 2 yellowcake (yellow dust, similar to all the other dusts)
- Combine 1 yellowcake with empty cell to produce 1 yellow cell
- Put yellow cell in electrolyzer to produce a fissile cell
- Put fissile cell in furnace to create fuel rod
- Put fuel rod in reactor until they turn into depleted cell
- Combine 1 yellowcake, 1 depleted cell and 1 empty cell to create 2 yellow cells and repeat above (yep, double your load after the first cycle -- normally you would have leftover cake at some point in the cycle, this is to simulate that in the re-enrichment process).
Also, the GUI for the reactor isn't exactly how one works. In a normal reactor, you WANT heat in the system in order to create steam to produce power through a turbine and THEN you cool it. How about a new recipe first, the turbine:
.A.
AEA
.A.
A - Advanced alloy
E - Electronic circuit
Now the reactor...the updater (done every tick or second/configurable) can go through each item in the GUI one at a time and perform certain actions based on what it finds:
**Fuel Rod**
deplete 1 unit
start 'value' at 1
pick a direction and go along that path checking for objects:
- Fuel Rod: deplete this by 1 unit, increase 'value' by 1, pick a direction from here and keep going
- Water Cell: deplete this by 'value' (if unable, add as heat to the reactor hull), done moving
- Piston: if reactor has redstone activation, add 'value' to the reactor hull heat and finish moving; otherwise, ignore this block and keep moving
- Integrated Reactor Plating: add 'value' to the heat of the plating
- Anything Else: add 'value' to the reactor hull heat, done moving
**Integrated Reactor Plating** (IRP)
if the reactor hull heat is greater, it will move up to 50 heat to itself from the hull
if its heat is above 50, look at the 4 adjacent objects (if applicable):
- Water Cell: deplete it by 5 and reduce IRP heat by 5 if able
- Integrated Reactor Plating: balance up to 10 heat between them (it'll end up being 20 since both IRPs will "run" the same algorithm)
- Coolant Cell: deplete it by 10 and reduce IRP heat by 10 if able
- Anything else is ignored
**Integrated Heat Dispenser**
if the reactor hull heat is above 50, look at the 4 adjacent objects (if applicable):
- Water Cell: deplete it by 8 and reduce hull heat by 8
- Coolant Cell: deplete it by 12 and reduce hull heat by 12
- Anything else is ignored
**Coolant Cell**
restore 1 point of depletion
**Turbine**
check each coolant cell adjacent and add up their depletion count as 'deplete'
check each water cell adjacent and calculate how much to restore them as 'restore'
using the lower of the 2 values:
- deplete the coolant cells by this value
- restore the water cells by this value
- create a packet of EU based on this value
**Other objects**
ignored
After each object has been checked for, the reactor will then go through a hull check phase (in order):
- reduce hull heat by 1 plus 2 for each added chamber plus 1 for each water surrounding it plus 0.25 for each air surrounding it
- if hull is above 200 and contains ice cubes, it will use one up and reduce hull by 200 recursively
- if hull is above 500 and contains water buckets, it will turn it into a regular bucket and reduce hull by 100 recursively (yes, just like real life, boiling water doesn't cool things down, just keeps it from going over a specific temperature once the water starts boiling)
- at 4,000, any item not related to reactors (or stated in this area) are destroyed
- at 5,000, Any buckets turn into 3 Tin Ingots (even if you used iron to make them, iron is more valuable), also water surrounding the reactor begins to boil off
- at 6,000, all pistons are destroyed
- at 7,000, Turbines turn into 4 Mixed Metal Ingots (base construction minus a few things due to burn-off)
- at 7,500, Water Cells turn into Empty Cells
- at 8,000, Integrated Heat Dispensors turn into 2 Mixed Metal Ingots
- at 8,500, Coolant Cells turn into Empty Cells
- at 9,000, All Empty Cells are destroyed, and 1 tin ingot is placed for every 4 of them
- at 9,500, Integrated Reactor Platings turn into 1 Mixed Metal Ingot
- at 10,000, reactor goes critical
Values of course subject to change, just as an example. A good hull design would consist of placing Fuel Rods next to each other separated by pistons in order to create as much heat as possible (and when redstone is supplied, the pistons block the rods from reacting with each other, so the reactor produces far less heat, but still there in small amount) and then wick the heat away with IRPs. Then you set up Water cells near the IRPs and IHDs in order to soak up the heat, then put a turbine between it and the coolant cells in order to create the power. The more heat you can produce AND cool each update, the more power your reactor can be....and the setup in the GUI would look very much like real life this way.
I like the idea, but make it a GUI inclusion/exclusion type thing (similar to advanced wooden pipes in the AdditionalPipes mod). To counter the OP nature, you could have the device require more EU for each block being scanned in the inventory slot.
It would also be nice if you could backfill foam (maybe from the foam gun) in the same area as defined by the scanner that is in the device....although this is not entirely necessary, but if you venture into a cave and see foam, you know that you mined that spot (or possibly creating an easily sculpted tower/mineshaft/whatever).
How about this, a MFS-ND (an MFS with Nether Distribution capabilities....going along the lines of the MFE->MFS chain). When you place one of these in the world, it creates a unique identifier for it, storing its location/map/whatever in a file/metadatathing. A list of these IDs of the world can be created (loaded by server) that store an EU value for how much the unit currently has. Also, when you place one of these objects in the world, a duplicate is created in the nether at the correct relative location (avoiding obsidian blocks to avoid portals -- this may need to be offset to insure that portal reconfigurations do not destroy these blocks, or at least replace them when it does occur). If the world is not loaded (SP for example), then it will create it when the player goes through a portal (the ID list isn't going anywhere at this point). If you dismantle it, the object is automatically dismantled in the other world as well (it is taken out of the ID list and put in the "dismantle" list if in SP or unloaded....when the player moves worlds, the 'dismantle' list will run to destroy it then).
What does it do exactly? Simple, it acts exactly like an MFS in all aspects, but with a "global" EU value in the ID list. The only down side is that if the 2 worlds are not loaded at the same time (i.e. SP mode, or no one is in the nether), then the updates will be only one sided. If all machines in IC2 were placed in a build-list, then you could have global mechanization at all times under throttle control (reduce lag and have just pure awesome spewing out)....but I doubt the creator will implement that (and if he would like to and needs help *coughs and points to self*). As for now, a trip back and forth to the nether will be required to see any results.
Since the device is already nether linked, I imagine the recipe would look like this:
O
O
O
. O F
. - nothing
O - obsidian
F - flint&steel
The problem I foresee in giving high-end pulses for solar panels is it negates the effects of power loss in a system. Currently, if you have a strip of wire (41 blocks of tin, 4 of copper, 6 of ins copper, etc. etc.), it will lose the 1 EU of power that the panel generates before it hits a machine/node. If your suggestion were to be implemented, then the energy would build up over any gaps of loss due to distance before being transmitted. Although the efforts of reducing lag should overshoot the possible "cheats" or overpowering that comes out of the system, those things still need to be taken into account.
What could be done is send X "packets" of 1 EU each every X ticks for each solar panel. There's actually just 1 packet that needs to be delivered containing a 1 EU value, but also contain X EU as a side data point....if the 1 EU is diminished, then the packet can be discarded and all X EU is lost anyway. If the packet arrives safely to a machine/node, then it can give its X EU value instead of the 1 EU.
I don't think this seems too "sci-fi" but rather a little alteration/refinement is all that's needed.
What about a laser emitter/receiver blocks instead?
Emitter:
Allows up to HV input and can store up to 1M EU. When supplied with redstone, the unit remains in the 'off' state (so that it is 'on' as default when placed). When the unit is put in the 'on' state (when placed or redstone first supplied), it will wait until it has 10,000 EU stored first (threshold, mainly for lag purposes, but can be seen as the warming phase of the laser unit), at which point it switches to the 'ready' state. At the 'ready' state, the unit will attempt to use 600 EU/t in order to emit a 512EU beam on its output face (yes, a 14% loss due to cooling costs). If the unit ever dips below 600 EU in the 'ready' state, it will switch to the 'on' state and wait for the threshold again. A wrench can be used to orient the blocks emitter direction, all other faces are power input.
Collector:
I was thinking of a design that requires compressing a solar panel, but that would make no sense logically speaking, so instead the pattern should require multiple solar panels and glass (to act like a prism) in a TNT type setup (this is to make it expensive but not entirely impossible or unrealistic). It has a collection face that can be oriented with the wrench, and when hit with a beam, it will supply power (or store up to 40,000 EU locally...aka the 4 batteries used in the solar panel design). When it reaches above 80% power (32,000 EU) in 'empty' state, it switches to 'full' state and emits a redstone signal, and when it reaches below 20% power (8,000 EU) in 'full' state, it switches to 'empty' state and stops emitting a redstone signal. These state switches are an option for those who use redstone emitters to converse a signal in order to turn on/off the emitter (excess 'beams' of power are wasted if the collector is full).
A beam can be either a dedicated block (similar to the force field) or simply a visual one (similar to buildcraft's marker lines). I suggest the latter for lag reasons (creating/destroying/moving blocks in SMP constantly could be a problem, while a visual change is done client-side). Further, the lag can be reduced by placing emitters in a queue and doing a small check each tick rather than constantly forcing MC to update blocks. Pseudo-code would look something like this:
Because the beam emits 512EU, it can be considered low...so no harm will come to you or critters that cross it. To expand on this idea, you could introduce KEU beams or MEU beams that would kill things or even destroy landscape.
