Luke Kolin

So if I am understanding you correctly (which is a big if, only on my second coffee), when I ask to read LVAR "foo", FSUIPC behind the scenes asks the simulator for the count of LVARs, then iterates through it until it finds the ID that matches "foo", then queries LVAR #{ID}. Each time? It never caches that mapping of names to IDs? (I mention only because that would match the behavior I see, and that iteration strikes me as rather slow and ripe for optimization). If so, if I read an LVAR that doesn't exist, I get a zero. If it subsequently gets created, then if there's no caching that's going on, I should be able to read it, but I cannot seem to for some reason. I just want to confirm what FSUIPC is doing, then I'll hack up your LUA scripts to filter down just the FSDT LVARs and see what's going on. (For some odd reason the script I have doesn't want to create an onscreen window in p3D v4.4). Cheers!

Thanks. Interestingly enough, the LVAR doesn't exist until I trigger the pushback. If I attempt to read an LVAR via an FSUIPC offset that doesn't exist, but is later created, is that nonexistence cached somewhere? Cheers!

Please see http://www.fsdreamteam.com/forum/index.php?topic=20579.0 Ordinarily I would say it's a GSX bug, but since Umberto has 100% confirmed that his software works correctly, it's obviously an FSUIPC bug where it reads every LVAR correctly except that specific one. Pete, since you appear to have GSX, would you be able to check whether that LVAR is being read correctly? I'm pretty confident FSUIPC can read and write LVARs correctly but I am not going to get anywhere with Umberto on my own. 😕 Cheers!

Yes, it's a separate process. The sim is crashing, and then it's triggering this error message in the ACARS software when it tries to reconnect. Cheers! Luke

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