You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the user has customized process dump settings, they can be being internally reset to their default value or a different value when loading a vessel and on other events, despite the PAW showing the customized value. Practical workaround is to manually cycle the dump settings in the PAW.
The processes dump specs implementation is flawed from the very beginning, as processes are vessel-wide and dump specs are implemented per part, leading to individual parts fighting over what the vessel-level dump settings should be. I wont go in details about the billions of other issues this thing has, it's another thing that we need to rewrite from scratch.
I did a quick prototype for a reimplementation, but I haven't the time to do that right now so I'm posting this here for reference :
Implement an EditorVesselData persisted data structure, that we save in persistent.sfs and use to carry data from the editor to VesselData on vessel launch.
Identify it by ShipConstruct.persistentId. From a quick analysis this is fail-proof as long as we don't use it in flight. Details :
Stock set this in the editor and save it in the ShipConstruct.persistentId
When the vessel is rolled out for launch, the value is copied to Vessel.persistentId in ShipConstruction.AssembleForLaunch()
This method is called just before the OnVesselRollout event, so we should be able to safely copy the VesselEditorData to the active vessel VesselData to carry our in-editor-defined vessel-level data to VesselData (might need to be in a coroutine to wait for the vessel to be properly initialized)
In the processes config definition, get ride of dump_valve and dump fields, add a defaultDumpedOutputs field instead. This accept a list of comma separated outputs or the all value. If the field is absent, no output are dumped by default.
Remove the processControler module dump_specs config value and all related code.
In the editor, add a "configure processes" button to the planner. This open a popup with the list of all processes present on the vessel. For each process, list the resource used, their rate, and a "dump" checkbox for the outputs. Save these settings in the VesselEditorData as a dictionary<string,string[]> where the string is the process name and string[] an array of the dumped outputs names. If that data is not initialized yet, get the default values from defaultDumpedOutputs.
Same popup is available in flight trough a "configure processes" buttons in the monitor UI.
It's then trivial to get the dump status of an output from Process.ExecuteRecipe()
When the user has customized process dump settings, they can be being internally reset to their default value or a different value when loading a vessel and on other events, despite the PAW showing the customized value. Practical workaround is to manually cycle the dump settings in the PAW.
The processes dump specs implementation is flawed from the very beginning, as processes are vessel-wide and dump specs are implemented per part, leading to individual parts fighting over what the vessel-level dump settings should be. I wont go in details about the billions of other issues this thing has, it's another thing that we need to rewrite from scratch.
I did a quick prototype for a reimplementation, but I haven't the time to do that right now so I'm posting this here for reference :
EditorVesselData
persisted data structure, that we save in persistent.sfs and use to carry data from the editor toVesselData
on vessel launch.Identify it by
ShipConstruct.persistentId
. From a quick analysis this is fail-proof as long as we don't use it in flight. Details :ShipConstruct.persistentId
Vessel.persistentId
inShipConstruction.AssembleForLaunch()
OnVesselRollout
event, so we should be able to safely copy theVesselEditorData
to the active vesselVesselData
to carry our in-editor-defined vessel-level data toVesselData
(might need to be in a coroutine to wait for the vessel to be properly initialized)dump_valve
anddump
fields, add adefaultDumpedOutputs
field instead. This accept a list of comma separated outputs or theall
value. If the field is absent, no output are dumped by default.dump_specs
config value and all related code.VesselEditorData
as adictionary<string,string[]>
where thestring
is the process name andstring[]
an array of the dumped outputs names. If that data is not initialized yet, get the default values fromdefaultDumpedOutputs
.Process.ExecuteRecipe()
Related issues : #422, #337, #449, #497, #494
The text was updated successfully, but these errors were encountered: