SSU Development Thread (2.0 to 3.0)

[Urwumpe]

The strut length if you mean the east/west length is 17.9491.

Is that the length from animation reference to the point it connects to the rail?

 

[DaveS]

Is that the length from animation reference to the point it connects to the rail?

No, it is of the mesh itself. Could you be more specific of what you mean by "animation reference"?

 

[Urwumpe]

No, it is of the mesh itself. Could you be more specific of what you mean by "animation reference"?

Animation reference is the connection between OWP and strut, where the strut rotates in our animation model.

const VECTOR3 FSS_OWP_STRUT_ROTATION_REF = _V(5.524, 0.0, 22);

 

[DaveS]

Animation reference is the connection between OWP and strut, where the strut rotates in our animation model.

const VECTOR3 FSS_OWP_STRUT_ROTATION_REF = _V(5.524, 0.0, 22);

Then in X axis in it is 1.7.

 

[Urwumpe]

Then in X axis in it is 1.7.

I need the distance in XZ plane between the two points.

 

[DaveS]

I need the distance in XZ plane between the two points.

Could you show on the graphic exactly the points?

 

[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.

 

[1hippienaut]

lookin keen yall
finally rebuilt my laptop
set for greater graphics loads
its alive

 

[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.