CIGI Articulated Parts - P3D as IG

[mchriest]

Using P3D as IG, My Articulated Parts packets are being ignored. Packet mapped to entity 0, Articulated part enabled, correct deflection axis (pitch, for AILERON_LEFT_DEFLECTION, in this case) enabled. ArticulatedPartID = 2.

I note that the provided CigiArticulatedParts.xml provides definitions for "PropertyGet" only. I have tried adding PropertSet definitions to the file, with no result. I can imagine several possible reasons listed below. If anyone has some insight, I would appreciate guidance.

Possible Causes:
1. Setting surface deflections on P3D via CIGI is not supported.
2. Setting deflections is supported, but I need to correctly add the definition to the xml file (exact syntax, anyone?)
3. Setting deflections is supposed to be supported, but is failing due to a bug in P3D. This is my suspicion.

Recently, it was determined in another thread that CIGI objects are not rendered when the starting ViewID is set to 0. To get a model to render, the ViewID must be set to something other than the "Cigi View", and then manually set. This procedure did result in the object being rendered in the CIGI view, but I noticed that this operation also caused P3D to ignore my ViewCtrl offsets. I have a hunch that the manual view change is also breaking the ArticulatedParts offsets, but have no way of knowing for sure.

[mchriest]

Updated Observation:

I can apply an articulated part deflection to the first packet received by P3D, but all subsequent packets are ignored.
This is repeatable, and is not dependent on modifying the CigiArticulatedParts.xml.

e.g., using Mooney Bravo.
1. Configure my host to send some deflection to the left aileron, i.e. 20 degrees.
2. On P3D, select ..Network..Cigi..Start IG
3. I can see the 20 degree deflection.

But any further packets have no effect, unless I Stop IG, and Start IG, in which case only the first packet is applied.

[Clifton Crane]

Hi mchriest,

What are you using for your host? Are you using the CCL host emulator?

[mchriest]

Hi Clifton,
thanks for the reply. I"m using my own host, based on the Cigi Class Library "CigiMiniHost" example.
I am currently sending an Articulated Part packet every frame, modifying the left aileron setting.
entityID = 0
ArtPartID = 2 (left ail, from the cigi art. parts. xml)
ArtPartEn = 1
PitchEn = 1
Pitch = <some value that I'm manipulating every frame>
All other ArtPart packet settings are 0.

[Clifton Crane]

Hello,

Are you running your IG in synchronous or asynchronous mode? Does the IG update (i.e. render frames), or is it being blocked by the host? Are you sending IGCtrl packets along with your articulated part packets?

[mchriest]

Hi Clifton,
The simulation is in synchronous mode. Yes, the sim updates, and yes, I'm sending the IGCtrl packets. Nothing would work otherwise. If you have the time, please take a moment to review the other threads I have recently posted to:
(Cigi Crash when using P3D as IG, and Cigi Object Rendering)
as they will provide some background and answer most of these types of questions.

As a brief recap:
In the CigiObjectRendering thread, I was told by your colleague, Brady Butler, that the IG will not render the model if the cigi configuration''s ViewID is the same as the ViewID posted in the ViewDef packet. His suggestion was to change the configuration file to point to another viewID, and then manually change the view back in P3D after connecting.
This rather klugey work-around did result in the object being rendered, but as I mentioned, it broke the working (until that point) View Offsets in the ViewControl packet.

I strongly suspect that this work-around has also broken the IG's handling of the articulated parts on the ownship.
Is it possible for you to run P3D as an IG, shift your view outside of the cockpit (using the ViewControl offsets), and animate any of the surfaces using articulated parts packet(s)? If so, I would be proven wrong, be very grateful, and could continue with my work.

Thanks,

mike.

[Brady Butler]

Hello Mike,

We originally tested articulated part packets with a Prepar3D Host to a Prepar3D IG without the ViewID's being the same so that we could change our view manually. This is because when the ViewID's are the same the view control packet from the host overrides any manual camera selection on the IG. I can confirm that articulated parts work as expected from Prepar3D to Prepar3D regardless of the view control packets that are sent from the Host.

I have a suspicion that something may be being missed, or that there may be an edge case bug. I'm currently at home but I will look into this when I get back into the office tomorrow.

In the meantime, just to verify, are you sending the Pitch values as 0 to 360?

Regards,
Brady

[Brady Butler]

Hello Mike,

Now that I'm back in the office, I tested our articulated part packets with a Prepar3D Host to Prepar3D IG and they are working as expected. The ViewID's in CigiConfig were set to different values on the Host and IG for the reasons mentioned in the previous post(s).

Let us know if you have any updates.

Regards,
Brady

[mchriest]

Hi Brady,

thanks for testing, and thanks for the reply.
As long as I know that the features work when configured correctly, I'm happy to continue trying to figure out what the issue is on my end. I'll assume for now that when the articulated parts issue is resolved, I'll also resolve the camera offset issue.

Can I ask what view ID you are sending from the host? And do you change the host view id once you have manually changed the IG view?

[Brady Butler]

Hello Mike,

I usually just have one set as ViewID=0 and the other set as ViewID=1. As long as they're different so that I can choose which camera to view the aircraft from. The IG will only respect the ViewControl packets when the ViewID's are the same.

We currently don't draw the model when the ViewID's are the same because the camera can be inside the model with an exterior model type being shown/drawn to Prepar3D, which was very disorienting. There was also the idea that the IG would be used as an "out the window" view.

We have some ideas for a better solution than simply making the model invisible. We will be looking into some of the options in the future.

Regards,
Brady