SSU Development Thread (2.0 to 3.0)

[GLS]

Well, then the person who filed the tickets should also do this - we have quite many tickets with the comment "should be fixed in rev xyz", but we have no confirmation by the ticket creator or a comment in the ticket about continued discrepancies.

Maybe we should assign finished tickets to the ticket creator again.

If not the creator, then a 3º person should check the changes done before closing the ticket.
Ticket 99: scenario and mission file data (play with payload offset) added.

 

[Urwumpe]

Did we already have a script for making a SSU-distribution? I remember we talked about it.

If yes, I could start providing "nightly-builds" every other or other-other day (we don't have that much activity to require true nightlies).

 

[DaveS]

Did we already have a script for making a SSU-distribution? I remember we talked about it.

If yes, I could start providing "nightly-builds" every other or other-other day (we don't have that much activity to require true nightlies).

How about every Sunday? Allows for bug reports as well as fixes.

 

[GLS]

Checked that and no extra vertices has been found. The problem stemmed from the brackets/equipment on the port side sill longeron of the PLB. Removed that side and made a mirror copy of the working starboard side and the problem is gone. Revision 2195.

The swirling textures are gone, but the issue in D3D9 is still there, and it now shows in MOGE as well.

---------- Post added at 01:18 PM ---------- Previous post was at 01:15 PM ----------

Did we already have a script for making a SSU-distribution? I remember we talked about it.

If yes, I could start providing "nightly-builds" every other or other-other day (we don't have that much activity to require true nightlies).

There's a script in trunk/Utils/SSU to assemble a zip file.

 

[Urwumpe]

How about every Sunday? Allows for bug reports as well as fixes.

Would be good enough after release, I just want to provide some higher pace for allowing faster and more up-to-date testing. Remember, we want to release on 10th August 2015, Sunday is already the ninth.

---------- Post added at 02:34 PM ---------- Previous post was at 02:33 PM ----------

There's a script in trunk/Utils/SSU to assemble a zip file.

Thank you, will test and use it then.

 

[DaveS]

The swirling textures are gone, but the issue in D3D9 is still there, and it now shows in MOGE as well.

Fixed in revision 2196.

 

[GLS]

IMO, we must determine ASAP if the "panel behind getting the mouse events" issue is a problem caused by SSU or if it is an Orbiter problem. This way, if it is a problem with Orbiter it might get fixed in the 2015 version. Otherwise we risk having this issue until maybe 2020, and we can say goodbye to having the rest of the overhead panels working.
I changed the order in which the panels got the VC register call, and instead of O6 being in from of C3, it was C3 in front of O6. But I can't find anything wrong anywhere. The way the oapiVCSetAreaClickmode is described, it seems to really be an Orbiter issue, as it doesn't take into account where the area is in relation to the camera position, but I don't think this is enough to "file a complaint".

 

[Urwumpe]

IMO, we must determine ASAP if the "panel behind getting the mouse events" issue is a problem caused by SSU or if it is an Orbiter problem. This way, if it is a problem with Orbiter it might get fixed in the 2015 version. Otherwise we risk having this issue until maybe 2020, and we can say goodbye to having the rest of the overhead panels working.

I agree. I fixed some many problems there by a proper initialization, but its possible that we need to refactor this for all panels to make sure that no panel is in a bad state ever.

O6 worked this weekend properly according to VC debug mode. (CTRL+3), we just lack to implement some switches and connect those to functionality.

 

[GLS]

I agree. I fixed some many problems there by a proper initialization, but its possible that we need to refactor this for all panels to make sure that no panel is in a bad state ever.

O6 worked this weekend properly according to VC debug mode. (CTRL+3), we just lack to implement some switches and connect those to functionality.

AFAIK, the panels all work well (except the A8 issue). The problem is when we lean right in the CDR position, O6 "covers" C2 and C3 with its click area. Looking up at O6 has no such problems, as the O6 registers its click areas after C2/C3. Reverse that order, and the problem only becomes looking up. I'm going to play with DG a bit more to see if I can reproduce this in there.

 

[Urwumpe]

AFAIK, the panels all work well (except the A8 issue). The problem is when we lean right in the CDR position, O6 "covers" C2 and C3 with its click area. Looking up at O6 has no such problems, as the O6 registers its click areas after C2/C3. Reverse that order, and the problem only becomes looking up. I'm going to play with DG a bit more to see if I can reproduce this in there.

Oh, that's a good thing to test. If true, then we should really have a Orbiter bug there, because the Z-order of the action areas is not used correctly.

But if that behavior is the case, we could also fix it... we could register the action areas in order of distance to the VC position.

 

[GLS]

Oh, that's a good thing to test. If true, then we should really have a Orbiter bug there, because the Z-order of the action areas is not used correctly.

But if that behavior is the case, we could also fix it... we could register the action areas in order of distance to the VC position.

Well, that was fast! It is an Orbiter bug. Just confirmed it with DG. I added a debug string to the mouse event function to show when I was clicking inside a click area, compiled, started the sim, looked back and started to click away. And soon enough the events started to appear (I even managed to start the engines this way). I'll write an official bug report on this.

 

[Urwumpe]

DaveS: Can it be that the ODS rod groups are named out of order? It seems like the 3R group is not next to the 3L group.

 

[DaveS]

DaveS: Can it be that the ODS rod groups are named out of order? It seems like the 3R group is not next to the 3L group.

Just checked, they're where they're supposed to be. Maybe a new meshres file is required?

 

[Urwumpe]

Just checked, they're where they're supposed to be. Maybe a new meshres file is required?

That is what I first thought, but making a new one results in an identical file.

The problem is: The animation parameters are simply mirrored, but the meshgroup rotates away from the ring.

 

[DaveS]

That is what I first thought, but making a new one results in an identical file.

The problem is: The animation parameters are simply mirrored, but the meshgroup rotates away from the ring.

Well, that sounds more like animation component issue than an issue that the wrong mesh group being animated. The mesh is set up correctly with the petal 3 rods/actuators being below the #3 petal.

 

[Urwumpe]

Well, look here:

I can understand if you expect a trivial animation component error.

But look here:

        const VECTOR3 ODS_ROD3L_REF = _V(-0.117, ODS_ROD_REF_Y, 0);
	const VECTOR3 ODS_ROD3L_DIR = _V(0, 0, -1);
	const VECTOR3 ODS_ROD3L_ACT_REF = _V(-0.315, ODS_ROD_ACT_REF_Y, 0);
	const VECTOR3 ODS_ROD3L_ACT_DIR = _V(0, 0, 1);

	const VECTOR3 ODS_ROD3R_REF = _V(0.117,ODS_ROD_REF_Y,0);
	const VECTOR3 ODS_ROD3R_DIR = _V(0, 0, 1);
	const VECTOR3 ODS_ROD3R_ACT_REF = _V(0.315, ODS_ROD_ACT_REF_Y, 0);
	const VECTOR3 ODS_ROD3R_ACT_DIR = _V(0, 0, -1);

..............

                       pRod3LAnim[0] = new MGROUP_ROTATE(midx_ods, grps_rod3l0, 1, 
				ODS_ROD3L_REF, ODS_ROD3L_DIR, ODS_ROD_ROTATION);

			pRod3LAnim[1] = new MGROUP_ROTATE(midx_ods, grps_rod3l1, 1, 
				ODS_ROD3L_ACT_REF, ODS_ROD3L_ACT_DIR, -ODS_ROD_ROTATION);

			
			pRod3RAnim[0] = new MGROUP_ROTATE(midx_ods, grps_rod3r0, 1, 
				ODS_ROD3R_REF, ODS_ROD3R_REF, ODS_ROD_ROTATION);

			pRod3RAnim[1] = new MGROUP_ROTATE(midx_ods, grps_rod3r1, 1, 
				ODS_ROD3R_ACT_REF, ODS_ROD3R_ACT_DIR, -ODS_ROD_ROTATION);

That's also why I am asking for proper coordinates: The original animation references did not work at all.

 

[DaveS]

Try these:

1L_DR_rod ref: -0.386292, 2.22673, -0.181387
1L_DR_rod dir: -0.287224, -0.824477, -0.487587
1R_DR_rod ref: -0.313801, 2.22669, -0.0558456
1R_DR_rod dir: 0.278716, -0.824529, 0.492411

2L_DR_rod ref: 0.386292, 2.22673, -0.181387
2L_DR_rod dir: 0.287224, -0.824477, -0.487587
2R_DR_rod ref: 0.313801, 2.22669, -0.0558456
2R_DR_rod dir: -0.278716, -0.824529, 0.492411

3L_DR_rod ref: 0.0724755, 2.22755, -0.746854
3L_DR_rod_dir: 0.565876 -0.824436 0.00943811
3R_DR_rod ref: -0.0724755, 2.22755, -0.746854
3R_DR_rod_dir: -0.565876 -0.824436 0.00943811

 

[Urwumpe]

Found a typo and the new coordinates also work out much better than the old ones.

Now only the rod drive units are off - they animate parallel, but shift to the outside.

 

[GLS]

On ticket 99: "Confirmed to be an Orbiter bug, waiting for bugfix in Orbiter to test the behavior again."
Is this confirmed as not our problem? The only bugs confirmed to be caused Orbiter are the mouse events showing at different panels and the initial camera position direction. The issue with panel A8 seems to be offsets changing with the c.g.. And it only happens on that panel (which has a separate mesh). But other than that I can't say what is at fault here.

 

[DaveS]

1L_D-ring_extendbase ref: -0.454016, 2.00183, -0.31743
1R_D-ring_extendbase ref: -0.229847, 2.00183, 0.0708301,

2L_D-ring_extendedbase ref: 0.242712, 2.0039, 0.0715625
2R_D-ring_extendedbase ref: 0.46688, 2.0039, -0.316662

3L_D-ring_extendbase ref: 0.22416, 2.00286, -0.733517
3R_D-ring_extendbase ref: -0.224176, 2.00286, -0.733546