TL;DR
Additively expose native heat-connection rendering/patches to (heat-powered) non-
ReactorPrototypes.
---
I've been developing a heat-powered assembling machine mod. The entity itself is straightforward to implement, as assembling machines already support a heat energy source.
However, I've run into an API limitation regarding the
visual representation of heat connections.
Currently, the Reactor prototype exposes dedicated connection graphics such as:
- connection_patches_connected
- connection_patches_disconnected
- heat_connection_patches_connected
- heat_connection_patches_disconnected
These automatically do the following, producing the polished behaviour seen on reactors and heating towers:
- select the correct directional connector
- distinguish connected from disconnected connections
- apply the animated heated glow on the little stubby connectors.
Problem
Any prototype that supports
energy_source.type = "heat", despite supporting heat as an energy source, does not have access to this functionality. As a result, reproducing the same visual behaviour currently requires a substantial amount of runtime scripting:
- detecting neighbouring heat entities,
- tracking build/remove events,
- maintaining runtime state,
- rendering replacement sprites,
- updating connector graphics manually.
The underlying heat network already knows which connections exist; the visual information simply isn't exposed to non-reactor prototypes.
Suggestion
At present these properties are only available on the Reactor prototype. It would be useful if equivalent functionality were available to
any prototype using a heat energy source.
For example, either by:
- additively exposing the connection patch definitions on HeatEnergySource / HeatBuffer, or
- exposing equivalent optional properties on prototypes supporting energy_source.type = "heat".
Code: Select all
connection_patch_graphics = {
connected = ...,
disconnected = ...,
heat_connected = ...,
heat_disconnected = ...
}
The connection topology is already modelled generically through
HeatConnectionDefinition, which is used by both
HeatEnergySource.connections and
HeatBuffer.connections; only the corresponding connection-patch rendering is currently exposed through
ReactorPrototype. In parallel to
FluidBox, both heat structures already expose shared visual fields, suggesting that optional per-connection patch graphics would fit naturally alongside the existing connection definitions:
- heat_picture ≈ pipe_picture
- heat_pipe_covers ≈ pipe_covers
- ...
---
This is not merely about reducing Lua code. Heat-powered entities are already fully supported from a simulation perspective, but the engine is also the only place that has perfect knowledge of connection state and heat-buffer temperature. Mods attempting to reproduce the same visual behaviour must therefore duplicate logic that the engine already performs internally, while still being unable to fully reproduce the native behaviour.
Exposing the existing connection-patch system to any prototype using a heat energy source would make heat-powered assemblers, furnaces, and other custom entities feel like first-class members of the heat network, much as fluid pipe connection graphics are already available to any prototype with fluid boxes. It would also remove the need for mods to mirror engine-side state purely for presentation, keeping gameplay logic and rendering responsibilities where they naturally belong.