Cannot read LVAR correctly

[Luke Kolin]

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!

[Pete Dowson]

2 hours ago, Luke Kolin said:

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.

According to the post you have made, the only L:Vars active are the GSX ones. There are no FSDT ones. It isn't that it isn't changing, it simply doesn't exist in any currently active gauges or DLLs.

FSUIPC merely gets the list using the functions provided by P3D/FSX. There's really no way it will miss any.  But in the first instance, rather than use the Lua plug-in, you should use the built-in FSUIPC control to list all LVars.

2 hours ago, Luke Kolin said:

Pete, since you appear to have GSX, would you be able to check whether that LVAR is being read correctly?

Currently, after moving to a new PC, GSX isn't working at all, with various problems starting with a complete failure of the Addon Manager to allow me to enter my serial number. I too am having exchanges with Umberto, but he is slow to respond so i don't know when i will see it fixed. 😞

Pete

 

[Luke Kolin]

21 hours ago, Pete Dowson said:

FSUIPC merely gets the list using the functions provided by P3D/FSX. There's really no way it will miss any.  But in the first instance, rather than use the Lua plug-in, you should use the built-in FSUIPC control to list all LVars.

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!

 

[Pete Dowson]

2 hours ago, Luke Kolin said:

If I attempt to read an LVAR via an FSUIPC offset that doesn't exist, but is later created, is that nonexistence cached somewhere?

No, it simply isn't in the list.  FSUIPC asks P3D for the count of L:Vars (say 'N'). It then iterates through those numbers, or "IDs", from 0 to N-1 to get the names. It cannot know about any which don't exist at that time, and cannot really cache any names you throw at it to record their "non-existence".

You'll see in the Lua library document that these functions are represented clearly by ipc.getLvarId (getting the numerical ID given a name). and ipc.getLvarName (the reverse, getting the name given the ID). Both will tell you if it exists or not.

I've got GSX working again now, so I could check here for you in the next few days, but it appears that isn't needed now?

Pete

 

 

[Luke Kolin]

15 hours ago, Pete Dowson said:

No, it simply isn't in the list.  FSUIPC asks P3D for the count of L:Vars (say 'N'). It then iterates through those numbers, or "IDs", from 0 to N-1 to get the names. It cannot know about any which don't exist at that time, and cannot really cache any names you throw at it to record their "non-existence".

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!

 

[Pete Dowson]

5 hours ago, Luke Kolin said:

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}.

No, it asks direectly. What I was describing was how this Listing (the FSUIPC control and the Lua plug-in provided) works. You call for a pecific LVar would simply return nil is it didn't exist.

5 hours ago, Luke Kolin said:

If so, if I read an LVAR that doesn't exist, I get a zero.

A zero? If i remember rightly (which I may not, getting too old) you should get "nil" which is the Lua "non-existent".

5 hours ago, Luke Kolin said:

For some odd reason the script I have doesn't want to create an onscreen window in p3D v4.4

Which script is that?

Pete

 

[Pete Dowson]

I saw your exchange with Umberto on the GSX forum, and added my own clarification. Basically this:

First, the assignable FSUIPC control to list L:Vars just lists those extant at that time. 

The Lua plug-in I think you are using ("log lvars.lua") only polls for the ones it knows about.  When it first runs it scans for L:Vars with IDs from 0 to 65535 building the array of names to keep watching. However, it stops doing that when it reaches the last valid ID in that scan. It does this for efficiency and with most add-ons this is quite sufficient.

In this case, though, you would want it to repeat the complete scan, or at least continue from where it failed to retrieve a name before. it shouldn't be too hard to make such modifications. You'd just need to take care to avoid bringing the sim to a crawl or, on the other hand, missing changes to LVars because of the continuous re-scanning.

We can discuss alternative changes if you are still interested, though if you need it for for own code then the simplest way would be to keep trying to read it by name till it appears and returns a valid numerical result.

Pete

 

[spokes2112]

A shameless plug 😞 ..
You could always use this little kit, nothing more than a mod of Pete's included lua examples.
Just monitor the L:Var you want - if it is not there the lua will die gracefully, otherwise if the var is there a window will show it's status. 
Basically all you need is the "LVAR_SPECIFIC" portion of the kit since you know the L:Var name..
Assign a key to start it repeatedly until you get a value.

Roman

[Luke Kolin]

14 hours ago, Pete Dowson said:

We can discuss alternative changes if you are still interested, though if you need it for for own code then the simplest way would be to keep trying to read it by name till it appears and returns a valid numerical result.

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!

[Luke Kolin]

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

[Pete Dowson]

1 hour ago, Luke Kolin said:

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.

It works fine here with FSUIPC 5.151. 

In P3D4 the SimConnect message windows are suppressed if you don't have "Message Text" option enabled in the P3D4 user settings. The idea then is for you to use an external utility for the display (possible on a WideFS client PC).

Check that option. Maybe you changed it?

Pete

 

[Luke Kolin]

2 hours ago, Pete Dowson said:

In P3D4 the SimConnect message windows are suppressed if you don't have "Message Text" option enabled in the P3D4 user settings.

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

Cheers!

[John Dowson]

Its not in the FSUIPC ini file, its a P3D option, under Information -> Miscellaneous Text.

[Luke Kolin]

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!

 

 

[Pete Dowson]

24 minutes ago, Luke Kolin said:

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?

To the last point -- no, the menus can't be suppressed.

Maybe the Message Window is off-screen or otherwise not visible? Check the FSUIPC INI file to see if the Window position is saved. If so delete the section for it and make sure that

RestoreSimcWindows=No

is set in the [General] section, not "Yes". Window positions are saved like this for example):

[Window.Message Window]
Undocked=599, 113, 1358, 76

[Window.SimConnect Message Window]
Undocked=1197, 258, 364, 88
NewDocked=1433, 76, 650, 160

[Window.SimConnectWindow]
Undocked=-693, 161, 596, 319

Also it might be saved in your saved Scenario file. Check that too.

As for ALT TAB not working, there's really no way possible for FSUIPC or the Lua program to affect that. It is rather suspicious behaviour.

Pete

 

[Luke Kolin]

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!

[Luke Kolin]

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

[Pete Dowson]

1 hour ago, Luke Kolin said:

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).

That's very odd. s I said, it works fine here. There are two other similar "logging" Lua plugins provided. Try them to see if they behave the same for you:

VAS_Monitor
display vals

Pete