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

[GLS]

Can anyone in the graphics department get me precise RMS joint (middle of the axis) and EE coordinates?

I seem to be having a problem with the payload latches unlatching. Anyone else ?

Did you try the PL BAY MECH PWR switches on panel R13L?

 

[DaveS]

Can anyone in the graphics department get me precise RMS joint (middle of the axis) and EE coordinates?

Here they are:

SY: -2.46699, -0.653461, 7.12342
SP: -2.63377, -0.174527, 7.12408
EP: -2.57585, -0.328731, 0.75787
WP: -2.63427, -0.173609, -6.29261
WY: -2.63394, -0.173748, -6.73341
EE: -2.63438, -0.174269, -7.99831

---------- Post added 12-21-16 at 12:47 AM ---------- Previous post was 12-20-16 at 10:18 PM ----------

"EDW 22 TAEM" scenario

Speaking of this scenario, could the HUD Brightness rotaries be made operational? The brightness switches do work but they're not strong enough to combat the brightness of the atmosphere, washing out the HUD data.

 

[GLS]

Speaking of this scenario, could the HUD Brightness rotaries be made operational? The brightness switches do work but they're not strong enough to combat the brightness of the atmosphere, washing out the HUD data.

I think I added that sometime ago... or was I dreaming? :uhh:

 

[DaveS]

I think I added that sometime ago... or was I dreaming? :uhh:

Well, for me the HUD Brightness rotaries does nothing, either on the CDR or PLT HUDs. The HUD Brightness switches increase/decrease the brightness as they should but the rotaries seem to be show only (IOW, they move but there's no actula functionality).

---------- Post added at 12:59 AM ---------- Previous post was at 12:55 AM ----------

Disregard: The HUD Brightness rotaries does work, I had the wrong understanding on how the it worked.

 

[GLS]

It has to be in MAN for it to be controllable. I divided the scale in 10% intervals and did the darker 50% in the MAN NIGHT, and the brighter 50% in the MAN DAY, and AUTO is set at 50 ou 55% as we can't simulate that.

 

[DaveS]

It has to be in MAN for it to be controllable. I divided the scale in 10% intervals and did the darker 50% in the MAN NIGHT, and the brighter 50% in the MAN DAY, and AUTO is set at 50 ou 55% as we can't simulate that.

Now that I have tested it a bit further, there seems to be a disconnect in the HUD brightness painting. It's nice and bright as long as it is above the cloud layer but as soon as you break through, the HUD dims considerably. I have included tow screenshots that show the difference.

Above the cloud layer:

Below the cloud layer:

---------- Post added at 01:29 AM ---------- Previous post was at 01:21 AM ----------

After some more investigation, the HUD brightness issue seems to be related to sun-light angle on the vehicle and is an issue only present in D3D9Client RC1. The inline client is fine.

 

[GLS]

OK, so the RMS is kinda of... uhh... wrong. It doesn't affect the EE attitude calculation, but the position calculation depends on it having the correct size and distance between the joints, or it simply won't match the official paperwork. If diagram 14.4-7 of the Shuttle Systems Handbook is to be believed, the joints are off by several centimeters, which explains why it is about 2in off the correct position when stowed.
I've corrected what I could: the final part of the RMS coordinate calculation, MPM axis - to - RMS axis distance and an EE camera orientation error, but I can't fix the mesh.

---------- Post added at 12:37 AM ---------- Previous post was at 12:31 AM ----------

After some more investigation, the HUD brightness issue seems to be related to sun-light angle on the vehicle and is an issue only present in D3D9Client RC1. The inline client is fine.

I was going to say that, as the panel brightness changes between the screenshots, and maybe that affects the glass as well.

 

[DaveS]

OK, so the RMS is kinda of... uhh... wrong. It doesn't affect the EE attitude calculation, but the position calculation depends on it having the correct size and distance between the joints, or it simply won't match the official paperwork. If diagram 14.4-7 of the Shuttle Systems Handbook is to be believed, the joints are off by several centimeters, which explains why it is about 2in off the correct position when stowed.
I've corrected what I could: the final part of the RMS coordinate calculation, MPM axis - to - RMS axis distance and an EE camera orientation error, but I can't fix the mesh.

Fixed in rev. 2589.

 

[GLS]

The RMS should now be solid in terms of what was implemented. The EE coordinates issue is now gone (there is still a sub-degree and sub-inch error, but IMO it's expected and tolerable), and I also fixed the orientation calculation for the elbow camera, and also a limitation in the wrist roll joint (when in IK) that caused false joint speed errors, so now following the checklist to grapple the OBSS should be easier.
One remark has to be made in regards to the attitude and position coordinates, and I'll probably add this to the manual as well: our calculations refer to the EE position, a.k.a "PL ID 0". For other PL IDs in the checklists our numbers are worthless, because AFAIK we can't change our point of reference/PL ID, but joint angles are always correct.

---------- Post added at 10:37 PM ---------- Previous post was at 04:18 PM ----------

I corrected the HUD so that it doesn't cut the bottom half and it doesn't draw "outside" the window. The graphics code needs to be tweaked and I'd like to try something before I do that, but probably it will have to wait until next week.

 

[asdad]

I have Problem with Body Flap when Touchdown can you Fix it ?

 

[Urwumpe]

I have Problem with Body Flap when Touchdown can you Fix it ?

What does "Problem" mean in detail?

 

[asdad]

when touchdown is like not stable if I put Body Flap in Auto

 

[Urwumpe]

when touchdown is like not stable if I put Body Flap in Auto

That does not help me much but I'll try to check what happens.

 

[asdad]

ok Thank you

 

[GLS]

In regards to the "Enable geometry instancing" setting we suggest to have off when using D3D9: that doesn't seem to exist now.... can this suggestion be removed from manual/readme?

 

[DaveS]

In regards to the "Enable geometry instancing" setting we suggest to have off when using D3D9: that doesn't seem to exist now.... can this suggestion be removed from manual/readme?

Yes. If it isn't around anymore, it should be removed from the manual.

 

[asdad]

The problem solve for body Flap after I uncheck Atmospheric Wind Effect sorry for my mistake

 

[asdad]

How About Prelaunch sound in SSU is never use Should I Remove It or not ?

 

[GLS]

How About Prelaunch sound in SSU is never use Should I Remove It or not ?

If you need the space you can delete that folder as yes it's not being used, but when updating the trunk it will be downloaded again... unless you update each of the other folders in the trunk manually, which IMO is not worth it for just 15MB.

 

[asdad]

ok thanks GLS