I meant that the process of turning something into lava should maybe remove some heat from the reactor
Reactors have been made not being affected to outside environment (at least that's what I believe). And, this is like an outside vent, a random one that doesn't need much materials.
although I currently see no way to keep a reactor powered at 85% because whatever block you put the redstone on melts.
You can power the reactor through a repeater and a block, and use a cobble generator to constantly replace the block once it melts, or you can use the configurable redstone behavior of EU storage blocks, plus some redstone and wiring. I mentioned before that te blocks don't get affected.
I mean it could remove the lava's worth in HU at least
Why do you want that? You want to remove the only way to get basalt (besides replication) as of now?
and not turn flowing lava into source blocks
That sounds reasonable.
so at least a dormant reactor can't be an infinite lava source.
A heated dormant reactor can turn every single block (except air and te blocks) to lava. It is an infinite lava source anyways, it just depends on what blocks you want it to turn into lava.
Expensive replication of obsidian is due to its rarity in terrain generation. Again, as lava is very cheap in the nether, and it is simple enough to turn lava into obsidian, who want to replicate obsidian?
I don't think that the infinite lava is OP, and as far as I know this isn't even considered a bug. I had already considered utilizing this to produce EU, but I found it is much more productive utilizing the reactor to produce EU, running on replicated fuel rods.
A large amount of lava is required only at early-mid game, but a reactor needs a lot of Lead, making it difficult to craft during that period. However, there are plenty of lava in the nether and they're easily accessible via a pump, which needs much less materials. Although the lava amount in nether is finite, but how can you use up all of it?
In my opinion, creating lava with the reactor is a great idea, offering a completely automatic way to create renewable lava, basalt, and obsidian, while still needing some infrastructure. What I have thought was to use a cobble generator, with a bunch of dispensers , observers, and fluid cells to collect the lava, which needs some material investment. Creating lava simply through machine simplifies things too much. Considering that lava isn't needed that much in late-game (unless you're making a portal pigman farm), I am against the idea of a lava-creating machine and keep things as-is.
Apparently he means that he want the induction furnace and the crop harvester to support the transformer upgrade. (I'm using a translating software, so I might get things wrong)
My suggestion: Put a EU storage machine like MFSU or MFE before the transformer. I'm not sure if it works but I think it is worth a try.
The texture of the bronze tank is pretty strange, especially the middle rectangle-shaped thing, right? I thought that it looks better if the textures are more similar, so I slightly edited the texture to make it look something like . I would like to see this texture getting implemented.
Isn't that better?
First of all here is the reactor layout that I use and some statistics by the reactor planner:
Mark V pulsed reactor, operating on a 5-sec on 2-sec off pulse with an average efficiency of 40
So... After about 5 months of building and testing (The oldest backup I could find dates back to early March this year), I think the automation is reliable enough, at least that was what I thought, for me to finally release this build, which is literally a redstone mess.
In this build, I had automated the warmup process, fuel rod replacement and recycling, and optional fuel rod crafting completely only with IC2 and vanilla Minecraft. The principle of the automation of warming up is quite simple: by removing the vents and putting them in after the reactor is warm enough through redstone control, the reactor can automatically warm up and run at above 50% heat even after it is turned off. As the reactor itself is almost undetectable without other mods, things can still be detected through redstone circuits that controlled the reactor. I'm not going to go through how other things work because they should be able to be easily understood by just looking at them in the world.
The reactor and automation circuits are built within a single chunk, but redstone related with the reactor control room (which are built in cyan concrete) and part of the redstone controlling the crafting system extends into another 3 chunks as I don't think not loading these will cause problem. I haven't tested what will happen if only the reactor chunk is loaded yet. Therefore the chunk loader within it is set to load all the 4 chunks. Slimestone is used in some parts when wiring is too difficult or I'm just too lazy to do the wiring. These can be replaced with redstone dusts. Also there are a chest with low durability rods at -1, 31, -1 if you want to watch how the fuel rod automation works. Remember to middle-click them
Normal running, scanned for 45 secs
Warming up, scanned for 45 sec (roughly the warmup time)
There are still some problems I found out but I have no solution. Any help to solving the following problems is greatly appreciated.
1.Occasionally there was an extra pulse in the main clock that controls pulsing. I haven't figured out the exact cause of this yet. Although this won't cause the reactor to explode, sometimes the reactor will cool down because of this extra pulse, causing the efficiency to severely decrease.
2.Chunk unloading and reloading causes issues. When the chunk that has the reactor is reloaded (player entering the area, F3+A seems to have no effect), the clock will de-sync with the reactor, causing it to eventually cool down. There is a rare chance that this will cause the reactor to explode. In theory enabling the chunk loader should be a way to solve this issue.
3.Vents occasionally mysteriously disappear or reappear. Although it is designed to only turn on the reactor when all vents are extracted from the reactor, there is still a chance that the reactor continues to be on when there is a missing vent, which will break the heat balance and make the reactor explode. The only chance of this happening I found out is that the vent(s) get stuck inside the droppers which are responsible of putting the vent(s) back into the reactor at the proper time.
Apologies again for the redstone mess.
So, im kinda new here...
I have lately been experimenting with reactor designs (fluid) that are hyper-efficient and here's what I came up with:
Any suggestions on improvements? ( i put containment reactor plating cuz i didn't know what to put there...)
First of all, for a beginner like you, it is amazing of you to come up with such a efficient design (especially looking back at my first designs, which are truly awful). However, the major problem of your reactor is material cost - there are already mature designs with exactly the same efficiency, with less materials. This is mainly caused by your excess heat exchangers and low venting efficiency.
For example, the difference is quite obvious when the design that I use is compared with your design.
Random Questions Section:
1 the simulator places the max efficiency of this at 29... what causes water reactors to be amped up so much?
2 is the simulator accurate?
3 are the 5 3x3 cooling units (the component heat vent, overclocked heat vent and component heat exchanger in the middle groups) as efficient as tiled component heat vents and overclocked heat vents?
4 is it possible to do component automation with only ic2?
5 (i keep editing this post to add more questions)
1. Fluid reactors' (or "water reactors" as you called) output are based on heat the vents vent, while EU reactors are based on fuel rods. The output of the EU reactor is throttled by 50% (according to the in-game tooltip) because fluid ones are complicated and more costly to set up.
2.Personally I think the simulator is quite reliable. You can ask MauveCloud about it as it is he who programmed the simulator.
3. No. The component heat exchanger takes up space and does nothing except preventing the vents from breaking. Also, the vents will break when there are always excess heat in the reactor core.
I checked your map, i loved the way you stacked all reactor and your mox design but you use a lot of redstone which as you said can cause lags and i don't find it a good way to automate ic2 stuff .
Redstone dust itself doesn't cause a lot of lag, it's turning it on/off that cause lag due to the tremendous amount of block updates that it cause. For the machine part, I have tried to optimize the lag when it's idle wit the help of LagGoggles.
I modified a bit my design, now i'm using a weighted item distributor to send iron plates in priority to canning machine then batch crafter, it makes a buffer of 128 iron plates but for now it's working but i wish the sorting machines would be able to also sort quantity (i'll make report on mantis, in case it's a bug).
I think it is better for you to make a thread in the suggestions forum, since this is more like a feature request/suggestion than a bug.
For your EU issue, i know the splitter cables doesn't work, you still can use 2 transformers to achieve the same goal but beware of wrong wiring (RIP my old mining factory, only 1 machine wrongly wired on 2048 instead of 512 destroyed the entire building ).
Since my map has 20 reactor in it and each generates about 600 EU, I don't think that a few transformers will work because of the extremely high amperage (and it will be bigger if more reactors are put in there).
If i put a stack on iron plates it will seperate this stack at 33% on the north and 66% on the top so my design would work but if i put iron plates one by one (like a metal former) it will send everything to the north, i don't know if it's a bug but i would like to be able to send exactly 1 iron plate on north then 2 iron plates on top.
Any ideas ?
You could use hopper minecarts and hoppers to distribute the items into the exact amount that you want with a cost of a comparatively high lag.
Actually, I've made a fully automatic MOX reactor including fuel rod recycling, uranium production, etc. The reason why I haven't shared it yet because sometimes I stumble into problems like the EU stop flowing and I haven't finished the product treatment. This is like a pre-release version and I currently cannot guarantee that it will work 100% (and probably in the future).
Players generally don't like the idea that if they set up a component production line, it will consume inputs until every machine input and output along the way has a full stack of intermediate products. As a result, they tend towards overly-smart logistics networks like AE, where the network is in charge of putting exactly the right inputs in so that nothing gets wasted, but I think that it would be nice to have the Factorio-like option of letting full inputs produce natural backpressure with an acceptably-low overhead, so everything can pull directly from storage.
I don't like item stacking mainly because if hoppers are involved, they will create a tremendous amount of lag (often more than 100 μs per tick per hopper). However, I personally like to use redstone to lock the hoppers when they aren't needed to reduce the lag, and I avoid using other mods whenever possible. Also, no thing is wasted - the items there just don't get used.
Your idea about the stack size limit is great, but I think that the accept limit is better to be (64 - N) * one craft, and the output threshold (63 - N) * one craft, otherwise only 1 upgrade is enough.
I don't know how best to handle cases where different recipes take different counts of the same input item, perhaps a "recipe lock" upgrade would also be useful.
I believe an IC2 machine only take one recipe at a time. I like the recipe lock idea as it can act as a item filter.
Slightly changed the design posted by vlad[54rus] and I managed to increase the efficiency. Also changed an unnecessary adv heat exchanger into a normal heat exchanger.
1407.67 HU/t, efficiency 14.66, 1 reflector
I get the impression you're not a programmer, otherwise you probably wouldn't have even suggested this:
"3. Simulate my manual calculation (The most complicated but accurate if done correctly)"
Yes, I'm not a programmer, but I have some programming experience.
Details on how to do it:
1.Divide the components into sections (components in separate sections cannot exchange heat directly except through the reactor hull)
usablevent cooling (limited by heat exchanger transfer rates), hull cooling for each section
3.If a section contains components directly heated by fuel rod(s):
3a. Calculate heat generation of the fuel rod(s)
3b. If vent cooling + hull cooling >= heat generation then add vent cooling of this section to output
3c. Else ...
4a. If hull cooling <= vent cooling then add hull cooling of this section to output
4b. Else add vent cooling of this section to output
EDIT: My ideas on section division: Make separate sections as lists
Start with the left-top component
.1.If this component can accept/generate/transfer heat (excluding the component heat vent) then
...2.If this component is in current lists then
.....2a.Go to 1 and check for the next component
.....2b.Else create a list and add that into the list
.......2c.If the component next to this one (on all 4 sides) cannot accept/generate/transfer heat (including the component heat vent)
.........2d.Go to 1 and check for the next component
.......2e.Else add that component into the current list
.........2f.Go to 2c and repeat
I gave this a bit more thought, and I can show the following details for a simulation (and possibly as predictions):
1. Hull heating (from fuel rods with no heatable neighbors)
2. Component heating (from fuel rods that do have heatable neighbors)
3. Hull cooling (how much the hull is (or can be) cooled down by various components - there are currently 2 types of vents and 3 types of exchangers that can do this) - in some cases, the "used" hull cooling might be less than the "possible" hull cooling.
4. External venting (how much components are (or can be) cooled by vents with the heat transferred to coolant for a fluid reactor, or completely out of the reactor (for an EU reactor)) - this can fluctuate, especially when using exchangers, but for a given reactor tick, 2x this gives the HU/t of a fluid reactor (40x to get it in HU/s).
Of these, my planner currently shows peak external venting (which might not be such a useful metric, but related to 4) out of possible external venting and max total heating (1 and 2 combined).
Here's my idea for calculating predicted values of those, which I'm hoping will match up with your manual calculations (never mind the "reliable" part for now - "reliable prediction" is kind of an oxymoron, right? ) :
1. Calculate hull and component heating.
2. Calculate hull cooling.
3. Calculate best-case exchanger transfers (i.e. ignore the possible fluctuations and take as much as the "component exchange rate" will allow from any neighbors heated during steps 1 and 2, then transfer as much as possible to any neighbors that haven't been heated)
4. Calculate external venting.
This design seems to not work with the ideas too. You might have forgotten the possibility of components heated up by rods directly and then put their heat into the hull, and then cooled by components that pull heat form the hull. This would also have trouble calculating hull cooling. The reactor heat exchanger will pull heat only if its damage percentage is greater than that of the reactor.
For this one, there will be trouble with hull cooling. The heat exchanger at R0C5 cannot pull heat from the hull, because it is heated too much by the vents. That can be seen by replacing it with a component heat exchanger.
Some ideas about calculating “effective” vent cooling:
1. Generate a adjustable amount of heat and test for the stable one with highest possible heat generation
2.Use pulsed controls to determine heat vented (Only possible for unstable reactors unless having a negative off pulse)
3. Simulate my manual calculation (The most complicated but accurate if done correctly)
I’m leaving for now. I’m going to reply in 9 hours.
Because these are details that can be predicted ahead of time by the program (without actually running a simulation).
Then what do you call it after running a simulation? Still calling it "predictions" doesn't make sense.
Seems that example kind of turned the tables on me, though this one runs long enough that average HU/t output of it as a fluid reactor can be used for calculating an estimate of that - also, CSV data claims this design as a fluid reactor will output 360 HU/s very briefly at the moment when the left vent breaks.
That might actually be a bug, but if so, it may be quite difficult to track down, and I want to try the design in-game first (to make sure it really is a bug).Edit: Brief 360 HU/s confirmed in-game.
Since you want "a reliable, universal way to make my program do it", calculating the output of the corresponding fluid reactor won't work because it isn't universal. At the tick the vent broke, the left one vented heat and broke, while the right one kicks in because the left one can't absorb all the heat.
Until the left vent breaks (at 333 seconds), the right vent will be idle, but afterwards it will operate at full speed and give the reactor 2084 more seconds before it explodes.
Key word from my post: more. I said 2084 more seconds, because without the right vent, the reactor will explode at 1582 seconds. 3666 - 1582 = 2084.
In your original post, "afterwards" refers to the time the left vent break, which is at tick 333. Then 333 + 2084 = 2417, not anywhere close to the explosion point (tick 3166) with the right vent. In your original post, I never saw/interpreted the meaning of "without the right vent". Maybe you just forgot to say that.