TotenKnopfandClaude Opus 5
014e45aa2b
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
56 lines
1.7 KiB
Plaintext
56 lines
1.7 KiB
Plaintext
// ABOUT ME
|
|
// Components merged into the Missile Launcher. They broadcast, over the heat
|
|
// network, whether this launcher is currently set to Thermal Canister Missiles.
|
|
//
|
|
// Why it exists: banking heat is only worth anything if something on the ship
|
|
// actually spends heat as ammunition. On a ship with no thermal launchers,
|
|
// holding the heat network near full buys nothing, so the radiators should just
|
|
// behave as they do in vanilla. Radiators treat a received 0 as permission to
|
|
// vent freely.
|
|
//
|
|
// ThermalMissilesToggle is the launcher's own vanilla mode toggle
|
|
// (ModeToggle, Mode = MissileType, OnMode = 4), so this signal follows the
|
|
// player's ammunition selection live, including mid-battle switches.
|
|
//
|
|
// Carried as a NetworkValue rather than a NetworkToggle: vanilla marks every
|
|
// NetworkToggle IncludeInPhysical = false, so they do not carry a signal on a
|
|
// real ship.
|
|
|
|
AutoRad_One { Type = StaticValue; Value = 1 }
|
|
AutoRad_Zero { Type = StaticValue; Value = 0 }
|
|
|
|
AutoRad_ThermalAmmoValue
|
|
{
|
|
Type = ToggleValueSelector
|
|
Toggle = ThermalMissilesToggle
|
|
ToggleOnValue = AutoRad_One
|
|
ToggleOffValue = AutoRad_Zero
|
|
}
|
|
|
|
AutoRad_NetworkedThermalAmmo
|
|
{
|
|
Type = NetworkValue
|
|
ValueSource = AutoRad_ThermalAmmoValue
|
|
Categories = [ auto_radiator_ammo_user ]
|
|
IncludeInBlueprints = false
|
|
}
|
|
|
|
// Routes the broadcast onto the heat network. NetworkHeatOutputProxy is what
|
|
// the launcher's thermal ports anchor on. Those ports are only operational in
|
|
// thermal missile mode, so a launcher loaded with anything else is simply not
|
|
// on the network -- which is the behaviour we want anyway.
|
|
AutoRad_Router
|
|
{
|
|
Type = NetworkRouter
|
|
RouteGenerators
|
|
[
|
|
{
|
|
Type = Bidirectional
|
|
Routes
|
|
[
|
|
[NetworkHeatOutputProxy, AutoRad_NetworkedThermalAmmo, 0]
|
|
]
|
|
}
|
|
]
|
|
}
|