games/cosmoteer-pressure-relief-radiator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: record the routing cause and the three silent-failure guards

Browse Source 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
This commit is contained in:
TotenKnopf
2026-08-29 00:12:05 +02:00
co-authored by Claude Opus 5
parent 014e45aa2b
commit e6b98ef68f
1 changed files with 25 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+25 -6
View File
@@ -166,14 +166,33 @@ those types set `IncludeInPhysical = false` — they are blueprint stat-display
plumbing and carry no signal on a real ship, so every receiver read off, the plumbing and carry no signal on a real ship, so every receiver read off, the
vent gate was permanently open, and radiators behaved exactly as in vanilla. vent gate was permanently open, and radiators behaved exactly as in vanilla.
**v1.1.0** carries the signals as `NetworkValue` / `NetworkValueReceiver` **v1.1.0** carried the signals as `NetworkValue` / `NetworkValueReceiver`
instead, which is what vanilla's thermal amplification pump uses to drive actual instead, which is what vanilla's thermal amplification pump uses to drive actual
physical behaviour, and which never sets `IncludeInPhysical` anywhere in the physical behaviour. That was necessary but not sufficient: it also loaded
shipped data. `tests/test_mod.py` now fails on any use of the blueprint-only cleanly and did nothing.
types, and separately re-checks that premise against the installed game so the
guard cannot quietly go stale.
The v1.1.0 logic is verified statically but has not yet been confirmed in-game. **v1.2.0** added the diagnostic indicator icons, which is what finally located
the fault. The wrench icon was present — so `AddBase` and the `Overrides` had
been applying correctly the whole time — while both signal icons showed,
meaning both `NetworkValue`s read zero.
**v1.3.0** fixes the actual cause. A network component is only attached to the
network if a **route** reaches it: the part's `NetworkPort` anchors on one
component, and a `NetworkRouter` bridges that anchor to every other network
component on the part. That is how vanilla connects the radiator's own
`NetworkedThermalDissipationLoadValue`, and how the amplification pump reaches
the resonance beam turret. Unrouted components are not an error — they simply
never connect and read as absent forever.
Routes were added from each part's anchor: `NetworkedHeatBuffer` on the radiator
through its existing `Router`, plus a new `NetworkRouter` on the thermal
battery, the missile launcher and `base_part_overclock`, none of which ships
one.
Three separate mechanisms have now each produced a mod that loads without a
single error and silently does nothing. The test suite has a mutation-verified
guard for each: blueprint-only signal types, fields that do not exist in the
real schema, and unrouted network components.
## Possible additions ## Possible additions