SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[Wolf]

Willing yes.

But I am disqualified.

May I put a SCA in the wishlist? With O2016 a trip from EDW/NOR to KSC would be nice :thumbup: not to mention the ALT on the Enterprise with the Antelope Valley addon in the background

 

[Urwumpe]

May I put a SCA in the wishlist? With O2016 a trip from EDW/NOR to KSC would be nice :thumbup: not to mention the ALT on the Enterprise with the Antelope Valley addon in the background

Again: I am disqualified there. I think somebody else should code this. It must not even be somebody from already developing SSU.

 

[GLS]

What about having two or three default lists that ship with SSUs config-folder contents?

Basically, we just need a set of landing sites just depending on the following input parameters: Launch site and launch azimuth. These two parameters are already enough to switch between default lists.

So, having tables defined for "KSC-low inc", "KSC-high inc", "VAFB" would likely solve 99% of all problems.

If we use a mission editor there, this would be even more easy because the logic which set of landing sites to select could then be defined more sophisticated and moved there instead of having it in the C++ runtime.

In reality, the landing sites did not just depend on the ascent trajectory, but also on the changes to the Space Shuttle operations and software. Before STS-51L there had been different sets of landing sites possible at all.

But that would not really work historically. STS-125 had a different table from STS-31R and they both went +/- to the same place. And that wouldn't allow you to land the shuttle near you place. :lol:
So I think giving the user the capability to build the table is much more flexible. We would have 1 or 2 "default" ones, probably not covering all the runways (which I want to have), and then the user can build the rest of the tables as needed.

Yes, it should/will be handled by SSUW... we just need a pair of hands to work in there... :uhh:

For storing the runway info, a single CSV file could contain all the data, and the site table could be another CSV file with lines "1,KSC15,KSC33", "2,EDW22,EDW04", etc, or we could bypass the whole table list file and put the list explicitly in the mission file (not flexible IMO).

BTW: any idea how this was handled in the sw? Probably ILOADs right?

 

[Donamy]

Speaking of landing sites: Anyone willing to work on a SSU STA? We already have a mesh+textures if Donamy would allow us to use his old Shuttle Fleet STA.

If you still have it, go ahead and use it.

 

[DaveS]

If you still have it, go ahead and use it.

You don't mind if I fix some some of the visible edges? The original Shuttle Fleet aircraft package is still available on Simviation: https://simviation.com/1/browse-Space+Orbiter-111-1

 

[Donamy]

I don't mind at all. Good luck !!

 

[Urwumpe]

What I meant actually was having default lists as fall-back, should no custom landing site list be defined. We always need a list for the GNC software.

But that would not really work historically. STS-125 had a different table from STS-31R and they both went +/- to the same place.

Well, just look at the changes to STS operations between the two:

Mission | Software | RTLS ECAL | 1EOACA | Automatic ECAL entry | TAL Delay | Size of landing site table | TAL Sites
STS-31|OI-8C|No|No|No|No|50|All
STS-125|OI-32|Yes|Yes|Yes|Yes|90|Reduced to save costs

RTLS ECAL was made available in 1994, after being in development since 1998.
1EOACA : Single Engine Out Automated Contingency Abort, introduced in OI-21, 1992.
Automatic ECAL entry was introduced with OI-28, 2002
Landing site table was optimized later to store 90 entries into approximately the same amount of GPC memory.

A large number of former TAL landing sites also had been removed later, due to operation costs.

For storing the runway info, a single CSV file could contain all the data, and the site table could be another CSV file with lines "1,KSC15,KSC33", "2,EDW22,EDW04", etc, or we could bypass the whole table list file and put the list explicitly in the mission file (not flexible IMO).

I would just put a reference to such a CSV list into the mission file.

BTW: any idea how this was handled in the sw? Probably ILOADs right?

Yes.

 

[GLS]

Well, just look at the changes to STS operations between the two:

Mission | Software | RTLS ECAL | 1EOACA | Automatic ECAL entry | TAL Delay | Size of landing site table | TAL Sites
STS-31|OI-8C|No|No|No|No|50|All
STS-125|OI-32|Yes|Yes|Yes|Yes|90|Reduced to save costs

RTLS ECAL was made available in 1994, after being in development since 1998.
1EOACA : Single Engine Out Automated Contingency Abort, introduced in OI-21, 1992.
Automatic ECAL entry was introduced with OI-28, 2002
Landing site table was optimized later to store 90 entries into approximately the same amount of GPC memory.

A large number of former TAL landing sites also had been removed later, due to operation costs.

Yes, there were alot of changes during the program, and that's why it doesn't make sense to have:
if (feature x) load tableA
else if (feature y) load tableB
else....
We would have to specify "rules" for having site A or B, etc, and that seems trouble. By allowing "manual" site placement, we can easily make the historical tables, as well as fictional ones.

On the default table list, we assume than that our default file always exists? We put it in the default mission and it's the one used if not overriden by the mission file. About the actual loading of the data, IMO makes sense to place it all inside the LandingSiteData class, and just give it the table file name.

Also, folder for the tables and the landing site "database"? We have the aero stuff in the "Config", MMU stuff in "Data/SSU" (which AFAIK does nothing) and the "Missions/SSU" folder, these last 2 are created by us.

 

[Urwumpe]

Also, folder for the tables and the landing site "database"? We have the aero stuff in the "Config", MMU stuff in "Data/SSU" (which AFAIK does nothing) and the "Missions/SSU" folder, these last 2 are created by us.

Data/MMU was mostly a test balloon from a time, when it looked like it might be possible to get real STS software. It makes less sense like it is now for the DPS MMU, a virtual file system can do the job better, especially since we have a lot of resources available during loading the scenario - the whole work what the various linker stage tools of the real software did for determining memory allocation and tape structure could be done before simulation starts.

