Luke Kolin

That's an error generated by VABase because it lost its connection to the sim - it's pretty much impossible for it to cause the crash since it's running in a separate process. Cheers! Luke

John already said how - turn on event logging and see what controls are sent when you toggle the button. Cheers!

I have already worked around it in my code base (I think), but I'd strongly recommend populating 0628 from 3402 - one of the less touted virtues of FSUIPC from a developer's standpoint is that it abstracts away a fair number of sim-specific details and allows a cleaner code base from our perspective. Clearly you shouldn't twist yourselves into knots to maintain that common interface, but wherever you can with reasonable effort, you probably should. Cheers! Luke

Thanks, John. Can you please revalidate 0628 in P3Dv4.4? It appears to remain zero even when in instant replay. I can switch to using 3402 in the worst case, but how will this offset operate in cases where the user has disabled PDK? Cheers! Luke

What software is reading from FSUIPC and powering the display? Cheers!

Why don't you round the number to the nearest .01 Mach? Cheers!

It looks like FSUIPC5 and FSUIPC4 (or more likely, the simulators) handle instant replay different. In P3Dv4, offset 0628 does not appear to be nonzero, offset 3365 is zero and I continue to get data even when I'm in instant replay mode - this of course is not good because I'm reading the replay rather than actual sim data. In P3Dv3, I do not see this behavior - offset 3365 is set to 1 when in instant replay mode, whereas 3365 is zero in P3Dv4. What is the expected behavior, and what should I use to properly detect Instant replay? It doesn't appear that offset 0628 is correct. FWIW, I tried with UsePDK=No and got the same results (at least I think, I didn't see anything in the log to say that PDK mode wasn't being used). In the log, I do see the messages where FSUIPC is detecting that the replay mode is on, but for whatever reason it's not being sent in offset 3365 or 0628. Cheers! Luke

Have you tried reading LVARs that GSXv2 uses to determine its status? Cheers!

It's QualityWings, not PMDG. I don't know if they have an SDK. Cheers!

Yes, it's my dyslexia. Using offset 0x6DD7 for the LVAR rather than 0x66D7. Thanks again. Luke

Thank you for reminding me that the other LVARs were being read in time. I think I've tracked down the problem but I'll need to double-check in the morning. Appreciate you being my second set of eyes (or neurons!) Cheers! Luke

FWIW, here's the log (I have a LUA script that IIRC you wrote that logs the LVAR values - note how quickly they change).... FSUIPC5.log

In the TFDi 717 and PMDG MD-11, pressing a panel button will toggle an autopilot state. An LVAR will be written to, then quickly (I suspect dependent on frame rate) cleared. Right now I'm polling on a frequent basis but there are certain button presses that are being missed because they are being cleared within 100ms or less. Pete, is there any way other than polling that one can detect that an LVAR has changed? What I'd love to have is a facility similar to vertical speed at touchdown that will capture a brief (even for a single frame) non-zero LVAR value and preserve it until another non-zero value comes along. Cheers! Luke

Looks like P3D 4.3 is out today! Cheers!

Then do what Pete suggested and rename the key file. Cheers! Luke

Blast from the past! :) Actually, I wasn't referring to scenery, I was talking about the FSUIPC installation. My point was that using the P3Dv4 add-on format means that you can just create a directory in the "My Documents\Prepar3D Add-Ons" directory for FSUIPC5, and modify absolutely no shared files whatsoever. You don't even need the installer to have elevated permissions. IMO this gets you back to the pre-FSX days of not touching shared components. Cheers! Luke

Are you running FSUIPC 5.124? Your situations sounds almost exactly like what people were experiencing with 5.123c. Cheers!

Thanks, Pete - and welcome back! Cheers!

Look here. Cheers!

To confirm (and to help Pete when he returns) 5.122 appears to work fine with P3D4.2. Cheers! Luke

That matches my experience, Wispy. I think the constant SimConnect reconnections is what is causing it. Cheers! Luke

There's 5.123c, but I am suspicious. Tried a reinstall with the same issue. I then tried setting SimConnectStallTime to 2 in the FSUIPC.INI, but the log still shows the stall condition every 1000ms. I wish I had kept a copy of 122 around. :( Cheers! Luke

The streak continues! Pete goes on vacation and a new P3D drops. Just got the v4.2 Academic client installed and FSUIPC 5.123c is not playing nice. Log attached - hopefully it's just a new SimConnect library that needs to be linked against. Cheers! FSUIPC5.log

I've seen this before, and can duplicate it right now. 5.123c with Prepar3D 4.1.7.22841. Cheers!

Certain payware aircraft (PMDG + LDS) allow one to read the transponder mode via their SDK. I would check the iFly documentation to see if it is the same. Cheers!