It looks like currently the beacon uses the same amount of plasma no matter the temperature, ignoring any productivity bonuses. It would be nice if the energy usage would stay constant, so less plasma is used as the temperature increases...

You're right about the energy math, and it's worth spelling out why the beacon still works the way it does.

A fusion generator is energy-limited. Its output is capped at 50 MW, and the engine computes the available energy as fluid_amount × temperature × heat_capacity. At the base 1,000,000°C that's 25 MJ per unit, so 2 plasma/s hits the 50 MW cap exactly — and at 10× temperature it only needs 0.2 plasma/s for the same power. Consumption scaling with 1/T is the entire point of that entity.

The plasma beacon isn't a generator, though. It's throughput-limited. Vanilla's own plasma description draws the distinction: "A quantity of plasma also represents that amount of coolant that travels with it." The beacon needs a certain quantity flowing through it to sustain its field, and hands the same quantity back as hot fluoroketone. That's why the ratio is exactly 1:1, and why consumption scales with quality — a stronger field needs more flow — rather than with temperature.

Here's the part that matters for base building. A fusion reactor outputs 4 plasma/s no matter how many neighbours it has; the neighbour bonus raises the temperature "without increasing the amount of coolant used", as the in-game description puts it. So a normal-quality beacon costs a quarter of one reactor at 1M°C, and a quarter of one reactor at 10M°C. The bonus never changes how many reactors you need per beacon — only how much electricity that same plasma could have produced instead. And if you've maxed out your neighbour bonus, electricity is not what you're short of.

I did look at the alternative properly. The clean implementation would be to make the beacon's hidden converter an actual fusion generator, which gives exactly the behaviour you're describing, in the engine, with no scripting at all. It fails on power priority: generators are demand-driven and sit at secondary-output, behind solar. With enough solar in the network the generator throttles to zero — your beacons would stop working because you built solar panels. Not acceptable.

The scripted route (swapping temperature-banded recipes at runtime) does work, but it would make an already cheap beacon up to 10× cheaper, and it would specifically undercut the higher plasma cost that quality beacons are meant to pay.

So it's deliberate rather than an oversight. Good question though — it sent me back through the numbers to make sure.

Temperature banded recipes would certainly be unnecessary. Some scripting is be necessary to turn the beacon on and off, but you need that for fluid-consuming beacons anyway. Other than that, in 2.1 it's trivial to couple them to eg. an assembling machine with "nothing->fluid" recipe with fluid energy source, scale_fluid_usage=true, and on updates you can check the "working fluid" output to ensure exact beacon duty cycle with fluctuating input (if "fluid per cycle" can be deducted from working fluid fluidbox, beacon is active for next cycle, otherwise inactive).

In 2.0 you'd have needed hidden pumps with internal circuit conditions to achieve the same effect (constant FK output per plasma, with temperature-varying consumption), but it looks like you don't support 2.0 anymore anyway...

Let me take the design side; the technical analysis on this project is my AI assistant's job, so I'll leave that part to it below.

What I was after: an endgame beacon that runs on plasma consumption and is tied into the cooling loop. I did think about the reactor neighbour bonus, and I decided against it — but in the opposite direction to yours. I already consider fusion power cell consumption far too low, and the neighbour bonus lowers it further on top of that. Cooling is practically free as well. So my intention was to raise the cost, not lower it.

The compromise I settled on was four beacons per reactor, with quality actually increasing consumption rather than leaving it flat. I still think it's too cheap and the beacon effect too strong. Nobody has argued otherwise so far, but the balancing is definitely still an open question for me. Temperature dependent consumption would push it the wrong way.

I understand that it's possible, and it's a genuinely interesting topic — it's just not what I want for this mod. And offering it as a setting would mean a substantial rebuild for something that would ship switched off.

I value your expertise and your suggestions. They make some really interesting alternatives thinkable, and thank you for that. My assistant dug up one detail about the fluid energy source that you may not have come across yet, so I'll let it handle that part. If you don't like AI answers, this is a good place to stop reading.

Either way, thanks for your contribution — but I'm strongly inclined to leave it as it is.

[Claude, the AI assistant Morlot developed this mod with.]

One thing back to you first: you can drop the "nothing -> fluid" recipe from your construct entirely. Since 2.1 a fluid energy source itself takes
output_fluid_box together with spent_fluid ("Fluid and amount produced per 1 unit of fluid consumed"), so the source returns one fluoroketone-hot per plasma consumed with no recipe involved. The 1:1 balance holds for free and there is no recipe cycle to line the duty cycle up against. That field was new to me too — I only found it while checking your idea.

Now the detail. The fusion generator and a fluid energy source do not use the same formula:

  FusionGeneratorPrototype: energy = amount * T * heat_capacity * effectivity
  FluidEnergySource:        energy = amount * (T - T_default) * heat_capacity * effectivity

Both quoted from the burns_fluid description on the respective prototype.

fusion-plasma has default_temperature = 1000000, and the vanilla fusion reactor sets no target_temperature — in that case the docs say the output fluid's default temperature is used. So a reactor with no neighbours emits plasma at exactly its default temperature. (Cross-check: the generator's 2 plasma/s x 25 MJ = 50 MW, exactly its output_flow_limit.)

In a fluid energy source that is a delta of zero: no energy at all, and with destroy_non_fuel_fluid defaulting to true the plasma is consumed for nothing — the docs name that exact case. Consumption would scale as 1/(T - 1M) rather than 1/T, with a pole sitting precisely where an un-bonused reactor runs, and no effectivity value moves it, since zero times anything is zero.

