SSU Workbench development

[GLS]

As the title says, this thread is for the discussion associated with the SSU Workbench development.

Currently the mission file IO is pretty much established, but the scenario file IO is still to be done in detail: read the file, load to memory all the information contained in it and then output a file equal to the original, should be an initial goal before we start massaging the data.

Another thing to be decided is the "default" location of the exe and how it finds its way in the Orbiter installation. Currently the location of the orbiter.exe is required at the start, so later when saving the program knows where the Missions folder is (the user can choose where the scenario file goes, but as default the save dialog opens in the "Scenarios/Space Shuttle Ultra" folder).

We're also missing the "new" and "open" icons for the menu.

One more thing: could/should we add this project to the "main" SSU solution file? It would only be for the 2013 solution, but it would allow to have all the code under one umbrella.

 

[Urwumpe]

Another thing to be decided is the "default" location of the exe and how it finds its way in the Orbiter installation. Currently the location of the orbiter.exe is required at the start, so later when saving the program knows where the Missions folder is (the user can choose where the scenario file goes, but as default the save dialog opens in the "Scenarios/Space Shuttle Ultra" folder).

I would keep it manual - people can have multiple installations of Orbiter and not all having SSU. But maybe being able to store defined Orbiter installations in the configuration of the Workbench would be wise.

EDIT: And keep it out of the solution. It is not yet depending on SSU artifacts and SSU does not depend on the Workbench during compilation.

 

[GLS]

Any idea about what the function of the "DX9ExtMFD" and "ExtMFD" scenario blocks? They seem to do nothing and are always empty....

 

[Urwumpe]

Any idea about what the function of the "DX9ExtMFD" and "ExtMFD" scenario blocks? They seem to do nothing and are always empty....

They are created during saving of a scenario if you have the respective plugins active in Orbiter.

 

[GLS]

They are created during saving of a scenario if you have the respective plugins active in Orbiter.

OK... so we don't need to write them when saving a scenario, right?

 

[DaveS]

OK... so we don't need to write them when saving a scenario, right?

No, that is taken care of by the plug-ins themselves.

 

[GLS]

I'm almost done with the code that loads and saves the (generic) vessel data in the scenario, and then only the specific data of the SSU vessels will need saving (subsystems, panels, animations, etc). I created a vessel class that holds the standard vessel data from the scenario, and then each SSU vessel derives its own class adding its specific data.
In doing this, I'm wondering what the exact relationship between "scenario" and "mission" should be: should the scenario be inside the mission, the mission inside the scenario, or should they be separate entities?

 

[Urwumpe]

In doing this, I'm wondering what the exact relationship between "scenario" and "mission" should be: should the scenario be inside the mission, the mission inside the scenario, or should they be separate entities?

A mission should have multiple scenarios, which act as "entry points" into the mission. Like starting at VAB Rollout or in Orbit, a scenario for each flight-day, etc.

So, mission and scenario are related, but not the same and must be separate. A scenario just allows to start a mission, at different mission states.

Above the missions, should be a "flight manifest" entity, which would make it easier to plan the next mission of an orbiter and to handle the turn-around from landed orbiter back to the stack. It would consist of the currently planned missions and their assigned orbiters.

Not sure if it makes sense to only have historic flight manifests or if it would be more interesting to allow a "campaign mode", in which a manifest is only an operational plan for the next year(s) and is followed by a next manifest, which is defined during run-time.

For example, for building a space station with SSU, it would make sense to have a full manifest for the construction phase of the station.

Would we get into failures and LOCV, it would then of course mean, that a manifest can also become obsolete and necessary to be replaced by an updated following manifest... so there would be some kind of workflow and state machine around manifests and missions.

(Just installing VC2015 here... approaching return to Orbiter development again, but I still need to get my sourceforge connection back online)

 

[GLS]

A mission should have multiple scenarios, which act as "entry points" into the mission. Like starting at VAB Rollout or in Orbit, a scenario for each flight-day, etc.

So, mission and scenario are related, but not the same and must be separate. A scenario just allows to start a mission, at different mission states.

Above the missions, should be a "flight manifest" entity, which would make it easier to plan the next mission of an orbiter and to handle the turn-around from landed orbiter back to the stack. It would consist of the currently planned missions and their assigned orbiters.

Not sure if it makes sense to only have historic flight manifests or if it would be more interesting to allow a "campaign mode", in which a manifest is only an operational plan for the next year(s) and is followed by a next manifest, which is defined during run-time.

For example, for building a space station with SSU, it would make sense to have a full manifest for the construction phase of the station.

Would we get into failures and LOCV, it would then of course mean, that a manifest can also become obsolete and necessary to be replaced by an updated following manifest... so there would be some kind of workflow and state machine around manifests and missions.

