ON vents constantly (vanilla). OFF banks heat and vents only when the
network is nearly full. The gate is now PowerToggle OR MustVent.
The launcher's thermal-ammo broadcast is gone: it did not follow the ammo
selection live, and the switch states the player's intent directly. Only
the radiator is patched now. New test_gate_is_power_or_must_vent pins the
semantics.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
Disassembling Cosmoteer.dll (tools/ildump.py) shows PartThresholdToggle
compares plain floats with no percent logic, and that a
NetworkResourceInput's Value is the free fraction (0..1) of the connected
network. v2.1.0 compared that against 2000000, so it always vented.
Thresholds are now 5% / 10% free as local constants. New guard
test_threshold_amounts_match_value_scale fails on the old values. README
corrects the earlier wrong diagnosis of v2.0.0.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
v2.0.0 held heat forever: thermal batteries visibly full, parts taking
heat damage, radiators still idle. That is the dangerous direction.
The ceiling read a thermal battery's own HeatStorage with a percentage
threshold. That storage is wrapped by a NetworkResourceStore, and the
local read never crossed 98% however full the network actually got, so
the battery broadcast "hold" permanently.
Measure the network's remaining room directly instead, from the radiator
itself, with a bare NetworkResourceInput -- the same way the heat
exchanger decides whether it can still push heat. Vent below ~2000 status
heat of headroom, hold again above ~6000. Absolute headroom is also the
better metric: what matters is room against the generation rate, not a
percentage of whatever storage happens to be installed.
Polarity is now fail-safe. Holding requires positive evidence of
headroom, so anything missing or unmeasurable vents rather than holds --
the opposite of the failure above.
This deletes both broadcasters. The thermal battery and base_part_overclock
are no longer patched at all, and the mod touches two parts instead of
four. The launcher ammo signal stays; it is confirmed working in both
directions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
Confirmed in game. The radiator's thermal-ammo and hold signals both
arrive, VentAllowed goes false, and the radiator idles with its manual
switch still on -- heat banked for the launchers instead of vented.
The self-test probes did their job: ThresholdToggle was fine, and a
mod-defined category carries a value perfectly well. The EMP probe was
simply a bad probe -- it read thermal_load_dissipation, which an idled
radiator broadcasts as zero, so it was correctly reporting a real zero.
Routing in v1.3.0 was the actual cure.
Remove the probes and the diagnostic indicators. The repointed power
indicator is the one cue a player needs: it now shows on a radiator the
mod has idled.
Add test_override_values_name_real_components, which catches an Overrides
value naming a component that does not exist -- a fourth way to produce a
mod that loads clean and does nothing, and one this very commit
introduced while stripping the scaffolding.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
Routing the network components changed nothing, so the fault is further
down. The wiki documents no network components at all, so there is
nothing to look up and the remaining possibilities have to be separated
empirically.
Each probe drives its own indicator, and an indicator draws while its
toggle is off, so a visible icon means that probe failed:
A (mine) ThresholdToggle misbehaves, no network involved
B (crew) a mod-defined category carries nothing, broadcast and
received on the same part
C (EMP) receiving fails even for thermal_load_dissipation, which
this very radiator already broadcasts
Also switch the real thresholds from MinAmount = 0.5 to the
MaxAmount = 0 / Invert form the thermal pump uses. The signals are only
ever 0 or 1 so it is equivalent, and it removes a variable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011oLWY1G6S8U35bi2FxVWni
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 Fable 5