The diagnostic icons answered it. The wrench was present, so AddBase and
the Overrides had applied correctly all along -- but the thermal-missile
and resource icons were both showing, meaning both NetworkValues read
zero. With both signals absent, VentAllowed collapses to true and
AutoPowerToggle degenerates to plain PowerToggle: on means permanently
on, exactly as reported.
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 the rest -- which is how vanilla connects the
radiator's own NetworkedThermalDissipationLoadValue, and how the thermal
amplification pump reaches the resonance beam turret.
Add routes from each part's anchor: NetworkedHeatBuffer on the radiator
via its existing Router, and a new NetworkRouter on the thermal battery,
the missile launcher and base_part_overclock, none of which ships one.
Unrouted network components are not an error -- they simply never
connect and read as absent forever, which is why three versions loaded
cleanly and did nothing. The new test fails on any network component the
mod adds that no route names.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
Drop debug_mode.sh. Setting DebugMode = Normal crashed the game on
startup (Enum.Parse on a member that does not exist), and there is in
fact no DebugMode type in the assembly at all, so that route was never
going to work. Developer mode is launched directly instead.
Investigating it produced something worth keeping: a reader for the
assembly's CLI metadata tables. It walks PE headers to the #~ stream and
resolves a type's fields including inherited ones, which gives the real
rules schema of any component.
Wire that into the tests. Cosmoteer ignores unrecognised fields rather
than reporting them, so a misspelled field name yields a mod that loads
cleanly and silently does nothing -- the exact failure mode this project
has been stuck in. Nothing else catches it.
The check confirms the current components are all well-formed, which
narrows the remaining fault to runtime behaviour.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
The binary ships a part debugger (OpenPartDebugger, PartDebugValue /
PartDebugToggle / PartDebugTrigger) that can show a part's live component
values -- the only way from inside the game to see why a modded toggle
chain is not firing. It is gated behind the DebugMode setting, which has
no UI in a release build.
The script refuses to run while the game is open, because Cosmoteer
rewrites settings.rules on exit and would discard the change.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
v1.1.0 loaded cleanly and still did nothing, so the NetworkValue rewrite
was not the whole story. Rather than keep guessing at which link in the
chain is dead, add indicator icons bound to the internal signals.
An indicator draws while its toggle is off, so one glance at a radiator
now separates the cases that were previously indistinguishable:
wrench absent -> the AddBase never merged; nothing in the mod runs
thermal missile -> no thermal-ammo signal arriving
resource -> no hold signal arriving from a battery
Tests check that every added indicator binds to a component that exists
and to a sprite that exists in the indicators atlas.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
v1.0.0 loaded cleanly and did nothing in game. Every vanilla use of
NetworkToggle and NetworkToggleReceiver -- all three of them -- sets
IncludeInPhysical = false. They are blueprint stat-display plumbing and
carry no signal on a real ship, so the receivers always read off, the
vent gate stayed open, and radiators behaved exactly as in vanilla.
Broadcast 1/0 through NetworkValue and threshold it back into a toggle
on the receiving side. That is what the thermal amplification pump uses
to drive physical behaviour, and vanilla never sets IncludeInPhysical on
it anywhere.
Also repoint the radiator's power indicator at the gate, so an auto-idled
radiator is visibly idle instead of looking identical to a working one.
Tests grow a guard against the blueprint-only types, plus a check that
re-verifies that premise against the installed game data so the guard
cannot go stale, and a name-collision check against vanilla components.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
Radiators and Thermal Canister Missile launchers pull from the same heat
pool with identical NetworkResourceOutput settings, and priorities.rules
defines no ordering for heat. A constantly-running radiator therefore
spends missile ammunition to make steam.
Gate radiator dissipation on three network signals instead of the raw
PowerToggle: a 98%/94% hysteresis band on the thermal battery, whether
any launcher is actually set to thermal ammo, and an override driven by
the engine's own OverflowHeatStorage as a safety net.
Storage fullness causes no damage on its own -- only overflow does, and
only above 350 status per tile -- so the band sits high deliberately to
keep the network full as a missile reserve.
Signal polarity is "hold", not "vent", so any ship missing a broadcaster
falls back to vanilla behaviour.
Includes an offline validation suite that resolves every patch target,
component reference and component Type against the installed game data,
since all three otherwise fail only as a crash on game load.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
TotenKnopfandClaude Opus 5