orbiternassp
Failure simulation overhaul
-Move all failure code in a dedicated class -Failures are possible to be scheduled on mission time, simulation time or time since staging (S-I or S-II) -S-IVB engine failures -Generic CSM switch failures
Failures can be scheduled or randomized through the PAMFD, just like right now. In addition, the failures are saved/loaded in scenarios. More complicated sequences of failures can be implemented in the scenario.
In the scenario section of the Saturn class, there will be a section for failures starting with FAILURES_BEGIN and ending with FAILURES_END. An example of a failure would be:
MALFUNCTION 0 0 0 100.0
1st parameter: From a list of possible malfunctions, choose the desired one. 0 is equivalent to "LET AutoJet Fail" 2nd parameter: 1 if the system is already failed, 0 if the failure is supposed to happen in future. 3rd parameter: The condition type for the failure. 0 = mission time, 1 = simulation time. Other values are vehicle specific, for the CSM implemented right now are 2 = time since S-I/S-II (or S-IVB) staging, 3 = time since S-II/S-IVB staging. 4 = time since EOI, 5 = time since TLI preparations (Timebase 6 start), 6 = time since TLI cutoff 4th parameter: The time value associated with the condition type.
Switch malfunctions can be scheduled in the following way:
SWITCHMALFUNCTION GNComputerMnACircuitBraker 0 0 100.0
1st parameter: name of failed panel element 2nd parameter: failure state of panel element 3rd parameter: The condition type for the failure. See above. 4th parameter: The time value associated with the condition type.
This explanation will be added to our wiki once this PR is merged.
Limitations:
Some failure types require an active function call to cause the failure. If the affected subsystem does not save this failure then after a reload the failure condition might be gone. Similarly, switch failures don't get saved in the switch class so they would be cleared after saving/loading.