The practical consequence is the interesting part. The construct would not just change the cost curve, it would make the neighbour bonus a requirement: a single reactor, which is the configuration the mod is documented around, would leave the beacon dead.

Worth stating plainly: that is a reason the construct does not work, not the reason for the answer above. That one is Morlot's, and it stands on its own.

Since I haven't tried the beacon out in practice yet, I wasn't thinking about making it cheaper - I'd just like reasons to cluster reactors together rather than putting single reactors all over the place. A higher base cost balanced around 2+ reactors per cluster would be totally fine with me.

I actually wasn't aware of the calculation difference (thanks for pointing that out), but that could be fixed by simply setting T_default to 0 and manually adding a target temperature of 1M to each reactor outputting plasma, if you did decide to go down this route.

On the other hand, if beacons being too cheap bothered you, forcing the use of neighbor bonuses would be once way to increase costs :)

About your last point: you say that enforcing neighbourhood bonuses would increase costs. Do you mean the resource costs, or the energy that the plasma would otherwise have generated? These two factors actually work in opposite directions.

One reactor: 4 plasma/s at 1M powers two generators (100 MW). One beacon costs 25 MW in lost energy generation.
Two reactors: 8 plasma/s at 2M powers eight generators (400 MW). The same beacon now costs 50 MW.
At the upper limit of 10M: 250 MW.
A factor of ten. This is already the case in the mod, without any temperature coupling at all.

The beacon therefore acts more as a deterrent to cluster formation than as a reward for it. The most cost-effective method for operating beacons is a separate reactor without bonuses, whilst the cluster remains reserved for energy generation.

Volume-based consumption, as it currently stands, keeps resource costs constant and allows energy costs to rise with cluster size. Energy-based consumption, as you’ve suggested, keeps energy costs constant and allows resource costs to fall with cluster size. Neither option is neutral.

So, as regards the aim of giving players a reason to form clusters: my current solution has the opposite effect, whilst yours would encourage it. However, it does so by reducing the resource costs for a large cluster to a tenth. That is precisely the point I want to avoid.

Is that what you had in mind, or were you simply thinking of setting the base cost high enough that a single reactor stops being viable?

I was referring to leaving T_default as is, meaning normal temperature plasma doesn't fuel beacons at all, and higher temperature plasma is counted as if it was 1M degree colder.
Since fusion reactor only get full neighbor bonuses for adjacent reactors running at full capacity, this means that 2 reactors would need to produce more than 4/s to even out (probably somewhere around 5/s, with a temp of ~1.4M; with optimal circuit controlled coolant feeding, you could get the old 2/s consumption at 2M plasma).
If you connected 4 beacons to the 2 reactors, you'd also be back at 2/s per beacon without circuit control (all running at max -> 2M temperature).

A single reactor couldn't even power a single beacon though.

And if you managed to fit more beacons into the extent area of plasma pipes, you could get more efficient with larger reactor blocks (3 reactors -> 12 plasma at 3M, so beacons would only drain 1/s -> 12 beacons for the price of running 3 reactors) - though you'd have the problem of having to pack that many beacons, plus the affected machines, plus logistics, into the plasma pipe extent area...

This increases the upfront cost (more reactors necessary) and introduces interesting design constraints, rather than always plopping down beacon+single reactor pairs, while also increasing the upkeep cost for typical designs (with 4 beacons and 2 reactors, you'd get back exactly the old cost, but going higher than that would likely waste beacon area due to the limited plasma pipe extent - and for layouts making the most out of each beacon, with the default plasma pipe extent it seems difficult to even fit more than 2 beacons to a 2-reactor block)

I went through your proposal in detail with my AI assistant and worked out a working solution. I like it so much that the new 2.0.0 update actively recommends this mode:

• Below 3M the costs are higher. My original intention
• From 3M on the costs go down. Your intention
• The loss of electricity generation by plasma per beacon is now falling rather than rising
• A cluster is now a requirement, which means more Factorio-style puzzling
• The reactors no longer stutter, because the plasma is drawn evenly now. That fixes an old blemish

The exchange with you was very productive and is what made this version possible in the first place. With your suggestions the Plasma Beacon now fits perfectly into the plasma economy and finally feels "Factorio-like". This is how it should have been from the start.

Thank you very much indeed!

If you are interested in the technical details, I'll hand over to my AI assistant now. As always: if you don't like AI, you can stop reading here.

Technically this is your proposal, unchanged. The hidden converter behind the beacon swapped its electric energy source for a FluidEnergySource on fusion plasma. burns_fluid = false gives exactly the delta formula you were counting on — amount × (T − default_temperature) × heat_capacity — so default_temperature stays at 1M and no vanilla prototype is touched. scale_fluid_usage = true lets the engine draw whatever energy_usage demands, and spent_fluid hands the fluoroketone back one for one, so the recipe carries no fluid at all any more.

That leaves a single balance knob: energy_usage. At 50 MW the draw is

50 MW / ((T − 1M) × 25 J)

which puts the break-even against the old model at 3M — a plain 2x2 reactor block. Measured in game:

Your estimate of "probably somewhere around 5/s, with a temp of ~1.4M" for two reactors was exactly right. That is where a single beacon on two reactors settles, because the neighbour bonus scales with how hard the neighbours are actually working.

Which gives the mode a property neither of us predicted: adding beacons raises the load, which raises the bonus, which makes every beacon on that cluster cheaper. The design rewards loading your reactors properly instead of punishing it.