SSU Development Thread (2.0 to 3.0)

[Urwumpe]

Could you show on the graphic exactly the points?

I actually have - I have reduced the parts already to the mechanic equivalents, not the actual shape of the parts.

There is a large vertical tube on the OWP strut, which is where it connects to the two rails. That defines the first point. The second point is where the strut rotates around the OWP.

That photo shows the connection between strut and OWP bracket pretty good.

And the attachment to the bug report shows the attachment between rail and OWP strut

 

[DaveS]

Then measured directly northward it is 2.3564. That is if you mean in the 0.0 anim state (fully retracted).

 

[Urwumpe]

Then measured directly northward it is 1.7. That is if you mean in the 0.0 anim state (fully retracted).

And what is it in east-west direction?

 

[DaveS]

And what is it in east-west direction?

E/W it is 16.6591.

 

[Urwumpe]

E/W it is 16.6591.

So 16.7456 in the horizontal plane.

Checked in an intermediate state - looks like the OWP animations are off a bit compared to the mesh in general, will look closer at that tomorrow.

 

[Urwumpe]

The -Y-OWP animation is fixed, now looking for the next ticket to fix... I think #92 is something for the rest of the evening.

Before I forget it: Didn't we want to implement the LC-39 camera positions one day? What happened to that?

---------- Post added at 09:22 PM ---------- Previous post was at 09:10 PM ----------

Looks like the behavior of the bug is much more strange:

Initially, when loading the scenario, the camera points also in the wrong direction (had enabled the planetarium mode and checked the visible constellations), and it resumes to the state before exiting Orbiter, when you rotate the external view around the orbiter with CTRL+arrow key.

 

[GLS]

The -Y-OWP animation is fixed, now looking for the next ticket to fix... I think #92 is something for the rest of the evening.

I'm also seeing the ticket 92 effects in the ius-1.0 branch as one of the test scenarios is starting with the camera not aiming at the orbiter.
One thing you could do is add lean positions and such for all VC positions, as some don't have all the "specs". For example the port workstation VC position doesn't always lean in the same directions.

 

[Urwumpe]

I'm also seeing the ticket 92 effects in the ius-1.0 branch as one of the test scenarios is starting with the camera not aiming at the orbiter.
One thing you could do is add lean positions and such for all VC positions, as some don't have all the "specs". For example the port workstation VC position doesn't always lean in the same directions.

The bug also happens to stations, where the lean motion range is defined. It just does not happen if the viewing direction is straight forward.

The bug seems to be a constant rotation away from the original direction.

 

[GLS]

The bug also happens to stations, where the lean motion range is defined. It just does not happen if the viewing direction is straight forward.

Even if it doesn't have anything to do with this, or any other problem, as you are in the trunk now please take the time to do it (it can wait until after this ticket is done of course).
About this problem, I'm noticing that if the initial VC position is looking sideways -> 90º offset outside, and if the initial VC position is looking aft -> (yes you guessed it) 180º offset outside. Orbiter bug?

 

[Urwumpe]

About this problem, I'm noticing that if the initial VC position is looking sideways -> 90º offset outside, and if the initial VC position is looking aft -> (yes you guessed it) 180º offset outside. Orbiter bug?

Did not get that simple relationship here. When looking aft the view did not change, I still looked into the same direction afterwards. Also, I suspect the change in viewing angle also depends on the viewing direction in celestial coordinates.

I suspect, it is something that we do for the L4 and R4 panels, if you pass through those, the bug happens.

EDIT: Now I had a 180° change when in the aft cockpit, after passing through the payload bay cameras.

---------- Post added at 10:17 PM ---------- Previous post was at 10:02 PM ----------

Short test sequence to check something (using aft pilot workstation and DX9 client):

Ext. view mode | Initial direction | New direction
target-relative|celestial north pole|celestial south pole
absolute direction|celestial north pole|celestial north pole
global frame|celestial north pole|40°N declination, between Vega and Theta Herculis
target-relative|0° DEC 0h RA| Near Procyon ~5°DEC 8.5h RA
global frame|0° DEC 0h RA| 0° DEC 12h RA

 