(Just installing VC2015 here... approaching return to Orbiter development again, but I still need to get my sourceforge connection back online)

I'm still digesting the whole post, but I have some questions: When we load a scenario, a new mission should be created from it, right? Another way to do things would be select a mission (how/where is that saved?), and then create a scenario at a certain point, right?

I'm trying to focus on the "basics" here, as IMO there's little point to think about big things if we can't even read the scenario file...

 

[Urwumpe]

I'm still digesting the whole post, but I have some questions: When we load a scenario, a new mission should be created from it, right? Another way to do things would be select a mission (how/where is that saved?), and then create a scenario at a certain point, right?

I'm trying to focus on the "basics" here, as IMO there's little point to think about big things if we can't even read the scenario file...

Well, when we start an scenario without a mission behind it, we should create a default mission in SSU for having suitable data available.

But generally, you load a scenario, which describes a state in the mission and the scenario refers to the mission.

The mission object should, like describe some time earlier, describe everything that is constant during a mission. The variable aspects of a mission should be handled in a mission state object, which is saved into the scenario. Every VESSEL that supports a mission should own and write its own mission state object.

 

[GLS]

I have a policy question about parameter output, both for the scenario files as well as for the mission files: should we always write all the parameters, or should we rely on the defaults in the main (C++) code and only write when the value is different from the default?

 

[Urwumpe]

I have a policy question about parameter output, both for the scenario files as well as for the mission files: should we always write all the parameters, or should we rely on the defaults in the main (C++) code and only write when the value is different from the default?

I think its safer to be explicit. (And write a known parameter regardless if its default or not)

For example, if a default value changes, we would need to track the change on both ends. No big problem, but as experience shows, a constant trouble spot that could be avoided.

Also, scenario file size is no problem yet.

 

[GLS]

So I've put the mission class and the scenario class "side-by-side", and managed to finally solve the issue of having the data of 2 classes on the screen! :woohoo:
Now I have a question about where the mission data is saved... should we add a few more parameters (launch site, ET type, etc...) to our existing mission file that are just used by the workbench (<< I like this) or should another set of files be created?

 

[Urwumpe]

So I've put the mission class and the scenario class "side-by-side", and managed to finally solve the issue of having the data of 2 classes on the screen! :woohoo:
Now I have a question about where the mission data is saved... should we add a few more parameters (launch site, ET type, etc...) to our existing mission file that are just used by the workbench (<< I like this) or should another set of files be created?

I think for those parameters one file should be enough for the start.

I would add another file to the mission, when data gets too complex. For example, should we do the step to include flight plans to the missions, having a special file for the flight plan might be better than stressing the simple structure of the mission file.

 

[GLS]

We're also missing the "new" and "open" icons for the menu.

So, what about using this set of icons?

https://commons.wikimedia.org/wiki/GNOME_Desktop_icons

 

[Urwumpe]

So, what about using this set of icons?

https://commons.wikimedia.org/wiki/GNOME_Desktop_icons

As long as we can use them with our license, its OK. I think I used a similar icon library already for a Java prototype of the workbench (with Java Ribbon UI)

But I think we should also create some of our own icons there.


Another question to the C# experts here: Is there a template processing library comparable to Freemarker in C#?

http://freemarker.org/

If yes, we could simplify a lot of the scenario file generation and other output tasks by it. For example, we could also use it for generating mission specific FDFs by processing templates into XML-FO files and translate those into PDF.

 

[GLS]

Just added a few more scenario parameters and finished adding the "existing" mission parameters. I added new parameters to the mission file for launchsite, SRM and ET, and plugged them to the window for user control, but I seem to have hit a wall on how to get that to do... something... so the scenario data reflects those parameters. :facepalm:

 

[DaveS]

Just added a few more scenario parameters and finished adding the "existing" mission parameters. I added new parameters to the mission file for launchsite, SRM and ET, and plugged them to the window for user control, but I seem to have hit a wall on how to get that to do... something... so the scenario data reflects those parameters. :facepalm:

Have you checked the actual vessel code? It could be that the scenario saving/loading code is there but the actual code to do something with those parameters are null and void.

 

[GLS]

Have you checked the actual vessel code? It could be that the scenario saving/loading code is there but the actual code to do something with those parameters are null and void.

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.

 

[Urwumpe]

Just added a few more scenario parameters and finished adding the "existing" mission parameters. I added new parameters to the mission file for launchsite, SRM and ET, and plugged them to the window for user control, but I seem to have hit a wall on how to get that to do... something... so the scenario data reflects those parameters. :facepalm:

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.