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

[GLS]

It's just the covers and the foam that goes on in the RPSF, nothing more. The stiffener rings are already there.

The rings are what is bolted. What is built-in the case is the stiffener ring stub, which is where the stiffener ring is bolted.

 

[Wolf]

About the APU sound: I still hear them running when inside the Orbiter flight deck (internal view)
This is not supposed to happen, right?

 

[GLS]

About the APU sound: I still hear them running when inside the Orbiter flight deck (internal view)
This is not supposed to happen, right?

Probably not... :uhh:
I'll make it external only when I get home tonight.

 

[Wolf]

Probably not... :uhh:
I'll make it external only when I get home tonight.

I thought it was an issue on my end only since I have some weird stuff happening with Orbiter sound. For example during first stage if I switch the view to another vessel (i.e. the ISS) and then go back to SSU view the engines sounds is gone (as if I was already in second stage) this doesn’t always happen though. Also if I zoom away from the orbiter the SSME sound level does not decrease but it keeps the same volume instead.

I recently changed the SSME-sustain sound with a customized .wav file. Maybe this could be causing these issues?

 

[GLS]

I thought it was an issue on my end only since I have some weird stuff happening with Orbiter sound. For example during first stage if I switch the view to another vessel (i.e. the ISS) and then go back to SSU view the engines sounds is gone (as if I was already in second stage) this doesn’t always happen though. Also if I zoom away from the orbiter the SSME sound level does not decrease but it keeps the same volume instead.

I recently changed the SSME-sustain sound with a customized .wav file. Maybe this could be causing these issues?

Probably not. I'll look at those issues as well.
BTW: why would you switch to the ISS during first stage? :shrug: :lol:

 

[Wolf]

BTW: why would you switch to the ISS during first stage? :shrug: :lol:

Cause I totally trust your ascent guidance system :lol:

To be more clear the issue happens when I select another vessel (not just switching the view target) and even after replacing the .wav file with the originsl one

 

[DaveS]

Cause I totally trust your ascent guidance system :lol:

To be more clear the issue happens when I select another vessel (not just switching the view target) and even after replacing the .wav file with the originsl one

Are using just OrbiterSound? I'm thinking that this might be another OrbiterSound bug related to Orbiter 2016, OrbiterSound isn't fully compatible with Orbiter 2016, which is why dbeachy1 developed XRSound. XRSound can take full advantage of OrbiterSound implementations through a special bridge module developed by face, which can be found here: [ame="https://www.orbithangar.com/searchid.php?ID=7209"]SoundBridge[/ame]


Could you try that and see if the problem goes away? If so, it isn't an SSU problem but rather an OrbiterSound problem.

---------- Post added at 02:34 PM ---------- Previous post was at 02:23 PM ----------

The rings are what is bolted. What is built-in the case is the stiffener ring stub, which is where the stiffener ring is bolted.

I'm still not convinced as this document on damages that the STS-1 SRBs suffered, mentions the forward stiffener ring on page 21: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19820012361.pdf
Despite the poor quality of the photo, I can deduce that the component in question is the Sta. 1773.56 stiffener ring on the Right-Hand aft SRM segment.

 

[DaveS]

And here's where it is stated that the aft segment of the FWC SRM has "graphite/epoxy composite aft segment case cylinder with integral stiffener ring".

 

[DaveS]

For reference, I found this photo of the left aft SRM segment being stacked on MLP-1 in HB-3 of the VAB for STS-1, showing the fully closed out stiffener rings. As you can see, they're not that thick and could easily have been baked into the general case cylinder design for the FWC given its increased diameter over the D6AC steel counterpart.

One interesting tidbit that I have dug up was that at the time of the STS-51L accident, they had not qualified the FWCs for re-use. This per Jesse Moore, the Associate Administrator for Spaceflight at NASA HQ at that time, in his initial testimony to the Presidential Commission:

We have a major question that the program is looking at right now, and we probably won't get any good data on that until later downstream, and our question among others that is currently on the table about the graphite/epoxy cases today, is can we reuse them? You know, currently we reuse the steel cases. The Shuttle returns, it has engines the back, the SRBs are returned. They have parachutes on them. We go back and retrieve the SRBs and go through and refurbishment cycle on to reuse them. For the graphite/epoxy cases , we are doing some final testing at this point in time, and we are not sure whether or not we can reuse those filament wound cases after we fly them and they come back and impact the ocean. We have not made an determination like that, so we are not planning to get out of the steel SRB business at this point in time. We have a lot of additional work on the filament wound cases.

This his answer to question asked by Dr. Arthur Walker, a member of the Commission if NASA had any plans to phase out the steel SRBs once the composite SRBs had phased in. This exchange can be found on page 18 of this document: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19860019504.pdf

 

[Wolf]

Are using just OrbiterSound? I'm thinking that this might be another OrbiterSound bug related to Orbiter 2016, OrbiterSound isn't fully compatible with Orbiter 2016, which is why dbeachy1 developed XRSound. XRSound can take full advantage of OrbiterSound implementations through a special bridge module developed by face, which can be found here: SoundBridge


Could you try that and see if the problem goes away? If so, it isn't an SSU problem but rather an OrbiterSound problem

I am using Orbiter Sound. Tried the Sound Bridge but the issue remains

 

