SSU V1.25 Release

Status
Not open for further replies.
OK, small big update:


  • Mission files are now supported, just need some more information read and used.
  • Moved the math functions from Atlantis.h into separate headers, for reducing the dependencies.
  • AC motors are still not working well, but at least I now know what thinking error I had in the math.

Next stage for the mission files will be making a libssu library, which can be used in other projects, which connects to the SpaceShuttleUltra.dll and uses it's central mission file handling. This way, we only need to load the mission configuration file once, which should make us pretty happy when the file size grows in the future.
 
Next stage for the mission files will be making a libssu library, which can be used in other projects, which connects to the SpaceShuttleUltra.dll and uses it's central mission file handling. This way, we only need to load the mission configuration file once, which should make us pretty happy when the file size grows in the future.

Could you be more specific, how this works ?
 
Could you be more specific, how this works ?

Pretty much like Orbitersound. The module of SSU exports one or more functions extra as DLL and other modules can call them.

Currently I just want to use the ssuGetMission() function for testing the idea, but this could also be used well for handling radio communications in a robust way.
 
How easy would it be to add whether the ODS should be flown or not to the mission files? Then I'm talking about actually having the ODS separate from the External Airlock.

Something like:
Code:
ExtAL=true
ODS=false
We need that to properly simulate the STS-125 mission as it lacks the ODS but not the airlock.
 
How easy would it be to add whether the ODS should be flown or not to the mission files? Then I'm talking about actually having the ODS separate from the External Airlock.

Something like:
Code:
ExtAL=true
ODS=false
We need that to properly simulate the STS-125 mission as it lacks the ODS but not the airlock.

my current idea was to make the External Airlock Configuration a integer variable:

0 = no airlock
1 = external airlock
2 = external airlock + ODS
3 = internal airlock

The numbers could get changed, for example making the airlock config a bitfield.

0 = no airlock
1 = external airlock
2 = only ODS (not possible)
3 = external airlock + ODS
4 = internal airlock
7 = internal airlock + external airlock + ODS
8 = Duct taped to the station
 
How about adding support for the Toolbox Stowage Assemblies(TSAs) on the airlock truss? Currently we're flying none, but they usually fly one or both as they contain important tools and equipment, like the NOAX repair equipment.
 
How about adding support for the Toolbox Stowage Assemblies(TSAs) on the airlock truss? Currently we're flying none, but they usually fly one or both as they contain important tools and equipment, like the NOAX repair equipment.

Implemented already over attachments. The position of the attachments just might need some tweaking.
 
Implemented already over attachments. The position of the attachments just might need some tweaking.
OK, what numbers do they have?
 
OK, what numbers do they have?

oh... good question. Should have been two of the first attachments, which change their position and orientation when you fly without external airlock.
 
oh... good question. Should have been two of the first attachments, which change their position and orientation when you fly without external airlock.
I've checked in the TSA mesh and config files for port and starboard TSAs, so could you see if you could tweak the numbers?
 
I've checked in the TSA mesh and config files for port and starboard TSAs, so could you see if you could tweak the numbers?

I will, also I think we should badly upgrade the documentation before release.
 
I will, also I think we should badly upgrade the documentation before release.
Yes, listing what each attachment is for. Even I have hard time memorizing what each attachment is for.
 
Yes, listing what each attachment is for. Even I have hard time memorizing what each attachment is for.

I will power-up inkscape after I finished cleaning the house, and make a map of the attachments.
 
Also need a tunnel adapter for STS-88. :)
 
my current idea was to make the External Airlock Configuration a integer variable:

0 = no airlock
1 = external airlock
2 = external airlock + ODS
3 = internal airlock

The numbers could get changed, for example making the airlock config a bitfield.

0 = no airlock
1 = external airlock
2 = only ODS (not possible)
3 = external airlock + ODS
4 = internal airlock
7 = internal airlock + external airlock + ODS
8 = Duct taped to the station

Also need a tunnel adapter for STS-88. :)
Could be part of configuration 7 above as that is how the Shuttle/Mir missions that used Atlantis was configured.
 
0 = no airlock
1 = external airlock
2 = external airlock + ODS
3 = internal airlock

Just a heads up, the orbiter always has an airlock. You might need an EVA to close the PLBDs, and they are always opened inflight so.... unless you want to save that funcionality for a future Shuttle-C mod to SSU.;)
 
Just a heads up, the orbiter always has an airlock. You might need an EVA to close the PLBDs, and they are always opened inflight so.... unless you want to save that funcionality for a future Shuttle-C mod to SSU.;)

STS-107 did not have an airlock AFAIR.
 
STS-107 did not have an airlock AFAIR.
Actually, Columbia did have an internal airlock on 107. The two EVs was Dave Brown and Mike Anderson. They had received the standard contingency EVA training and they had two EMUs stored onboard for that purpose.

The ability to do a contingency EVA is a must. So in between Columbia's internal airlock and SpaceHAB was a Tunnel Adapter Assembly(TAA).

The TAA has three hatches, two along its longitudinal axis and one along its vertical axis: http://www-pao.ksc.nasa.gov/kscpao/images/large/02pd0978.jpg

It is the vertical hatch on the TAA that allows for an EVA when the standard EVA airlock hatch is otherwise occupied by something else.
 
SSU_Attachments.png


Here is a first graphic of the SSU parent-child attachments. Would need some minor improvements, but I think it is better to gather some feedback now.
 
OK, based on those graphics I have discovered a bug with the TSA attachments. The TSA attachments are those for the MMU Flight Support Stations(MMU FSS) attachments, not for the TSAs on the airlock truss. If I remember right, only Challenger and Discovery ever received the modifications necessary for the MMU FSS. The Challenger accident happened before Columbia and Atlantis was modified to support them. And naturally, the MMU was retired long before Endeavour flew for the first time.

Needs fixing before release.
 
Status
Not open for further replies.
Back
Top