Modding: Make ConnectableEntityGraphics the basis for SimpleEntityPrototype

[FireController1847]

TL;DR

I’m suggesting either:

• A (much more work — harder, but better in the long run): A larger overhaul of entity texture drawing so that ConnectableEntityGraphics becomes the basis for connectable entities such as walls.
• B (much less work — probably more realistic): An alternate entity basis that can be used, such as a "SimpleConnectableEntityPrototype".

What?

Currently, the only basis for extending any form of connectable entity is the PipePrototype (using the custom PipePictures struct and its variants), or the WallPrototype (using the custom WallPictures struct). Additionally, across the whole codebase, almost every connectable tile uses its own independent pictures struct. Examples include:

• HeatPipePrototype.connection_sprites (which — unlike PipePrototype — uses two different fields for graphics, both relying on the ConnectableEntityGraphics struct, which confusingly is exclusive to heat pipes).
• BoilerPrototype (which uses its own BoilerPictureSet struct).

Each of these structures has reasons for extending or changing the picture layout, but ultimately they all rely on the same foundation: choosing a directional picture based on context — whether that’s rotation or connections. Instead of using the existing prototyping system (already object-oriented and well-suited for extension), it seems each object instead defines its own picture set. This wouldn't otherwise be an issue if there was an alternate way for modders to provide conditional graphics similar to the picture sets, but, as far as I can tell, that is not possible given the current state of the modding API.

As such, my suggestion is twofold — more like a “good, better, best” situation:

• Best) Unify the Pictures standard into something extendable using the existing prototyping system. The concept of selecting a SpriteVariation based on surrounding tiles is universal in 2D video games. This would yield significant long-term advantages, though it would require the most refactoring and might be unrealistic given limited development time.
• Better) Do not modify the existing codebase, but provide a picture-based standard (potentially using ConnectableEntityGraphics) for modders to build on in the future. For example, a "ConnectableEntityBase" prototype with a matching "SimpleConnectableEntity" implementation.
• Good) Update the "wall" entity to use ConnectableEntityGraphics to cover the handful of missing edge cases. That way, at the very least, a wall could serve as a non-functional base for expansion without forcing modders to expand pipe prototypes.

Why?

Why is this a limitation for modders? Consider this example:

09-02-2025, 17-41-29.png (3.12 MiB) Viewed 222 times

This fence, based on the "wall" prototype, is narrower than a full tile. As a result, it needs corner_right_up and corner_left_up sprites (among others I probably haven’t encountered yet) to display properly. The only way to achieve this right now is by switching to a "heat-pipe" or "pipe" prototype, which is at best unideal and at worst unperformant.

The only other workaround I can conceive would be attaching an EntityWithOwnerPrototype or SimpleEntityPrototype with separate textures to bypass the wall’s pictures entirely. That immediately doubles prototype usage and requires significant scripting (to monitor placement and scan neighboring tiles for picture detection). Sure — it can be done. But it feels like an arbitrary limitation, especially when the underlying codebase has either:

• Already solved this problem in some places, or
• Duplicated significant amounts of code that could be unified (which might even improve performance).

Closing

Thanks for the amazing game. I just went down the modding rabbit hole and, unfortunately, realized after a week of research that what I want to do essentially can’t be done without significant Lua overhead. Looking forward to your thoughts, suggestions, and future updates. Cheers!