SSU Workbench development

[DaveS]

Hmm, not sure what you mean... as far as the "main" SSU code, no changes are needed for the SSU Workbench to work. My problem, now that file load/save is +/- done, is how to change/update the vessel data (inside SSU Workbench) so that it writes what we want to the scenario files.

For example, the "SECTION_COUNT" parameter is only used by the SRB vessel and it seems like the two lines that would make it active has been commented out:

Atlantis_SRB.cpp

Atlantis_SRB::Atlantis_SRB (OBJHANDLE hObj)
: VESSEL3(hObj), bMainEngine(false), bSeparationEngine(false), usSectionCount(SRB_SECTION_COUNT)
{
	// preload mesh
	//mesh_idx = MESH_UNDEFINED;
	//hSRBMesh_Left = oapiLoadMeshGlobal ("SSU/LSRB");
	//hSRBMesh_Right = oapiLoadMeshGlobal ("SSU/RSRB");
	for(unsigned short i=0;i<SRB_SECTION_COUNT;i++) {
		//hSRMSegmentMesh_Left[i] = NULL;
		//hSRMSegmentMesh_Right[i] = NULL;
		hSRMSegmentMesh[i] = NULL;
	}

	hVis = NULL;

	slag1 = 0.0;
	slag2 = 0.0;
	slag3 = 0.0;

	COLOUR4 col_diff = {1.0,0.733f,0.196f,0};
	COLOUR4 col_zero = {0.0,0.0,0.0,0.0};
	COLOUR4 col_ambient = {0.5,0.5,0.5,0};
	SRBLight = AddPointLight( _V( 0.484, 0.434, -25.8 ), 300, 1e-3, 0, 0.0025, col_diff, col_zero, col_ambient );
	SRBLight->Activate( false );
}

That's the total code except for saving/loading. From what I can tell, it's totally inert and dead.

 

[GLS]

Well, the scenario should only represent the variable aspects of the "entities" described in scenario and mission file.

So, what goes missing? A mission file for example would contain, which SRB is installed before launch, but the scenario should contain, if the SRBs are already installed, ignited, or separated.

Yes, I know that. My problem is how to, for example, change the SRMs from the RSRM to FWC? The "on screen" part is done, as is the mission file parameter, but how to go to the vessel list loaded from the scenario and change/edit the SRB vessels... that's where it goes off the rails.
More, there are 2 situations here: (1) we load a scenario and with it comes a mission, and (2) we load (or create) a mission. Going from the mission editing to the scenario creation/editing is probably going to be different for those 2 situations.

 

[Urwumpe]

Well, usually, there should be just one process:

0 -> Create/Edit Mission File(s) -> Export scenario(s) -> Start Orbiter

The scenario file should not need to be edited as such - we just generate them in the workbench based on the parameters of the mission file and the entry points that we define. In first iteration, there would maybe be one special generator per scenario type for a mission. But maybe we can later generalize them to have only a few special C# generators with different configurations.

 

[DaveS]

I think the mission should always be the overriding thing. It takes priority overt he scenario. The scenario is just that, the mission in various situations (OV in OPF just prior to S0004 for example). All the various details like the ET and SRB types should be in the mission file. Currently they're set in the scenario.

 

[GLS]

For example, the "SECTION_COUNT" parameter is only used by the SRB vessel and it seems like the two lines that would make it active has been commented out:

Atlantis_SRB.cpp

Atlantis_SRB::Atlantis_SRB (OBJHANDLE hObj)
: VESSEL3(hObj), bMainEngine(false), bSeparationEngine(false), usSectionCount(SRB_SECTION_COUNT)
{
	// preload mesh
	//mesh_idx = MESH_UNDEFINED;
	//hSRBMesh_Left = oapiLoadMeshGlobal ("SSU/LSRB");
	//hSRBMesh_Right = oapiLoadMeshGlobal ("SSU/RSRB");
	for(unsigned short i=0;i<SRB_SECTION_COUNT;i++) {
		//hSRMSegmentMesh_Left[i] = NULL;
		//hSRMSegmentMesh_Right[i] = NULL;
		hSRMSegmentMesh[i] = NULL;
	}

	hVis = NULL;

	slag1 = 0.0;
	slag2 = 0.0;
	slag3 = 0.0;

	COLOUR4 col_diff = {1.0,0.733f,0.196f,0};
	COLOUR4 col_zero = {0.0,0.0,0.0,0.0};
	COLOUR4 col_ambient = {0.5,0.5,0.5,0};
	SRBLight = AddPointLight( _V( 0.484, 0.434, -25.8 ), 300, 1e-3, 0, 0.0025, col_diff, col_zero, col_ambient );
	SRBLight->Activate( false );
}

