SSU Development Thread (2.0 to 3.0)

[Donamy]

Hmmm, lets's think for a minute. Always, a hatch on the front bulkhead of the orbiter. That should be added. STS-88 had 4 hatches, unless it was removed from the TAA, and covered. A second cover is needed for flights with no ODS. I think STS-107, only had 2 hatches.

 

[SiameseCat]

No and the SSRMS is already published on OHM as a separate add-on complete with its own documentation. So I think we should consider a completely separate add-on not really connected to SSU.

The SSRMS is basically a separate addon; the main reason it's in the SSU repo is because the SSRMS code uses some stuff from libUltra, in the SSU codebase. We shouldn't be including any SSRMS stuff in the SSU release.

 

[GLS]

The SSRMS is basically a separate addon; the main reason it's in the SSU repo is because the SSRMS code uses some stuff from libUltra, in the SSU codebase. We shouldn't be including any SSRMS stuff in the SSU release.

OK, I'll remove the SSRMS files from the release list then.

---------- Post added at 12:39 AM ---------- Previous post was at 12:33 AM ----------

Hmmm, lets's think for a minute. Always, a hatch on the front bulkhead of the orbiter. That should be added. STS-88 had 4 hatches, unless it was removed from the TAA, and covered. A second cover is needed for flights with no ODS. I think STS-107, only had 2 hatches.

So the TAA only has 2 hatches, the top and the aft one. And the ExAL only has 2 as well, the aft one and the ODS one. Add to this the bulkhead hatch and it fits well. Does it work this way?

---------- Post added at 12:43 AM ---------- Previous post was at 12:39 AM ----------

I added the following to the Credits section of the manual:

SLC-6 uses part of VandenbergAFB-2006 by Usonian.

Good or bad?

 

[Donamy]

The orbiter should have a hatch at the front bulkhead, always. The TAA has only one hatch at the "T" section, with a fabric cover. The Airlock, has 2 hatches and 2 covers if the ODS isn't used.

 

[GLS]

The orbiter should have a hatch at the front bulkhead, always. The TAA has only one hatch at the "T" section, with a fabric cover. The Airlock, has 2 hatches and 2 covers if the ODS isn't used.

So it all still works that way. Only the bulkhead hatch and both ExAL hatches might need covers. Could you put the covers in a separate group? Then we could hide/show the covers as needed. Would the same trick work on the TAA supports? They are only used when it is installed aft of the ExAL.

 

[Donamy]

The covers need to be animated also, seperate from the hatches. We could have 2 TAA, one with supports, one without.

 

[GLS]

The covers need to be animated also, seperate from the hatches. We could have 2 TAA, one with supports, one without.

For now I think the idea was just to have the TAA, so it is possible to do STS-88, 74 and such. If the covers are in a separate group, the animations can be added later without further mesh work.

 

[Donamy]

I thought we were talking about later.

 

[GLS]

I thought we were talking about later.

Can you make it in 2 or 3 days? If not, then it will wait.

 

[Donamy]

I already have the meshes, just need to tweek the textures.

 

[GLS]

I'm correcting the launch position of the payload bay cameras, and noticed the scenario entry is called "PLBD_CAM", and I think the D in there is a typo. "PLDB_CAM" or "PLB_CAM" would be fine. Can anybody "prove" this isn't a typo?

 

[Urwumpe]

I'm correcting the launch position of the payload bay cameras, and noticed the scenario entry is called "PLBD_CAM", and I think the D in there is a typo. "PLDB_CAM" or "PLB_CAM" would be fine. Can anybody "prove" this isn't a typo?

Don't we have multiple cameras in the PLB, labeled A to D?

 

[GLS]

Don't we have multiple cameras in the PLB, labeled A to D?

Yes, but the orientation of all those cameras is saved under the paremeter "PLBD_CAM". If it was to save the positions individually it would use names like "PLB_CAM_A", etc, and not "PLBA_CAM".

---------- Post added at 11:22 PM ---------- Previous post was at 03:07 PM ----------

I'm pleased to report that the problem with panel A8 seems to be gone. Probably somewhere in the last changes, something was made that "fixed" this. I'll know more when I go back and check the what/when/how (right now I'm "stuck" until the TAA changes are committed).

 

[Donamy]

Finished the TAA, ExtAirlock and ODS.

 

[Donamy]

Just found a "Gotch ya"!! The ring handrail needs to be added/removed, when using the ODS or not.

 

[Capt_hensley]

In the final TAA versions, Two IIRC
#1 two hard hatches, one soft
#2 4 hard hatches, 3 soft

All animated or removed?

Adjust fire over!

Maybe a nice illustration with a legend might help.

 

[GLS]

I have a proposal to "minimize the effects" of ticket #100 (Aft Keyboard out of position): I could manually shift aft (Z axis) the vertices of each key in there, thus fixing the sideways error in the panel. To fix the up/down error, one would have to change both the X and Y coordinates very carefully to keep the keyboard on the panel surface, and to do that manually would be very time consuming so I'll just leave that to the experts and their tools. :lol:
So, any concerns over this?

 

[Urwumpe]

I have a proposal to "minimize the effects" of ticket #100 (Aft Keyboard out of position): I could manually shift aft (Z axis) the vertices of each key in there, thus fixing the sideways error in the panel. To fix the up/down error, one would have to change both the X and Y coordinates very carefully to keep the keyboard on the panel surface, and to do that manually would be very time consuming so I'll just leave that to the experts and their tools. :lol:
So, any concerns over this?

Can't we just use better coordinates for the action area?

 

[GLS]

Can't we just use better coordinates for the action area?

That will have to be updated as well. But as the keyboard texture is "linked" to the keyboard meshes (one group per key), those groups have to be moved. Right now the keyboard is off both on its top/down position as well as its left/right position (the bigger error), this in relation to the panel. This fix would remove most/all of the current bigger error.

 

[Urwumpe]

That will have to be updated as well. But as the keyboard texture is "linked" to the keyboard meshes (one group per key), those groups have to be moved. Right now the keyboard is off both on its top/down position as well as its left/right position (the bigger error), this in relation to the panel. This fix would remove most/all of the current bigger error.

I would still prefer leaving mesh editing to the graphics department - they should know what they are doing.

How about an new release candidate today?