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
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
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: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.
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.
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-1If you still have it, go ahead and use it.
But that would not really work historically. STS-125 had a different table from STS-31R and they both went +/- to the same place.
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?
Yes, there were alot of changes during the program, and that's why it doesn't make sense to have:Well, just look at the changes to STS operations between the two:
RTLS ECAL was made available in 1994, after being in development since 1998.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
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.
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.
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:
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.Also, decisions like primary TAL site should be already coded into the mission file, because it is a pretty complex decision.
Istres replaced Ben Guerir after 9/11 for STS-114 and subs.
So, they're not at all complex.
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".
IMO it would make sense to hardcode that default list, like the rest of the mission data. :shrug:
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.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?
I just hate hardcoding things professionally,...
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.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...