8 Commits
Author SHA1 Message Date
TotenKnopfandClaude Fable 5 ad17425508 feat: v4.0.0 -- radiator switch picks the mode, ammo gate removed
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
2026-08-29 01:44:06 +02:00
TotenKnopfandClaude Fable 5 c5ddc78495 fix: v3.0.0 -- thresholds on the free-fraction scale the assembly actually uses
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
2026-08-29 01:23:02 +02:00
TotenKnopfandClaude Opus 5 da331e955c fix: measure the network, not a battery's storage
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
2026-08-29 00:49:53 +02:00
TotenKnopfandClaude Opus 5 d82b7e43a4 feat: v2.0.0 -- confirmed working, scaffolding removed
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
2026-08-29 00:27:25 +02:00
TotenKnopfandClaude Opus 5 323ee90f3d test: add three probes to bisect the remaining failure
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
2026-08-29 00:21:17 +02:00
TotenKnopfandClaude Opus 5 e64b50c2be feat: make the radiator report its own internal state
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
2026-08-28 23:46:22 +02:00
TotenKnopfandClaude Opus 5 3ad03d7964 fix: carry signals as NetworkValue, not NetworkToggle
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
2026-08-28 23:37:21 +02:00
TotenKnopfandClaude Opus 5 831a628b53 feat: auto-gate radiators on heat network surplus
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
2026-08-28 23:24:32 +02:00