SSU Workbench development

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
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.

Yes - and if you change something at the first mission, you repeat the whole process. If WE change something deep inside SSU, the same.

If we have a manifest concept, we can at least reduce the work to those cases where a human decision is needed. And since we will change a lot, its a good idea to keep the work low in advance.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Yes - and if you change something at the first mission, you repeat the whole process. If WE change something deep inside SSU, the same.

If we have a manifest concept, we can at least reduce the work to those cases where a human decision is needed. And since we will change a lot, its a good idea to keep the work low in advance.

But then SSUW will have to update x files at once... it's a tall montain to climb making this work for 1 file at a time, making this do batch editing fells like the Everest...
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
But then SSUW will have to update x files at once... it's a tall montain to climb making this work for 1 file at a time, making this do batch editing fells like the Everest...

Not that much, since we are about to add subsystems, currently not existing at all. Or add variables currently not existing. Important is just having the flight plan and orbit data available soon.

Also its not batch editing. Its rather "Batch updating". You open a manifest file for an old version of SSUW, and we could automatically run a series of update procedures (or even update scripts) to fix things. The focus of the editor could then still remain at one mission, we could just make opening the mission easier by allowing to select it from a manifest window (instead of having path/filename decisions)
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Not that much, since we are about to add subsystems, currently not existing at all. Or add variables currently not existing. Important is just having the flight plan and orbit data available soon.

Also its not batch editing. Its rather "Batch updating". You open a manifest file for an old version of SSUW, and we could automatically run a series of update procedures (or even update scripts) to fix things. The focus of the editor could then still remain at one mission, we could just make opening the mission easier by allowing to select it from a manifest window (instead of having path/filename decisions)

In all honest, that seems so far in the future... I don't even want to think about it.
I'm now creating the "scenario window" that will bind to the scenario object.
Currently we have vessel objects inside the scenario object that I'm not really happy about. Maybe creating them in the mission object, and then when/if the user wants a scenario, those vessel objects are passed to the scenario object so the final touches can be made and the scenario output generated.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
In all honest, that seems so far in the future... I don't even want to think about it.

Well, I think different there. I think a coarse flight plan and some metadata about the mission would be all it takes there and we really could use it for various aspects there to make the life easier - from updating past scenarios when new subsystems are added to assisting the player ingame.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Well, I just hit my quota of C# and WPF for today... :compbash:
Current state: just finished setting up the scenario window, moved the scenario tab into it and renamed all the bindings as each window now only has one object to deal with... and it works as before. I'll commit things in a bit.