[DaveS]

Ticket#92 camera check (GO indicates orbiter visible, NO-GO indicates orbiter invisible):

CDR: GO
PLT: GO
R4: NO-GO
STBD W/S: GO
AFT PLT STN: NO-GO
RMS W/S: NO-GO
PORT W/S: GO
MS2 SEAT: GO
MS SEAT: GO
CDR L4: NO-GO
ODS C/L: NO-GO
PL A: GO
PL B: GO
PL C: GO
PL D: GO
RMS EE: GO
RMS ELBOW: GO
MIDDECK: GO
AIRLOCK: GO

 

[GLS]

Ticket#92 camera check (GO indicates orbiter visible, NO-GO indicates orbiter invisible):

CDR: GO
PLT: GO
R4: NO-GO
STBD W/S: GO
AFT PLT STN: NO-GO
RMS W/S: NO-GO
[B]PORT W/S: GO[/B]
MS2 SEAT: GO
MS SEAT: GO
CDR L4: NO-GO
ODS C/L: NO-GO
PL A: GO
PL B: GO
PL C: GO
PL D: GO
RMS EE: GO
RMS ELBOW: GO
MIDDECK: GO
AIRLOCK: GO

Are you still in the ius-1.0 branch? Could you try the "STS-26R ius deploy" scenario? Here the orbiter is not visible as it starts in the port workstation...

 

[DaveS]

Are you still in the ius-1.0 branch? Could you try the "STS-26R ius deploy" scenario? Here the orbiter is not visible as it starts in the port workstation...

Can confirm this. I thin what we have here is a very tricky Orbiter bug and not an SSU bug.

 

[Urwumpe]

Can confirm this. I thin what we have here is a very tricky Orbiter bug and not an SSU bug.

I agree - the bug manifests itself differently depending on the external view mode, which suggests it is not depending on our inputs. Possibly it is a DX9 client bug, that is what I use there.

I would suggest putting the ticket on hold for later and report the behaviour for further research - maybe we are not the only add-on with that behavior, we could also just make test with just a simple VC and an inverted camera.

 

[DaveS]

I agree - the bug manifests itself differently depending on the external view mode, which suggests it is not depending on our inputs. Possibly it is a DX9 client bug, that is what I use there.

No, it's an Orbiter bug as it is the same in the inline version.

 

[Urwumpe]

No, it's an Orbiter bug as it is the same in the inline version.

OK, thats good to know. So we just need a second test with another add-on and such a default view direction.

Quicktest with the Black Dart did not reproduce bug, because the VC position is not saved.

 

[GLS]

OK, thats good to know. So we just need a second test with another add-on and such a default view direction.

Quicktest with the Black Dart did not reproduce bug, because the VC position is not saved.

I think it was when the VC position save was introduced, that the MFD menu overwritting problem showed up. It might not be possible to implement this feature, or it might have to be done in a different way. It is worth checking (by going back to when it was introduced) if this is related to the other VC problems: the panel A8 not working when payloads are latched in the PLB, and the panel behind the current view getting the mouse events.

 

[DaveS]

I think it was when the VC position save was introduced, that the MFD menu overwritting problem showed up. It might not be possible to implement this feature

Well, it comes from the Crawler where it works just fine.

 

[GLS]

Well, it comes from the Crawler where it works just fine.

OK.
BTW: I tested earlier this month, and the crawler has the panel behind getting the mouse events problem as well. Tested that on DG and SH-A and couldn't replicate the issue.

 

[Urwumpe]

I also doubt it is causing the problems itself.

We have some lot of ugliness in the shuttle orbiter code, I would not be surprised if the problems actually come from calling a SSU function in a place, in which was never designed to be used.

---------- Post added at 11:33 PM ---------- Previous post was at 11:22 PM ----------

Is ticket #49 still an issue?