SSU Development Thread (3.0 to 4.0)

[DaveS]

I just committed panel A1U, but it I can't get the mouse events to be detected. Not sure if it is related to the panel A8 issue.

---------- Post added at 11:03 PM ---------- Previous post was at 08:57 PM ----------

It seems that the oapiVCSetAreaClickmode_Quadrilateral function doesn't work with non-rectangular areas, contrary its description:

So you think that could be the root problem?

 

[GLS]

So you think that could be the root problem?

Sure looks like it. I changed to a rectangular area and it worked, moved one corner so it was a trapezoid (or what ever it is called), keeping all points in the same plane, and it didn't work again.

 

[DaveS]

Sure looks like it. I changed to a rectangular area and it worked, moved one corner so it was a trapezoid (or what ever it is called), keeping all points in the same plane, and it didn't work again.

Great! So the solution will be to change all the quadrilateral click areas to rectangular ones?

 

[GLS]

Great! So the solution will be to change all the quadrilateral click areas to rectangular ones?

Just looked up the numbers on panel R2, and it's not a rectangle there, and it works for ages now....
I'll change the area on A1U, unless someone has a better idea.

 

[Urwumpe]

Just looked up the numbers on panel R2, and it's not a rectangle there, and it works for ages now....
I'll change the area on A1U, unless someone has a better idea.

Is the vertex order maybe wrong?

 

[GLS]

Is the vertex order maybe wrong?

I used a clockwise order starting from the top left corner.

 

[DaveS]

I used a clockwise order starting from the top left corner.

This is the what the OAPI Reference Document specifies for oapiVCSetAreaClickmode_Quadrilateral (page 147):

p1, top-left
p2, top-right
p3, bottom-left
p4, bottom-right

 

[GLS]

I'm getting tired of this panel. :compbash:
I setup 2 rectangular areas to cover the triangular panel and things started to work... until I noticed that clicking on one switch made others move. If 2 switches, each in a separate area, have similar coordinates, the events easily will go to the wrong place. So we need to go back to one area alone. And as we apparently can't use a non-rectangular shape, we will have a big chunk of click area on the other side of the wall... Any potential problems with this?

---------- Post added at 01:38 AM ---------- Previous post was at 12:54 AM ----------

Looks like it works now.

 

[Urwumpe]

I'm getting tired of this panel. :compbash:
I setup 2 rectangular areas to cover the triangular panel and things started to work... until I noticed that clicking on one switch made others move. If 2 switches, each in a separate area, have similar coordinates, the events easily will go to the wrong place.

Did you use the same area ID? :tiphat:

 

[GLS]

Did you use the same area ID? :tiphat:

No, used 2 different ones. The problem is that events from both areas would end up in the same panel, and without a way to "link" the components to a specific area, this wouldn't work. Unless using the same ID "merges" the coordinates of the areas....

 

[Urwumpe]

No, used 2 different ones. The problem is that events from both areas would end up in the same panel, and without a way to "link" the components to a specific area, this wouldn't work. Unless using the same ID "merges" the coordinates of the areas....

Maybe we just need "multi-area" panels. I believe, right now, we have the basic assumption: One panel = one area.

 

[GLS]

Maybe we just need "multi-area" panels. I believe, right now, we have the basic assumption: One panel = one area.

Yes, for the F6, F7 and F8 panels, as the MDUs are "raised" above the panel surface. When trying to click on a PLT MDU from the CDR position, it's noticeable the "click plane" is behind the MDU. We can deal with it when we break up the panels.

 

[Urwumpe]

Yes, for the F6, F7 and F8 panels, as the MDUs are "raised" above the panel surface. When trying to click on a PLT MDU from the CDR position, it's noticeable the "click plane" is behind the MDU. We can deal with it when we break up the panels.

Can you file a ticket for this (allow multiple VC areas per panel object) quickly and assign it to me? I'll look at the issue then after work. I think I can get it done in one or two evenings, make it the 3.1 milestone, if you want to, since its a minor feature change vaguely related to DPS.

 

[GLS]

Can you file a ticket for this (allow multiple VC areas per panel object) quickly and assign it to me? I'll look at the issue then after work. I think I can get it done in one or two evenings, make it the 3.1 milestone, if you want to, since its a minor feature change vaguely related to DPS.

Done.

 

[GLS]

When deploying the KU antenna, upon moving the DA out, do the alpha and beta gimbals always move to a certain angle, or it all stays still until a target is specified?

 

[Urwumpe]

When deploying the KU antenna, upon moving the DA out, do the alpha and beta gimbals always move to a certain angle, or it all stays still until a target is specified?

No, from what I can tell, it is moved to 0°/0° during activation of the Ku-Band antenna system, not during deployment - as soon as you power it on, the antenna will move - that is why the antenna is always powered down during deployment and stow.

When the power for the EA1 is turned on, it will remove the locking pins and search the master index pulse positions for each gimbal (116.5° for alpha, -23.25° for beta), after the MIPs are found, the antenna moves to 0°/0° - this all happens in EA1, without DPS involvement.

 

[DaveS]

No, from what I can tell, it is moved to 0°/0° during activation of the Ku-Band antenna system, not during deployment - as soon as you power it on, the antenna will move - that is why the antenna is always powered down during deployment and stow.

When the power for the EA1 is turned on, it will remove the locking pins and search the master index pulse positions for each gimbal (116.5° for alpha, -23.25° for beta), after the MIPs are found, the antenna moves to 0°/0° - this all happens in EA1, without DPS involvement.

This is all correct. For a proper stowage of the DA to occur the gimbals has to be manually slewed to -29.0 for EL and -125.0 for AZ. This will put the dish in the proper orientation that allows the starboard PLBD to be closed. CC 15-7 of the Orbit Ops FDF has the monitor overlay that used to check the Ku band DA for proper stowage.

 

[Donamy]

I fixed the ExtAL.msh, centering the hatch windows with the ODS target. Also got rid of the inside window, because it was grey.

Who wants it ?

 

[Urwumpe]

GLS, can you make "inhibiting the deployment of the Ku-Band antenna" a SpaceShuttleUltra.cfg configuration file option? In reality, it would be possible to deploy the Ku-Band antenna even with closed Payload Bay (or stowed OBSS) ... of course resulting in damage in various magnitudes, from just a bend antenna dish to LOCV.

 

[Capt_hensley]

GLS, can you make "inhibiting the deployment of the Ku-Band antenna" a SpaceShuttleUltra.cfg configuration file option? In reality, it would be possible to deploy the Ku-Band antenna even with closed Payload Bay (or stowed OBSS) ... of course resulting in damage in various magnitudes, from just a bend antenna dish to LOCV.

I thought the orbiter had a lockout just for that on the aft deck panels to prevent inadvertent deployment with the doors closed. Or am I confused with something else?