Is your feature request related to a problem? Please describe.

Setting up a refinery requires 4 diamonds and a complex chain of pipes, however, the efficiency of burning fuel instead of oil is low: splitting every phase has a maximum yield of 56% or 1.5 fuel MJ per 1 oil MJ. This is hardly an improvement given the complexity of the process.

I made the calculations based on the opportunity cost of heating (vs lava on a stirling engine) and the energy cost of splitting the different phases of the oil based on the source code to split each of the components (gas, light, dense, residue) of crude oil, see this diagram.

The values of kMJ/B are:

• Dense Fuel: 120k
• Mixed Heavy Fuel: 48k
• Light Fuel: 60k
• Mixed Light Fuel: 24k
• Gaseous Fuel: 15k

One important aspect are the progression values. Specifically, going from dense to light to gas has the following progression (in MJ / Bucket):

dense (120) = 2 light (60) = 8 gas (15)

The problem with this is that the increase from gas to light (4x) is higher than liquid to dense (2x). Thus, from an yield's point of view, it is better to not heat anything at searing levels (since it costs MJ), see diagram above. It is only advantageous from the residual's point of view.

Describe the solution you'd like

This proposal aims for two goals:

1. increase the yield of the process beyond 100%
2. increase the incentive to use higher temperatures through increasing yield for increasing complexity

The idea is: the denser the liquid, the higher the advantage it is to split it from residue, but doing so requires a higher temperature (and thus more complex designs).

I propose the following new values (multiplier x old value) in MJ/B:

• Dense Fuel: 540k (4.5 x 120k)
• Mixed Heavy Fuel: 144k (3 x 48k)
• Light Fuel: 90k (1.5 x 60k)
• Mixed Light Fuel: 30k (1.25 x 24k)
• Gaseous Fuel: 15k (1 x 15k)
• All oils remain with the same values.

Let's split this proposal in two:

1. The max amount would be higher, 120 -> 540. This increases yield to around 500% on the dense fuel, to fulfill the goal 1. above
2. the proposal is such that the yield increase from gas to light is the same as light to dense: dense = 6 light = 6*6 gas (an exponential, y = 6^(x - 1))
3. converting some oils to fuel (e.g. dense) is no longer only relevant from the residual's point of view: it is now advantageous to make every bit of oil into fuel.

Describe alternatives you've considered

One alternative would be to reduce the energy cost of heating/distilling fluids. I decided to not take this approach because the biggest energetic cost on the process is the heating. To address assumption 2. above, we would need to have the energetic cost of heating dependent on the fluid being heated. This would be a more complex change to the code base, since we do not support such a change atm.

Another alternative would be to change the amount of mB that each recipe yields. I believe that the current values are really balanced, as they make simple calculations and make physical sense. Changing these would take more effort to find balanced values.

I've implemented some similar values (although slightly lower) in 7.99.24.4 (https://mod-buildcraft.com/buildcraft-799244.html).

you don't need lava for heating at all? you can use your final or byproducts and run those through instead of lava to cool those down again for usage and heat up the next batch to be processed in the process

going this route drastically improves your efficiency already (after using a bit of lava to heat the first bit, but if you are patient you can get away with using as little as one bucket of lava to prime the system as you get more fluid volume from distilling, and to cool off the excess you can just use water)

I never though about that way of operating the cycle. Cool idea! So, yeah, I assumed a very in-efficient setup without knowing that option. Thanks for clearing it up.

We still agreed that the efficiency is low compared to the complexity of the setup.

We deferred action on this issue until the new MJ mechanics is finished.

The MJ update won't be coming to 1.12.2, so looking into these now does make sense - I'll probably use different values in the actual 1.14/Fabric/MJ update anyway.