That's the total code except for saving/loading. From what I can tell, it's totally inert and dead.

I didn't add that parameter so I can't say for sure what it is/was for. I'd guess it's so the SRB vessel can have 4 or 5 segments. AFAIK, for the Shuttle 4 is the limit, as adding a 5th segment would need changes to the GOX vent arm, so for SSU it seems like an unneeded parameter. But, if the SRB vessels could be made "autonomous", choosing between 4 or 5 segments would be a plus. But currently the SRB thruster/TVC/etc is not that vessel, it makes those parameters a bit redundant.

---------- Post added at 10:24 PM ---------- Previous post was at 10:22 PM ----------

Well, usually, there should be just one process:

0 -> Create/Edit Mission File(s) -> Export scenario(s) -> Start Orbiter

Yes, that makes it MUCH easier, but it also closes the door on scenario updates between SSU versions.

---------- Post added at 10:25 PM ---------- Previous post was at 10:24 PM ----------

I think the mission should always be the overriding thing. It takes priority overt he scenario. The scenario is just that, the mission in various situations (OV in OPF just prior to S0004 for example). All the various details like the ET and SRB types should be in the mission file. Currently they're set in the scenario.

Yes, that's the way I'm thinking: if the defined pad in the mission file is 39A, and the pad vessel is at the 39B coordinates, 39A is what counts.

 

[Urwumpe]

Yes, that makes it MUCH easier, but it also closes the door on scenario updates between SSU versions.

Not as such - we would just treat the scenarios as artefacts generated from the mission files. So, yes, when SSU changes and allows new parameters, we need to support them by the workbench (should be so anyway) and create the scenarios again. Maybe we can make our lives easier one day to allow batch generation of a set of missions and scenarios.

For example, we could also make a command line tool with C++, that generates the scenario files based on the mission file. For release, we just execute this command line tool and automatically generate improved scenarios. Same when Orbiter changes and the scenario files support new features - we could then just update the generator, keep the mission files, and create new scenarios.

I think I like the command line tool idea, but I am aware that is a rather indirect way to solve the problem.

 

[GLS]

Not as such - we would just treat the scenarios as artefacts generated from the mission files. So, yes, when SSU changes and allows new parameters, we need to support them by the workbench (should be so anyway) and create the scenarios again. Maybe we can make our lives easier one day to allow batch generation of a set of missions and scenarios.

For example, we could also make a command line tool with C++, that generates the scenario files based on the mission file. For release, we just execute this command line tool and automatically generate improved scenarios. Same when Orbiter changes and the scenario files support new features - we could then just update the generator, keep the mission files, and create new scenarios.

I think I like the command line tool idea, but I am aware that is a rather indirect way to solve the problem.

With only one "flow path", I can probably do some more work. There is one more detail: how do we deal with other vessels? If we want to put an ISS, a Mir, a Hubble or the NCC-1701-D in a scenario, how do we decide where it goes and how do we store that in the mission file?

 

[Urwumpe]

With only one "flow path", I can probably do some more work. There is one more detail: how do we deal with other vessels? If we want to put an ISS, a Mir, a Hubble or the NCC-1701-D in a scenario, how do we decide where it goes and how do we store that in the mission file?

Well, I would say, we need to have a "mission target" then in the mission, that must be specified.

Much more complicated is defining the custom scenario parameters there, but maybe we can solve this by simply refering to a text file that contains the custom parameters for a vessel.

Also, a complicated scenario could be a multi-module spacestation of docked modules. But that can be solved by multiple ways.

Maybe we should define some block like "preconditions" for a mission, that describe, what needs to be there so a mission is possible. When we want to start a mission during a Orbiter session after a turn-around, and something is missing from the preconditions, the mission can't be selected (some sort of "game over"). And when a scenario for this mission is created, the preconditions are generated into the scenario to be automatically fulfilled.

So, by the preconditions, we then have all vessels described, that must be there (or could there also be optional vessels?) and we can specify which vessel from this list is the target for our mission (If it is no precondition, it makes no sense as target).

To be honest: The multi-module space station is my current favorite use case. A small set of assembly and service missions within a flight manifest, that can be flown without quitting Orbiter or by saving as current state and sending the scenario by mail to the next player to continue.

 

[GLS]

Well, I would say, we need to have a "mission target" then in the mission, that must be specified.

Much more complicated is defining the custom scenario parameters there, but maybe we can solve this by simply refering to a text file that contains the custom parameters for a vessel.

Also, a complicated scenario could be a multi-module spacestation of docked modules. But that can be solved by multiple ways.

