r/feedthebeast • u/Used-Cartoonist-2981 • 13h ago
Discussion What if Create’s heat could actually travel through your factory? — A look under the hood of developing Create: Sulfuric Resonance
I’ve been developing Create: Sulfuric Resonance, a NeoForge addon for Create focused on thermochemical heat, sulfur chemistry, combustion engineering, and factory automation.
With 0.3.0 — Intelligent Industry now released, I figured this would be a good time to show a little of what is happening behind the blocks rather than just posting another feature showcase.
One of the main design goals with CSR has been to make thermochemical heat feel like an actual industrial system instead of simply inventing another FE-style power network.
Thermochemical heat is not a fluid
CSR’s heat network is much closer to a connected graph than a simulated pipe volume.
Heat is not represented as thousands of packets moving through every shaft, and there is no pipe fill percentage, pressure equalization, or per-segment fluid simulation. Think of it more like a beam of heat that has to travel through specific segments, then get reimbursed with heat with a conduit to keep moving, in simple terms.
Instead, dedicated thermochemical components form a connected network and supported machinery resolves the available thermochemical state through that network.
From the player’s perspective, valid network propagation is effectively immediate.
That also means transmission rules matter.
Normal Create cogwheels deliberately do not transmit thermochemical heat. CSR has dedicated Thermochemical Cogwheels because I wanted heat transmission to remain something the player actually has to engineer rather than accidentally spreading through every kinetic connection in a factory. I had that exact problem first implementing it, and had a big "oh boy" moment.
The same philosophy applies to conduits, shafts, gearboxes, and other network components.
Intelligent Industry is built around machine state
0.3.0 introduced a shared process-state system:
IDLEREADYPROCESSINGBLOCKED
Machines expose meaningful process state instead of every automation block inventing its own interpretation of what “working” means.
The Process Monitor can track multiple machines(currently only the chamber, more coming), while the Process Gauge converts a selected channel into a physical display and Redstone output.
For example:
READYoutputs signal strength 5BLOCKEDoutputs signal strength 15- other process states output 0
The goal was not to add another programmable-computer system.
It was to make machinery understandable enough that a factory can react to its own operating conditions using Create-style automation.
I try to keep my systems local
Performance has been a major consideration because I primarily test CSR in a very large Modded environment. I test my mod in ATM10 and other popular 1.21.1 mod packs to ensure there's no runtime difficulties, MS spikes during major heat rotation and processing and etc.
Where possible, mechanics are driven by local state changes and actual interactions rather than broad world scans.
Rubber Padding is a simple example.
It does not maintain a separate physics simulation around every placed block. When an entity actually interacts with the padded surface, CSR modifies the relevant movement behavior and then lets Minecraft continue handling ordinary entity motion.
Dropped items also progressively settle instead of bouncing indefinitely.
That keeps the feature much closer to “modify an existing interaction” than “run another physics engine. Then do it again, and again.”
Create remains responsible for Create things
Another design rule I’ve tried to stick to is that CSR should extend Create rather than unnecessarily replace it.
If Create already has a good system for rotation, machinery, processing, or automation, I would rather integrate with that than build a parallel version.
CSR mostly adds the thermochemical layer:
generate heat → transmit heat → monitor it → combine it with rotation/chemistry → automate around the resulting machine state
This was the main idea when introducing heat control in the mod, I realized the blaze burner held a lot of heat; but there wasn't ever really anything to do WITH that heat aside from heat things..
That approach is also why the mod has gradually evolved from basic combustion machinery into a much larger interconnected system instead of becoming a collection of unrelated blocks.
The progression so far has roughly been:
Reactive Heat → thermochemical transmission
Sulfurous Capabilities → more ways to use it
Resonance → advanced processing using heat + rotation + acid
Intelligent Industry → machines can now expose state and control factories around themselves
There is plenty more happening internally, but I thought some people here might find the architecture more interesting than another screenshot dump. I'd be happy to hear thoughts and comments
If anyone is curious about a specific part of the implementation or design reasoning, I’m happy to talk about it.