About the mission file and the upper stage parameters*, should those vessels load it to extract the payload adapter data? (I'd really like a positive answer so I can play with C++ now :lol:)


*) thinking more about it, I now believe pad versions should be handled with config files, which we can choose via scenario file, which will come from SSUW, so it all still works.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
About the mission file and the upper stage parameters*, should those vessels load it to extract the payload adapter data? (I'd really like a positive answer so I can play with C++ now :lol:)

Well........ I vote for yes.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
It was an easy task, but it took much longer than expected due to a "mini" family emergency.
Anyway, I moved not only the upper stage adapter parameters (using the same name for both stages as a mission can't have both) but also the IUS antennas, RCS tanks and SRM loads, i.e., all that is static.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
At the moment it is more "work waiting to be done"... :facepalm:
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
At the moment it is more "work waiting to be done"... :facepalm:


Maybe I can give it a try while being unable to properly test SSU. But I can't guarantee perfect quality because of the testing issues and I am still a C# noob, despite now even doing small C# projects at work.

Any small function that should be done for a start so I can get into the development?
 
Last edited:

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
But I can't guarantee perfect quality because of the testing issues and I am still a C# noob, despite now even doing small C# projects at work.
Are you quoting me? :lol:

---------- Post added at 07:20 PM ---------- Previous post was at 07:17 PM ----------

Any small function that should be done for a start so I can get into the development?

AFAIR, the file IO is pretty much done. The main issue is data organization and also data flow to/from the window controls (or widgets or whatever millennials call them).
Just follow the "open" or "new" command and things will show up.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Kicked this a bit more forward in the last few days: updated the icons, removed some things that didn't work or aren't needed, and added more "meat" to the existing bones, so right now SSUWorkbench can create (incomplete) "launchable" scenarios!!! :hailprobe:
Launch site selection and details are probably acceptable (a.k.a., done for now), and most subsystems and panel now show up in the scenario. Currently only 2 scenario start points exist (T-9m and T-31s), and the switch configuration should be correct, unlike some/most of the current launch scenarios. (once this thing is working the launch scenarios get (re-)build, so no point in editing those manually now)

Currently, there are 3 big holes: MFDs, propellants and payloads.
Maybe 95% of the logic for the MFDs is done... except the existing architecture wasn't really thought well enough for this... :facepalm: I dug the hole, so I can probably come up with a way around it.

The propellant resource "mess" makes playing with this a bit hard. (I started with the new order in the RCS branch, but I think we'll need a wrapper to simulate 2 tanks with one propellant resource... another story for another place)
Currently a fixed propellant loads are being set, but a few new controls could be added to allow further control, which shouldn't be a problem for now with only launch configurations... :shrug:

The payload section still needs work, both to add describe the payloads in the mission file, as well as adding the capability to select and place payloads in the vehicle, and then cook all that data to produce the correct scenario parameters. Related to the payloads is the upper stage selection (and its payload).
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Just committed changes to allow payload selection on PLB, upper stages and starboard MPMs. The visual layout could probably be better, but connecting that to the data structures isn't exactly easy.
The same goes for the upper stages, although I managed to come up with a solution that allows the selection of only one of the (current) stages, and allow future expansion for the 3 PAM types.
The payloads are now declared in the mission file, exclusively for scenario file generation. They are not used by the vessels, so existing mission files and scenarios will still run in Orbiter with no issues, but they payloads will not show up in SSU Workbench. I've updated the existing mission files, but there is no need to change the scenarios for now (release looming and scenario output still isn't finished).
No support currently exists for payload vessel-specific scenario parameters, only the default Orbiter parameters. That would require addition of more parameters to the mission file, and it's probably a good idea to wait until a structured mission file is created to allow for better parameter organization.

One big question is "what is the mass of the payload?" That can only be obtained for "config file" vessels, because for "dll vessels" masses are inside the dll, so we can't tell the user what the payload mass currently is. Same goes for the payload attachment index, so that has to be input manually. I have logic to read those parameters from the config files, but due to lack of window space and the issues above they are disabled.
BTW: the payload selection wasn't tested with SC3 payloads.

Another issue is related to the mission file name and the mission name. Currently the mission name is written in the scenario to connect it to a mission file, but there are no guaranties that the mission file was saved with the mission name (or saved at all). So some more work is still required in the workflow to make sure there are not loose ends.


So, I'd say SSU Workbench is (almost) "operational", just like the shuttle was on STS-1... :shifty:
Please, play with it and complain.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I'm just getting crashes here. Is there anything specific I need to do?
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
I'm just getting crashes here. Is there anything specific I need to do?
Loading what file? The mission files in the repository all loaded fine here... :shrug:
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Loading what file? The mission files in the repository all loaded fine here... :shrug:
Any of them, even clicking on the New Mission button makes it crash. Essentially doing anything will make it crash.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,868
Points
188
Website
github.com
Any of them, even clicking on the New Mission button makes it crash. Essentially doing anything will make it crash.

A crash on load/save is possible as there is little error checking for now, but that seems something more fundamental... :uhh:
How are you running it?
Can you run in debug/attached (should be key F5 in VS) and report the error and its location?
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
All crashes point to line 138 in SSU.Workbench.Model.Mission of Mission.cs. The error is System.IndexOutOfRangeException, 0x80131508.
 
Top