SSU Development Thread (2.0 to 3.0)

[Urwumpe]

I also noticed that all displays indicate that they are generated by GPC "0" ... we should fix this later.

---------- Post added at 10:14 PM ---------- Previous post was at 10:12 PM ----------

One more: We have many many Debug String messages getting displayed - before release, we should disable them, except maybe the launch countdown.

 

[GLS]

I also noticed that all displays indicate that they are generated by GPC "0" ... we should fix this later.

That's because there's only 1 GPC running at the moment :lol:
(yeah it should be 1-4, and 5 for the BFS displays)

---------- Post added at 09:18 PM ---------- Previous post was at 09:15 PM ----------

About the debug string, I have one with the AGT throttle bucket parameters that can be removed (that info is not displayed to the crew and it's already in the log). Other than that I don't remember having anything else.

 

[DaveS]

Could all the SSU specific log messages be moved out of the Orbiter log file and into a specific SSU log file?

 

[Urwumpe]

Could all the SSU specific log messages be moved out of the Orbiter log file and into a specific SSU log file?

Yes. But this would be a major refactoring, do you really want this shortly before release?


I have now tested all scenarios, discovered a few anomalies that I added to the thread, but everything seems to work fine in general with our current scenarios.

What we should improve: All our scenarios should get a standard naming scheme. We have some "STS-xxx launch" and some "STS-xxx L-10m" scenarios, these should better all get named the latter way.

 

[Donamy]

I'm sorry to keep bringing this up, but could the vertical tail be made such that this won't be hard to implement in the future? (from the mesh point of view)
Something like making the area around the base of the tail a separate part, and then we can choose which one to use.

Either that or 2 tails

 

[Urwumpe]

Either that or 2 tails

Rather three tails (Columbia, no-drag chute, with drag chute). But since we are also not doing a old electromechanic VC anytime soon, how terrible would it be having just one tail?

I added a meter longitudinal offset to the SSME exhaust, looks a bit better, though it still is no realistic exhaust... I hope nobody minds.

 

[DaveS]

Rather three tails (Columbia, no-drag chute, with drag chute). But since we are also not doing a old electromechanic VC anytime soon, how terrible would it be having just one tail?

The SILTS pod right now is a separate mesh altogether that can be toggled by the mission file entry SILTS=TRUE.

 

[Urwumpe]

The SILTS pod right now is a separate mesh altogether that can be toggled by the mission file entry SILTS=TRUE.

Yes, but it is simpler to have three vertical stabilizer meshes for one algorithm, then two independent algorithms for SILTS pod and vertical stabilizer mesh.

---------- Post added at 10:57 PM ---------- Previous post was at 10:51 PM ----------

Everybody OK with the SSME exhaust like that?

 

[DaveS]

Yes, but it is simpler to have three vertical stabilizer meshes for one algorithm, then two independent algorithms for SILTS pod and vertical stabilizer mesh.

---------- Post added at 10:57 PM ---------- Previous post was at 10:51 PM ----------

Everybody OK with the SSME exhaust like that?

Make about 2 m and it will be good.

 

[Donamy]

Another problem with the chute, is because of the difference, cutting the tail base apart, leaves a bad looking crease, if the parts aren't joined.

Texture looks fine to me.

 

[DaveS]

This photo shows the offset very well:

 

[Urwumpe]

I also found this image, which I translate to 1.9 to 2 meter offset during launch (SSME nozzle is 2.3 meter diameter)

http://www.nasa.gov/sites/default/files/images/677774main_jsc2011e067587-orig_full.jpg

 

[GLS]

Yeah, 2m would probably be right.

---------- Post added at 10:38 PM ---------- Previous post was at 10:26 PM ----------

About the standard scenario naming, I came up with this (it's a start):
filename: "<1> <2> <3>.scn"

<1>: mission name or orbiter/payload name
STS-111
Challenger with Landsat

<2>: mission part
Launch (& countdown?)
On-Orbit
Reentry
Landing

<3>: specific details about the mission part
T-00:00:45
200x250x51.6
MET 00-00:37:19
HST in low-hover position
EI-5
TAEM

 

[Urwumpe]

I think we would get some redundance since the mission number is also in the scenario file folder for us...

"Challenger with Landsat" would make sense for a folder with some quick example scenarios, that are not historically sorted. For the historic missions, there should be a description text (or HTML for the future) that contains orbiter and payloads.

For the historic missions:

"<2> <3>.scn" would be enough.

On-orbit, we should use "ORB#" for describing the maneuver situation in the flight plan or "FD#" for the flight day.

Before payload deployments or EVAs, we should have special scenarios ... maybe like "Before EVA-2"

But this would give us some strange scenario file ordering.... maybe we should always write the flightday in front of the scenario name:

"FD1 Launch L-2.5h"

 

[GLS]

The "Challenger with Landsat" is an example for missions that didn't have a number/name (Landsat, GPS, Mars Observer, etc).
The launch/countdown scenarios should have the T-hh:mm:ss format to be ordered.

 

[SiameseCat]

Yes, but it is simpler to have three vertical stabilizer meshes for one algorithm, then two independent algorithms for SILTS pod and vertical stabilizer mesh.

Columbia had the SILTS pod both before and after the drag chute was added, so we'll actually need 4 meshes; normal, without drag chute, normal with SILTS pod and SILTS pod without drag chute.

If this is possible, it might be simpler to have a single vertical stabilizer mesh and additional meshes for the SILTS pod and to cover up the drag chute. Alternatively, we can have 2 vertical stabilizer meshes, and then add a SILTS pod mesh when required.

 

[GLS]

Columbia had the SILTS pod both before and after the drag chute was added, so we'll actually need 4 meshes; normal, without drag chute, normal with SILTS pod and SILTS pod without drag chute.

If this is possible, it might be simpler to have a single vertical stabilizer mesh and additional meshes for the SILTS pod and to cover up the drag chute. Alternatively, we can have 2 vertical stabilizer meshes, and then add a SILTS pod mesh when required.

Looking at pictures, a "clip-on" drag chute "box" don't work. It would have to be 2 parts, one for drag chute, and another for the "original tail". If this 2 part system doesn't work with the mesh polys or whatever, I vote for the 2 tail system, and the SILTS pod is pretty much done.
And just to be clear, I brought this issue now because work is being done in the mesh, and I'm sure it's better to take care of this now than changing the mesh again in the future. I'm in no rush to implement this (fully) as there are more pressing things to be done.

 

[Urwumpe]

I am just printing the STS-135 mission flight plan right now... will use the weekend and the flight plan for making a preliminary mission editor.

 

[Donamy]

Anyone remember this one ?

 

[Urwumpe]

Anyone remember this one ?

Launchflames - YouTube

Yeah, but I also remember that there was a problem with them in SSU. There had been rendering problems...