writing in offset 3110 for control 66505 (Axis_pan_tilt)

[pchauffo]

Hello Peter,

first of all, for my first intervention on this forum, a humble thank to you for all what you bring to the FS community through FSUIPC. One day, the FS community (and Microsoft firstly !) will have to recognize it and, at least, erect a statue (at Meigs ?) to honor you :wink:

About FSUIPC now, I'm supporting SurroundSight's efforts on the 3dvisor.com SDK forum to interface through the FSUIPC SDK these virtual reality goggles "natively" with FS and no more through the original crappy "Mouse Emulation".

This bright guy (Michael alias SurroundSight) has succeeded to write the required C# code (my C efforts were more limited) but he has discovered like me that we are still limited to use the offset hex 3110 for yaw and pitch (controls 66504 and 66503). As soon as we write values for "roll" (Axis_pan_tilt control 66505) we are in front of strange behaviors, like exchanging axis ! So, at the end, we are in fact unable to address correctly roll behavior despite being able to perfectly manage yaw-pitch axis (though this is already quite an achievement to use this device)

Have you any idea why we encounter this behavior when writing in hex3110 in one block the data set ( 66505 for the first 32bits integer, signed scaled axis value below 2^13 for the second 32bits integer ) ? Is it a FS limitation ?

Thank you for your support.

Philippe

LSGL

[Pete Dowson]

.

This bright guy (Michael alias SurroundSight) has succeeded to write the required C# code (my C efforts were more limited) but he has discovered like me that we are still limited to use the offset hex 3110 for yaw and pitch (controls 66504 and 66503).

I don't really know what those controls do -- is that the Virtual Cockpit panning normally associated with a point-of-view hat on a joystick device? If not I would have thought it was the latter you wanted.

As soon as we write values for "roll" (Axis_pan_tilt control 66505) we are in front of strange behaviors, like exchanging axis !

Not sure what you mean by "exchanging axis", but for all AXIS (and _SET) controls you need to make sure the paramter is written first (to 3114), or at least at the same time in an 8-byte FSUIPC_Write. FSUIPC actually triggers the control itself when it sees you write to 3110.

A "tilt" will presumably tilt left or right based on your current viewing axis. Is that correct? Are you expecting it to retain the aircraft's axis instead? If these are viewing controls, which I assume they are, aren't they naturally all relating to the viewer's axis?

So, at the end, we are in fact unable to address correctly roll behavior despite being able to perfectly manage yaw-pitch axis (though this is already quite an achievement to use this device)

How are you doing that? I wouldn't think that of the three available AXIS PAN controls one would be siginifcantly different from any other, unless you've just found a bug in FS?

Have you any idea why we encounter this behavior when writing in hex3110 in one block the data set ( 66505 for the first 32bits integer, signed scaled axis value below 2^13 for the second 32bits integer ) ? Is it a FS limitation ?

I am at a loss to understand the problem in the first place, sorry. Is it some interaction between the three axes that concerns you, or something which looks buggy just with the Tilt one?

Regards,

Pete

[pchauffo]

Hello Peter,

sorry, it seems I was not crystal clear ...

So I try again and answer your point one by one:

- Yes, control 66503, 66504 and 66505 are linked to pan around the virtual cockpit. They are pitch, yaw and roll axis along which you can move the view

- we write correctly offset 3110 to 3113 (4 bytes) with 66505 value, then write in offset 3114-3117 (4 bytes) the axis value i.e. 3000 and then execute FSUIPC_Process. For other axis (66503 and 66504), it works perfectly but not for 66505.

ANd when we write in 66505, nothing happens but the next time we write a pitch or yaw pan change in 66504 or 66503 controls the view rolls instead of pitching or yawing ! It was the reason why I speak about "axis exchange". At this point, the only solution is to re-center manually the view and to limit actions to the pitch and yaw pan axis ....

- so yes, it seems that we discover a different behavior between the different pan axis control, in fact roll axis seems not to work correctly.

- my concern is only a simple question. Could this apparent buggy behavior be related to FSUIPC or is it a Microsoft "feature" ? If it is the second option, I can only cry in the desert and pray for FS X ...

THank you for your precious support.

Philippe

LSGL

[Pete Dowson]

- we write correctly offset 3110 to 3113 (4 bytes) with 66505 value, then write in offset 3114-3117 (4 bytes) the axis value i.e. 3000 and then execute FSUIPC_Process.

That's not right. FSUIPC will process the 3110 write BEFORE it processes the 3114 write. You must either write them in the same FSUIPC_Write (i.e. make a structure of 2 x DWORDs and send 8 bytes) or do the FSUIPC_Write for 3114 before the FSUIPC_Read for 3110.

For other axis (66503 and 66504), it works perfectly but not for 66505. ANd when we write in 66505, nothing happens but the next time we write a pitch or yaw pan change in 66504 or 66503 controls the view rolls instead of pitching or yawing !

That's weird. I will have to try it here when I get time. If it is an FS bug I'm afraid I cannot really do anything for you -- all FSUIPC does here is send your control and parameter to FS. you could actually do exactly the same by posting a WM_COMMAND message to FS's Window with the command as wParam and the parameter as lParam.

However, please revise your code to fix the order first, just in case it is that which is messing things up.

my concern is only a simple question. Could this apparent buggy behavior be related to FSUIPC or is it a Microsoft "feature" ? If it is the second option, I can only cry in the desert and pray for FS X ...

Well, as I say, FSUIPC is transparent here. Try fixing the order first, before crying.

Regards,

Pete

[pchauffo]

Hello Peter,

of course, your fix proposal was the right one.

To write the pan axis value before writing the Axis reference number is the correct way to proceed :oops: and solves my issue.

So no FS bug (I prefer that ! :D )

Problem solved. Now I can go back over the desert but not to cry, to do rolls in my virtual Spitfire ...

Thank you for the perfect support.

Have a nice week-end.

Philippe