[GLS]

The APU sound only plays in external view now. Will look at the SSME issue tomorrow... today already.

 

[Snax]

Just to add my 2c, I have the same issue as wolf regarding the SRB sounds.

During SRBs ignition, I can zoomin/zoomout very quickly and hear the volume increase/decrease, but I realized as soon as the sound switches to "sustain", the volume will remain the same depending on the distance I was from the Orbiter in external view (F2) untill SRB Sep, even when the volume should decrease as we're leaving the atmosphere, it does not.


I only have this with SSU in 2016 as with SSU v4.2 in Orbiter 2010 I don't have this behaviour, I can zoomin/zoomout during ascent and normally hear the sound volume change accordingly, with the volume changing as the Orbiter is leaving the atmosphere.

so I guess it's related to OrbiterSound, but also this is the only addon I have this issue in orbiter 2016. Perhaps other devs found a way to solve this in Orbiter 2016.

 

[Wolf]

Don’t know if this is related to Orbiter Sound since I have the same issues with SoundBridge module by dbeachy1 :shrug:

 

[DaveS]

When you say that you're "using the SoundBridge module", do you mean you're using it straight up on its own or in addition to XRSound? The last part is important. The SoundBridge module isn't a standalone module, it's a bridge module that is to be used to bridge the API calls specific to XRSound and the API calls that are specific to OrbiterSound. So, it should only be used with XRSound enabled, in fact that's why it should be allowed to overwrite the original OrbiterSound.dll file in Modules/Plugin.

---------- Post added at 02:06 PM ---------- Previous post was at 02:03 PM ----------

During SRBs ignition, I can zoomin/zoomout very quickly and hear the volume increase/decrease, but I realized as soon as the sound switches to "sustain", the volume will remain the same depending on the distance I was from the Orbiter in external view (F2) untill SRB Sep, even when the volume should decrease as we're leaving the atmosphere, it does not.

I believe this is how it is implemented in XRSound, if that's what you're using. You should bring that up in the official XRSound feedback thread: https://www.orbiter-forum.com/showthread.php?t=39240

---------- Post added at 02:15 PM ---------- Previous post was at 02:06 PM ----------

GLS: Is there any plans to save/load HUD settings like declutter level and brightness? Speaking of HUD decluttering, could an auto declutter feature be implemented to ease the high workload during the final approach?

 

[GLS]

GLS: Is there any plans to save/load HUD settings like declutter level and brightness? Speaking of HUD decluttering, could an auto declutter feature be implemented to ease the high workload during the final approach?

Aren't they being saved/loaded?

As for auto-"whatever" it's not an easy thing to do as it currently is done in a "man in the middle" way, i.e., generating the signal in the wire between the panel and the subsystem. The manual (key G), and auto, gear arm/down currently is a major hack already. The drag chute is smart and deploys on its own, which isn't exactly a good implementation if we want to do electrical failures. :facepalm:
A script, where one could define an action (click switch S6 of panel P3) and a trigger (MET > 50 && H < 300) would be nice... but would require time and work.

 

[DaveS]

Aren't they being saved/loaded?

Thanks, I missed this initially as none of the test scenarios had the relevant sections.

 

[Wolf]

When you say that you're "using the SoundBridge module", do you mean you're using it straight up on its own or in addition to XRSound? The last part is important. The SoundBridge module isn't a standalone module, it's a bridge module that is to be used to bridge the API calls specific to XRSound and the API calls that are specific to OrbiterSound. So, it should only be used with XRSound enabled, in fact that's why it should be allowed to overwrite the original OrbiterSound.dll file in Modules/Plugin.

In addition to XRSound.

 

[Urwumpe]

A script, where one could define an action (click switch S6 of panel P3) and a trigger (MET > 50 && H < 300) would be nice... but would require time and work.

That was one idea I had there - scripting the other crew members to relief the player. The main issue there is the boring effort. It isn't really a big challenge technically, though an effective memory structure might be smart.


The biggest challenge is preventing to iterate through all active triggers in every timestep.

 

[Wolf]

Speaking of HUD decluttering, could an auto declutter feature be implemented to ease the high workload during the final approach?

Please don't do that (unless the auto declutter function can be disabled by the user). IMHO it is good to have the chance to choose if and when to de-clutter the HUD; after all you should de-clutter only twice on final approach (first level when you have the RWY in sight and second one before preflare). Manual de-cluttering was also used in reality (you can hear that called by the PLT as they raech 4000' in the audio file we can play on final approach taken from one of the STS missions).
Also the chance to set your desired HUD britgtness is IMO a good feature to have.

---------- Post added 03-28-19 at 02:19 PM ---------- Previous post was 03-27-19 at 08:27 PM ----------

After the new aerosurfaces updates I noticed the following: SSU scenario saved after ET SEP and post SSME dump; when the scenario is launched from the saved state the orbiter shows the elevons in full up deflection and rudder in full right. Any idea why is this happening?

 

[GLS]

After the new aerosurfaces updates I noticed the following: SSU scenario saved after ET SEP and post SSME dump; when the scenario is launched from the saved state the orbiter shows the elevons in full up deflection and rudder in full right. Any idea why is this happening?

Can you post the scenario?