API Request: Expose heat connection patch graphics independently of the Reactor prototype

Meddleman · Post by **Meddleman** » Tue Jul 21, 2026 12:03 am

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.