# Auto Radiator A Cosmoteer mod. Radiators stop dumping heat the ship still wants. ## The problem Thermal Canister Missiles are built from the ship's own heat. The game says so itself, in `Data/strings/en.rules`: > Manufactures guided Thermal Canister Missiles that take thermal energy from > their own ship's heat pipe network and inflict it upon the target. The launcher charges each missile from the heat network — `HEAT_PER_MISSILE = 8500`, two missiles buffered per launcher. A radiator pulls from that same network, through a component that is behaviourally identical to the launcher's: | | Radiator | Thermal launcher | |---|---|---| | Type | `NetworkResourceOutput` | `NetworkResourceOutput` | | Mode | `DistributeProportionallyByAvailable` | `DistributeProportionallyByAvailable` | | Categories | `[ thermal_storage ]` | `[ thermal_storage ]` | `Data/ships/priorities.rules` defines priorities for crew and supply only — nothing for heat. So the two compete flat, proportionally, and a radiator running constantly is spending your ammunition to make steam. ## Why holding heat is safe Heat storage being full does not hurt you. Damage comes only from *overflow*. Every overclocked part routes its heat through this (`Data/ships/base_part_overclock.rules`): ``` HeatDistributionStorage { Type = MultiResourceStorage ResourceStorages = [NetworkHeatInput, OverflowHeatStorage] AddMode = InOrder } ``` `InOrder` means the network is tried first, and `OverflowHeatStorage` only receives what the network refuses. Overflow then applies the `cosmoteer.heat` status to the producing part's own tiles. From `Data/statuses/heat/heat.rules`, that status does nothing whatsoever below **350** per tile (`RequireValueRangeForTick = [350, Infinity]`). Fire chance ramps from 350 to 2500; thermal damage begins at 700. An overclocked large reactor produces 2750 heat/sec over its 4×4 footprint — about **172 status/sec per tile** while fully overflowing, so roughly **2 seconds of continuous, total overflow** before fire risk even arms. Radiators react within **0.5 s** (`HeatDissipationConverter { Interval = 0.5 }`). At a 98% ceiling on a single 15000-capacity thermal battery, the overshoot during that reaction window is about 625 status heat spread over 16 tiles — roughly **39 per tile**, against a threshold of 350. Holding the network near full is safe with a wide margin, and every percent of ceiling given up is ammunition thrown away for nothing. The genuine constraint is not the threshold. It is total radiator throughput (1100/sec each) versus sustained generation. If you are short on radiators you overflow continuously and no threshold value saves you — which is what the safety net below is for. ## What the mod does Radiators vent when **any** of these is true: 1. The heat network is not asking them to hold — the thermal battery is at or above 98% full (dropping the hold again at 94%, a deadband so radiators do not chatter at the threshold). 2. No launcher on the network is set to Thermal Canister Missiles. If you are not spending heat as ammunition there is nothing to hoard, so radiators behave exactly as in vanilla. 3. **Safety net:** some part is actually overflowing heat right now. This reads the engine's own `OverflowHeatStorage`, so it fires the moment the network genuinely refuses heat — regardless of thresholds, pipe topology, or whether your radiator capacity was ever sufficient. Latched for 3 seconds so a stream of per-tick overflow events becomes one steady signal. Your manual radiator on/off switch still overrides all of it. The automation can only idle a radiator you have left switched on. Ships with no thermal battery have no broadcaster, so nothing changes for them. The signal polarity is deliberately "hold", not "vent", so that the absence of any part of this mod's machinery always falls back to vanilla behaviour. No stat or number is changed. Only *when* radiators run. ## Layout ``` mod.rules manifest + patch actions components/thermal_battery_vent.rules decides when there is surplus components/launcher_ammo_signal.rules reports thermal ammo in use components/overclock_overflow_signal.rules safety net, reports real overflow components/radiator_auto.rules combines the signals into one gate tests/ offline validation suite install.sh validate + copy into the Mods folder ``` ## Install ```sh ./install.sh ``` Then enable **Auto Radiator** in the game's Mods menu. `./install.sh --uninstall` removes it. If the script cannot find your Mods folder, set `COSMOTEER_MODS_DIR`. ## Tests ```sh python3 tests/test_mod.py ``` Cosmoteer applies mod actions to vanilla data at load time. Some mistakes crash the game on startup — an unresolvable path, a misspelled component `Type` — and the suite catches those by parsing the installed game's `.rules` tree offline. The more dangerous mistakes do not crash anything. They load perfectly and silently do nothing; see **Status** below for the four this project hit and the guard for each. The suite also self-checks its own parser against known vanilla facts first, so a broken parser fails loudly instead of passing everything. Set `COSMOTEER_DATA` to point at a different install, and `COSMOTEER_ASSEMBLY` for the schema checks. ## How to tell it is working There is no separate "auto" mode and nothing to reset. The radiator's on/off switch is an AND gate: - switch **off** -> radiator is off, and stays off. The mod never turns it back on. - switch **on** -> the automation decides, moment to moment. An auto-idled radiator shows the "powered off" indicator icon and stops emitting its steam plume. That icon on a radiator you did *not* switch off is the mod holding heat back for your launchers. ## Status Working, confirmed in game on 2026-08-29 against game data version 0.30.4c. Getting there took four builds that each loaded without a single error and did nothing, for four different reasons. Cosmoteer reports none of them, so each one now has a mutation-verified test: | Silent failure | Guard | |---|---| | `NetworkToggle` / `NetworkToggleReceiver` carry no signal on a physical ship (every vanilla use sets `IncludeInPhysical = false`) | `test_no_blueprint_only_signal_types`, plus `test_vanilla_marks_those_types_blueprint_only` so the premise cannot go stale | | A field name that does not exist in the component's real schema is ignored rather than reported | `test_component_fields_exist_in_schema`, read from the assembly's own metadata | | A network component no route reaches never attaches, and reads as absent forever | `test_network_components_are_routed` | | An `Overrides` value naming a component that is not there reverts the gate to nothing | `test_override_values_name_real_components` | The third was the actual cause. A network component is only attached 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. Routes now run 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. None of this is documented: the wiki's modding pages cover no network components at all, so the game's own `.rules` files are the only reference. `tools/dotnet_enum.py` reads component schemas and enum members straight out of `Cosmoteer.dll`, which is how the field and type questions got settled. It is useful on its own for any Cosmoteer modding: ```sh python3 tools/dotnet_enum.py /path/to/Cosmoteer.dll PartThresholdToggleRules python3 tools/dotnet_enum.py /path/to/Cosmoteer.dll MultiToggleMode ``` Version 1.4.0 in the git history carries a probe build that makes a radiator report its own internal state through indicator icons, if this ever needs debugging again. ## Possible additions - A per-radiator UI toggle for auto/manual, which needs a new `ChoiceID` wired into `Data/gui/game/parts/part_toggles.rules`. - Making the 98% / 94% band configurable.