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

[GLS]

Sooooooo, if we have a EVA, we have an animated airlock hatch?

... and astronauts! You could still get Story Musgrave in SSU. :lol:
That would be nice, but right now I'd really like to release SSU for Orbiter 2016. The IMO there are 3 show stoppers ATM: (1) the few abort runways we have are currently rolercoasters (I'm in a bulldozer fixing that :lol, (2) Crawler motion needs work (will look at it after (1)), and (3) AerojetDAP altitude reference in MM305, which we talked about late last year and I leave the DPS in your capable hands.
I'm not saying we can't tolerate a few detours (vc update, SSU Workbench), but it's been almost a year with Orbiter 2016... we should aim to release maybe in the summer.

 

[Urwumpe]

(3) AerojetDAP altitude reference in MM305, which we talked about late last year and I leave the DPS in your capable hands.

I can't really tell how far I can get there, in about 4 weeks, my 1.5th child will be born, so I can not be sure I will do any coding in June and July.

But you are right there, the next update should be in summer.

What about putting a EVA simulation on our list for the following year? We never did one despite the initial Atlantis and SF having it and the lack of a working Ummu for 2016 is another reason, maybe we can fill the gap there for others.

Technically, for (3) I just need to do the following subsystems:

MDM
RA
ADTA / ADP

Practically, It would be no issue to also add some more sensors, AFAIR the Radar Altimeter shares a card in the MDM with a TACAN.

 

[Donamy]

... and don't forget the attachment problems with the SRMS.

 

[Urwumpe]

... and don't forget the attachment problems with the SRMS.

Yeah, I think we did not yet file a ticket for the issue. We should not forget it, I hope its just a minor issue. :tiphat:

 

[GLS]

VAFB leveling is done!
For the runway I leveled a +/- large area around it, using an elevation closer to the higher side, and went close to the water so the cliffs don't look half bad.

---------- Post added at 05:24 PM ---------- Previous post was at 05:22 PM ----------

Technically, for (3) I just need to do the following subsystems:

MDM
RA
ADTA / ADP

Practically, It would be no issue to also add some more sensors, AFAIR the Radar Altimeter shares a card in the MDM with a TACAN.

I'd say our main problem is data flow into, inside, and out of the GPCs.

---------- Post added at 05:26 PM ---------- Previous post was at 05:24 PM ----------

... and don't forget the attachment problems with the SRMS.

Looking into it now. You found this bug in SSU 4.2?

 

[Urwumpe]

I'd say our main problem is data flow into, inside, and out of the GPCs.

Its not as big as it looks like. A bit of horrorshow and it will do fine.

 

[GLS]

I spent a few minutes moving the RMS on all 6 axes in both EE and PLB frames, and there's no misalignment. :shrug:
Only if I move the RMS with time acceleration do I get the EE away from the GF, but soon as I return to normal time acceleration and move it again, it lines up perfectly again.

 

[Urwumpe]

I spent a few minutes moving the RMS on all 6 axes in both EE and PLB frames, and there's no misalignment. :shrug:
Only if I move the RMS with time acceleration do I get the EE away from the GF, but soon as I return to normal time acceleration and move it again, it lines up perfectly again.

Is that a SSU or an Orbiter issue?

 

[GLS]

Is that a SSU or an Orbiter issue?

I'd say it's an Orbiter issue, as something similar occurs when raising the IUS or the Centaur out of the PLB, but it could also be floating point precision. :shrug:

 

[DaveS]

I'd say it's an Orbiter issue, as something similar occurs when raising the IUS or the Centaur out of the PLB, but it could also be floating point precision. :shrug:

I tested the RMS on default Atlantis with the Carina as the payload and experienced no jumping whatsoever during time acceleration. So I'd say it's an SSU issue.

 

[GLS]

I tested the RMS on default Atlantis with the Carina as the payload and experienced no jumping whatsoever during time acceleration. So I'd say it's an SSU issue.

Yeah, but your framerate is probably in the triple digits...

 

[DaveS]

Yeah, but your framerate is probably in the triple digits...

FPS is not it. I get the same FPS with SSU (G-Sync enabled to 120Hz) and still experience the jumping with the End Effector. That's both with the payload and the camera.

 

[GLS]

It also jumps in the default Atlantis for me... :shrug:

 

[DaveS]

I just can't reproduce it, even by using the D3D9Client Frame-rate limiter set as low as 30 fps.

 

[Donamy]

There's a hole in the nose ! Both sides.

 

[DaveS]

There's a hole in the nose ! Both sides.

That was an issue that was discovered post-release of 4.2. It has been corrected in the SVN mesh which I sent you a copy of a while back. I have been working on correcting a number of flaws that I discovered quite a while back. It's nearly done, it just need a bit more work.

 

[Donamy]

That is from the SSU update that GLS just sent me.

 

[Donamy]

I still get the RMS grapple error with the 2016 update's latch test scenario. Closing and starting current scenario fixes the misalignment.

 

[DaveS]

That is from the SSU update that GLS just sent me.

I found them in the source, addressing them now.

 

[GLS]

Could you test without any pluggins (except maybe the ones shipped with Orbiter)?