Luke Kolin

Did this change? The offset status document for 5.15 says that bit 12 is playback, whereas for 5.154 it says bit 13. Cheers!

I've been trying to detect instant replay for my flight recorder in P3D v4 using the new offset 0x3402 that reads from the PDK. It appears that during instant replay, bit 11 does not appear to be set. Could someone validate that it's not just me? Cheers!

No worries, just wanted to let you know. Cheers!

The Installer appears to be contained in a ZIP file within a ZIP file, with the same name. Cheers!

The offsets look fine, now that I have the correct format. Thanks! Cheers! Luke

The numbers seem a little unusual, but it could be on my end. Can I assume that the lat/long are in the same format as 05B0 and 05B8? Cheers! Luke

Many thanks! I'll give this a test over the next few days. Cheers Luke

I am suspicious of the address. It looks like you inadvertently treating a variable storing a value as a pointer. Cheers! Luke

Deleted.

Thanks. What (I think) I'm looking for is the Lat/Long/Alt of the eyepoint itself, rather than relative to the reference frame. Cheers!

Sounds good! Thanks!

I believe I'm looking for the SimConnnect variable "EYEPOINT POSITION" - not sure if that is equivalent to what it was in FS9. Cheers! Luke

Just a friendly bump so that we don't lose visibility of this. Is there anything else I can do to help with this? Cheers!

Do you have the right encoding? These are 16-bit unicode characters IIRC. Cheers!

Just for read, please - I believe the offset was used for this purpose before, it's just not available post-FS9. IIRC the data is available via SimConnect. Cheers! Luke

An enhancement request - would it be possible to add offset 05B0 back into FSUIPC5? I believe there's a simconnect structure that allows one to read the position of the viewpoint, and it would be quite helpful to me. Cheers! Luke

I've noticed it as well. In a shell the > character tells it to redirect output. I think you may find a file called "4000" in that directory. Cheers!

Here's an updated script to log subsets of LVARs. It allows you to filter LVARs based on the presence of one of several substrings, does periodic rescans of new/removed LVARs and is written in a bit more of a modular fashion. Right now it's set to log GSX and TFDi 717 FCP LVARs as an example, but you can do whatever you want with it. Cheers! LogLVars.lua

I did some hacking around and it looks like the issue is slightly different - the window can be created but I'm not logging to it (even though I am to the log and they should occur together). I like the scripts because they give me a window into the LVARs being used and how their state changes, but I always need to hack up the raw versions since there are usually a lot of LVARs and I only care if a subset of them change (usually related to the aircraft/add-on I am reverse engineering). I'll see if I can modularlize the script a little and add some enhancements (filtering, rescanning of LVARs, etc) and then submit it back to you. I haven't learned a new language in a while. I suppose my brain needs some exercise. 😕 Appreciate your help! Cheers!

It was already enabled. What's odd is that when I fire off this LUA script and it's supposed to be logging, I can't ALT-TAB easily out of the sim, it's like something is stealing back focus (maybe the errant window suppression code?) What's also interesting is that I can see all of the GSX menus without issue - would those be suppressed as well? Cheers!

Sorry, what is the option name? I don't have MessageText in my INI. Cheers!

Pete - is your log_lvars supposed to log to the sim window? I recall it doing so but the latest version I downloaded today with the installer does not appear to do so. I know it's being triggered correctly since it writes to the FSUIPC log. Is this expected? Here's the script and the log file. Cheers! Luke FSUIPC5.log log_lvars.lua

Sorry... been busy a few days and I needed to pay closer attention here. For clarification (and this may confuse things...) I'm just using your LUA script as a debugging tool; I'm reading the LVARs via offsets and this is the use case I'm primarily concerned about. I think my next steps are to hack up spokes' LUA script to monitor the specific GSX LVAR, and then compare to what I'm doing via the offsets. Cheers!

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!