Maybe we should define some block like "preconditions" for a mission, that describe, what needs to be there so a mission is possible. When we want to start a mission during a Orbiter session after a turn-around, and something is missing from the preconditions, the mission can't be selected (some sort of "game over"). And when a scenario for this mission is created, the preconditions are generated into the scenario to be automatically fulfilled.

So, by the preconditions, we then have all vessels described, that must be there (or could there also be optional vessels?) and we can specify which vessel from this list is the target for our mission (If it is no precondition, it makes no sense as target).

To be honest: The multi-module space station is my current favorite use case. A small set of assembly and service missions within a flight manifest, that can be flown without quitting Orbiter or by saving as current state and sending the scenario by mail to the next player to continue.

So basically you're saying that there's a solution for that problem. :lol:
So, for now I'll delete all the scenario read stuff (it has all been committed so if it is ever needed, it will be some revisions), and I'll reconfigure things for the new "flow", focussing for now on the SSU vessels only.

 

[Urwumpe]

So basically you're saying that there's a solution for that problem. :lol:
So, for now I'll delete all the scenario read stuff (it has all been committed so if it is ever needed, it will be some revisions), and I'll reconfigure things for the new "flow", focussing for now on the SSU vessels only.

yeah, that makes sense. :lol:


When I am back in sourceforge, I can take a look there at some command line tools, maybe I will need some additional file there for filling gaps that we are not saving in the mission file. For example, a mission folder needs a description, AFAIR Orbiter supports HTML now. So there should be a way to define this for the mission, and for the scenarios, we need good descriptions as well, which should better be hand-written.

 

[GLS]

I just committed changes to effect the new "work flow". It only saves scenarios for T-31 seconds (still have to decide when to put the control to control that), and only the MLP, Pad and LCC vessels are done and output all the scenario parameters (Pad still needs work for the 1985 version). The main SSU vessel doesn't have the subsystems and panels, and also the MFD section is also missing, and before I put more meat on the bones I'd like someone with more expertise than me to look at the code to make sure the architecture isn't heading to a cliff...

 

[K_Jameson]

When I read the word: "Workbench", my brains automatically go to this:

 

[Urwumpe]

When I read the word: "Workbench", my brains automatically go to this:

Yeah :lol:

Initially I wanted it to be a toolkit, then a toolbox and when it grew more, I thought workbench sounds more accurate.

 

[GLS]

I picked this up again... but I'm still struggling with the overall architecture.
The mission file has the mission information (config and launch for now), and then SSUW should take that and create a scenario at one of several pre-defined points in the "life time" of a mission (launch, orbit, entry, etc). The problem is how to handle stuff like OMS prop load: should that be defined in the mission file (just for launch or for every phase?) or should SSUW have pre-defined loads (or usages from initial load) for each phase? And then, how does the user define these things in SSUW? How much work should we leave for the user after he/she hits the create scenario button?
I just made this super-duper-high-quality detailed diagram of SSUW :lol: to help visualize things:

What should be done when the scenario is created (yellow arrow) vs having the user editing things (red arrows), either on the mission side or the scenario side?

One thing that I'm getting more and more convinced of is that we'll need to separate the mission IU from the scenario IU.... maybe having 2 independant editing stages... not really sure how to do that, especially with all the data binding to the mission and scenario objects...:shifty:

 

[Urwumpe]

Yeah, about that way.

I would add another factor there: The Flight manifest. Right now just as mission editor internal file format to manage multiple missions with the same set of hardware. For example, for defining which kind of hardware an Orbiter has and when it will see major changes, without needing to do this in each mission.

Yes, I also think separating scenario UI and mission UI is necessary. I would even go so far to have a "scenario stage" editor for defining which scenario files can be created by template - and just have a quick list of stages and checkbuttons for each stage to select which stages will be generated as scenario.

For keeping the data bindings under control, I would add a different kind of data model there - the UserMission or so. This is containing all data in a way how we can best edit the mission, while for saving or loading the mission files, we can use the Mission class defined in the way how we need the data for flying the mission. Mostly read-only then for SSU, maybe later with enough "windows" inside the mission files to allow a in-game mission control to react to simple events. A UserMission class could be composed then of multiple child classes containing the editable entities for the mission, which each are tied to the UI by view controllers...

...And then we need a way to also export "UserMission" data as PDF flight plan for printing, or custom checklists for custom payloads/missions....

 

[GLS]

Yeah, about that way.

I would add another factor there: The Flight manifest. Right now just as mission editor internal file format to manage multiple missions with the same set of hardware. For example, for defining which kind of hardware an Orbiter has and when it will see major changes, without needing to do this in each mission.