Maybe it makes sense to keep the code and folder for other tape drives - for example, the engine telemetry is stored on tape during launch and played back later. Of course, we could also just write such telemetry directly for debugging - but it would have something immersive if this data would only be available after getting it transmitted successfully to a ground station/TDRSS

Well, back to topic:

I used the config folder for storing data constant for the whole project - as ROM.

I would write mission specific data rather into Missions/SSU then.

For default landing site tables, the ROM location/config folder would make more sense. For mission specific tables, the Missions folder would be better.

 

[GLS]

For default landing site tables, the ROM location/config folder would make more sense. For mission specific tables, the Missions folder would be better.

The inconsistency there is that our "default" table will/should still be a mission table... :shrug:

 

[Urwumpe]

The inconsistency there is that our "default" table will/should still be a mission table... :shrug:

Again, as I had explained above:

The usual way of defining this would be a mission-specific table, exactly for not doing complex mathematical calculations with hundreds of input parameters in the DLL. Also, decisions like primary TAL site should be already coded into the mission file, because it is a pretty complex decision.

But if the definition would be missing, we still need a table for the GNC software, so a default table should be provided to fill the gap. Or multiple tables that are providing more a more useful selection of landing sites than "one list fits all".

 

[DaveS]

Also, decisions like primary TAL site should be already coded into the mission file, because it is a pretty complex decision.

Not really. TAL sites are based on ascent trajectory. Can't go to Istres if your going due east. ECAL isn't available for those missions either. Istres replaced Ben Guerir after 9/11 for STS-114 and subs. Also TAL site decisions primarily based on weather. So, they're not at all complex.

 

[Urwumpe]

Istres replaced Ben Guerir after 9/11 for STS-114 and subs.

For example: How to code OSI layer 8 decisions into it?

So, they're not at all complex.

I disagree:

• Available landing sites is complex and political.
• There are many factors going into the TAL envelope, the region on the surface of Earth that can be reached by a TAL abort.
• Especially, the number of available TAL abort scenarios (how many engines out) did change over time and technology.
• Finally, there are often decisions that are not just based on physics: What if one TAL site is slightly in terms of required energy but is fully equipped for a Space Shuttle, while the other site just has some training in handling a Space Shuttle?

 

[GLS]

Again, as I had explained above:

The usual way of defining this would be a mission-specific table, exactly for not doing complex mathematical calculations with hundreds of input parameters in the DLL. Also, decisions like primary TAL site should be already coded into the mission file, because it is a pretty complex decision.

But if the definition would be missing, we still need a table for the GNC software, so a default table should be provided to fill the gap. Or multiple tables that are providing more a more useful selection of landing sites than "one list fits all".

Recap:
- "runway database" goes in "Config" next to the aero data, as it is fixed
- landing site tables go in "Missions/SSU", as they are mission specific
- the default landing site table goes in "Config", as it is fixed

I don't "like" the last one, as even being a default list, it is still (or should be) a mission list being part of the default mission (STS-101).
I'm not saying it's wrong to go in that folder, but somehow it doesn't make sense. IMO it would make sense to hardcode that default list, like the rest of the mission data. :shrug:

 

[Urwumpe]

IMO it would make sense to hardcode that default list, like the rest of the mission data. :shrug:

I just hate hardcoding things professionally, because hardcoded information requires more quality assurance. If we need a function to load a list of landing sites anyway, why not using it also for the defaults already?

 

[DaveS]

Finally, there are often decisions that are not just based on physics: What if one TAL site is slightly in terms of required energy but is fully equipped for a Space Shuttle, while the other site just has some training in handling a Space Shuttle?

All the official TAL sites were fully equipped and certified for shuttle landings. They wouldn't be designated TAL sites otherwise. Same for the nominal EOM sites (KSC, NOR, EDW and VBG). Most of the sites in the table are Contingency Landing Sites (CLS), the ECALs included.

These are not official shuttle landing sites and have no equipment or personnel to handle an orbiter. Their only qualifier is that they have a runway long enough to support and shuttle landing.

 

[Urwumpe]

So, there is alone a flag somewhere in the decision "official TAL site".

 

[Capt_hensley]

I just hate hardcoding things professionally,...

Only things that will never change, should be hard coded. Everything else is a variable, by definition.

However there are limits to to what should be active, and what should terminate but stay resident. You don't have your landing checklist on the HUD at T-5 for liftoff.

You guys are doing amazing things with a simulated spacecraft in a simulated world, producing simulated effects, to get simulated results. Take 5 seconds, go back and look at your block diagram. It all comes into perspective as "Cause, affect, result" Keep up the good work!:thumbup:

 

[GLS]

DaveS, could the RCS plumes be smaller? Even using D3D9 it becomes a slide show whenever the RCS are used, and forget about time acceleration as even 10x results in disaster. You probably want the plumes to look like they did in the night views, but it can't be. A middle ground between night (very visible) and day (almost invisible) has to be found.

Also, what is the deal with the exhaust textures? You never explained you idea...

 

[DaveS]

DaveS, could the RCS plumes be smaller? Even using D3D9 it becomes a slide show whenever the RCS are used, and forget about time acceleration as even 10x results in disaster. You probably want the plumes to look like they did in the night views, but it can't be. A middle ground between night (very visible) and day (almost invisible) has to be found.

Also, what is the deal with the exhaust textures? You never explained you idea...

No issues with the frame rate here (GeForce GTX 1070). Even with my older 970 particle streams were never an issue. You could try reducing the source rate (this is the rate at which the particles are created). As for the exhaust, I just thought it looked better without that old thing.