Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Space Shuttle Ultra Support & development threads for Space Shuttle Ultra addon.

Reply
 
Thread Tools
Old 09-20-2016, 02:26 PM   #1
GLS
Addon Developer
 
GLS's Avatar
Default SSU Workbench development

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.
GLS is offline   Reply With Quote
Old 09-20-2016, 07:20 PM   #2
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 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.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 09-29-2016, 01:08 PM   #3
GLS
Addon Developer
 
GLS's Avatar
Default

Any idea about what the function of the "DX9ExtMFD" and "ExtMFD" scenario blocks? They seem to do nothing and are always empty....
GLS is offline   Reply With Quote
Old 09-29-2016, 01:11 PM   #4
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 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.
Urwumpe is offline   Reply With Quote
Old 09-29-2016, 01:33 PM   #5
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 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?
GLS is offline   Reply With Quote
Old 09-29-2016, 01:44 PM   #6
DaveS
Addon Developer
 
DaveS's Avatar


Default

Quote:
Originally Posted by GLS View Post
 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.
DaveS is offline   Reply With Quote
Thanked by:
Old 01-21-2017, 10:38 AM   #7
GLS
Addon Developer
 
GLS's Avatar
Default

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?
GLS is offline   Reply With Quote
Thanked by:
Old 01-21-2017, 11:26 AM   #8
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 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)
Urwumpe is offline   Reply With Quote
Thanked by:
Old 01-21-2017, 02:18 PM   #9
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 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...
GLS is offline   Reply With Quote
Old 01-21-2017, 02:30 PM   #10
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 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.
Urwumpe is offline   Reply With Quote
Old 01-23-2017, 03:51 PM   #11
GLS
Addon Developer
 
GLS's Avatar
Default

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?
GLS is offline   Reply With Quote
Old 01-23-2017, 03:53 PM   #12
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 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.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 01-25-2017, 12:05 AM   #13
GLS
Addon Developer
 
GLS's Avatar
Default

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!
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?
GLS is offline   Reply With Quote
Old 01-25-2017, 08:34 AM   #14
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by GLS View Post
 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!
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.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 01-25-2017, 02:43 PM   #15
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by GLS View Post
 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
GLS is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > Addon Support & Bugs > Addon Developer Forums > Space Shuttle Ultra


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 04:55 AM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.