In all honesty, that seems a bit far in the future for me... getting some degree of automation in mission/scenario file creation is my goal. Everything else is a bonus.

Yes, I also think separating scenario UI and mission UI is necessary. I would even go so far to have a "scenario stage" editor for defining which scenario files can be created by template - and just have a quick list of stages and checkbuttons for each stage to select which stages will be generated as scenario.

Maybe having a second window, that overlays the main window, to handle the scenario editing could work. But it has to be done so some tabs of the main window can be reused (e.g. OMS/RCS need to be edited in the mission stage and also in the scenario stage).
As far as creating n scenarios all at once... that seems a bit greedy. I'll jump for 10 minutes in happiness if we get the "automated scenario creation" from 0 to 1. Having it create more than one scenario at one time means the user has to edit n descriptions, n dates, n vehicle states...

For keeping the data bindings under control, I would add a different kind of data model there - the UserMission or so. This is containing all data in a way how we can best edit the mission, while for saving or loading the mission files, we can use the Mission class defined in the way how we need the data for flying the mission. Mostly read-only then for SSU, maybe later with enough "windows" inside the mission files to allow a in-game mission control to react to simple events. A UserMission class could be composed then of multiple child classes containing the editable entities for the mission, which each are tied to the UI by view controllers...

...And then we need a way to also export "UserMission" data as PDF flight plan for printing, or custom checklists for custom payloads/missions....

The data binding issues were mostly related to the scenario vs mission thing, which should be solved with separate windows.



On the mission file, just to be sure: it should contain EVERYTHING that is configuration? E.g. Launch pad version, upper stage payload, adapter mesh name, mass and offset. Also on these, should those vessels read the mission file to extract their configuration parameters, like the main SSU vessel? Makes sense to me...
On consumables, having the launch loads in there seems a good idea, and something will have to be worked out to change the initial loads for the rest of the mission.

 

[Urwumpe]

On the mission file, just to be sure: it should contain EVERYTHING that is configuration? E.g. Launch pad version, upper stage payload, adapter mesh name, mass and offset. Also on these, should those vessels read the mission file to extract their configuration parameters, like the main SSU vessel? Makes sense to me...
On consumables, having the launch loads in there seems a good idea, and something will have to be worked out to change the initial loads for the rest of the mission.

Everything that is constant during a mission. So yes, the launch loads make sense in a mission file. The scenario files should only save data that varies during a mission.

For example: The exact software configuration would be pretty much constant during the mission -> Mission file.

Compool data on the other hand changes over time -> Scenario file.

 

[GLS]

Everything that is constant during a mission. So yes, the launch loads make sense in a mission file. The scenario files should only save data that varies during a mission.

For example: The exact software configuration would be pretty much constant during the mission -> Mission file.

Compool data on the other hand changes over time -> Scenario file.

For all vessels, right? That means they need to load the mission file as well.

 

[Urwumpe]

For all vessels, right? That means they need to load the mission file as well.

Well, practically, it must not be for all vessels. But: A mission involves all hardware assigned to it, so yes, a LC-39 also needs a mission assigned to it, just like VAB, LCC or OPF. And while a MLP isn't really that smart or manned, it also makes sense to assign the mission to it that it is assigned to, because it is not available for another mission then.

Maybe its smarter to have a mission master file with common data and refer to vessel specific mission files in it.

Also, because it could become a major pain to configure multiple missions with the same set of hardware, the flight manifest idea was to mitigate it, so common data for all missions of a manifest, like common vessel configurations can be stored there and don't need to be entered again and again.

 

[GLS]

Well, practically, it must not be for all vessels. But: A mission involves all hardware assigned to it, so yes, a LC-39 also needs a mission assigned to it, just like VAB, LCC or OPF. And while a MLP isn't really that smart or manned, it also makes sense to assign the mission to it that it is assigned to, because it is not available for another mission then.

Maybe its smarter to have a mission master file with common data and refer to vessel specific mission files in it.

Also, because it could become a major pain to configure multiple missions with the same set of hardware, the flight manifest idea was to mitigate it, so common data for all missions of a manifest, like common vessel configurations can be stored there and don't need to be entered again and again.

Correct my if I'm wrong, but to play with something like ISS assembly flights we just need to create a mission (file), edit it so it has RMS, ExtAl, set the launch time, pad, etc, and save it, and for the other missions you just reload that same file, change the OV and launch time and payload, and save with a new name. :shrug:

On the mission file(s), is it really wise to have 3 or 4 more files to work with? And in the end they would do +/- the same... in the end the data is the same, SSUW provides a UI for ease of editing and creates scenarios, and the vessels just read what they need. The only problem I can see is if we have more than one vessel of the same type in the scenario.