Reading LVARs

[Luke Kolin]

I am reading LVARs using FSUIPC (6 and 7). John, do you know the expected behavior if we attempt to read an uninitialized LVAR? We have been getting some random results and curious if there is an expectation of a zero value or just random memory contents.

Cheers

 

[John Dowson]

17 hours ago, Luke Kolin said:

do you know the expected behavior if we attempt to read an uninitialized LVAR?

Not without checking...I can do this later, but I am pretty sure that the behavior would be different in FSUIPC6 and FSUIPC7 as the way lvars are accessed is different,

I suspect there is no specific handling for uninitialized lvars. Off hand, I think that in FSUIPC7, a default value of 0 is used, but in FSUIPC6 and earlier it will be whatever the gauge function returns, but I will check later and get back to you.

John

[Luke Kolin]

Thanks, appreciate it!

Cheers

[John Dowson]

All lvar values are stored as doubles (within FSUIPC), so its not possible to set a nil/null/uninitialized value. In FSUIPC7, a default value of 0.0 is used when the lvar/value is first created, but I think you can't read the value until the initial value is received, so that will be whatever is returned from the get_named_variable_value function of the Gauges API. Similarly, in FSUIPC6 and earlier it will be whatever the get_named_variable_value function of the Gauges API returns, but a value of 2.2250738585072014e-308 (DBL_MIN) may be returned if the lvar doesn't exist.

20 hours ago, Luke Kolin said:

We have been getting some random results and curious if there is an expectation of a zero value or just random memory contents.

If its random then I guess that is just what the get_named_variable_value function returns for uninitialized lvars.

But I don't think that lvars can be uninitialized... As far as the MSFS documentation goes, it says they are set to 0 when created, so I would expect all lvars to be initially 0, and not random. And I would expect the same in P3D.

Cheers,

John

[Luke Kolin]

3 hours ago, John Dowson said:

But I don't think that lvars can be uninitialized... As far as the MSFS documentation goes, it says they are set to 0 when created, so I would expect all lvars to be initially 0, and not random. And I would expect the same in P3D.

This is helpful context. If an LVAR has not been created when I request to read it, then get_named_variable_value would return an undefined result? I think this matches what I'm seeing. I guess there's no way for FSUIPC to check if it has been initialized prior to the read?

Cheers

[John Dowson]

18 hours ago, Luke Kolin said:

This is helpful context. If an LVAR has not been created when I request to read it, then get_named_variable_value would return an undefined result?

No. As I said, the MSFS documentation for get_named_variable_value returns 0 when the variable doesn't exist (see https://docs.flightsimulator.com/html/Programming_Tools/WASM/Gauge_API/get_named_variable_value.htm). However, you are not using this function directly, are you ?

If you are reading the lvars via lua, the ipc.readLvar documentation (for both FSUIPC7 and FSUIPC6) states: 

Quote

The value returned from readLvar is numeric, or nil if the variable is not available, and from readLvarSTR will be a string or nil.

Is that not the case?

Otherwise, how are you reading lvars? There are various ways that lvars are read, and what you get when the lvar doesn't exist may depend on the interface you are using.

Sorry, but I don't understand why all these questions on something so basic. If things are not working according to the documentation, please provide an example and I will look into it. Otherwise, follow the documentation.

John

[Luke Kolin]

1 hour ago, John Dowson said:

If you are reading the lvars via lua, the ipc.readLvar documentation (for both FSUIPC7 and FSUIPC6) states:  Is that not the case? Otherwise, how are you reading lvars?

Sorry I wasn't more clear. I am not using Lua, I'm using offsets 0x0D6C and 0x0D70.

To give the sequence of operations, I read the LVARs FSDT_GSX_BOARDING_STATE and FSDT_GSX_STATE to detect whether FSDT's GSX package is installed and operational. When called, I get the value of 1 back for the former, and 3 for the latter. I then ready FSDT_GSX_NUMPASSENGERS to see if a passenger count has been set by GSX. It also returns 3 What's interesting is that when I then fire up a LUA macro that selectively dumps LVARs to the SimConnect message window, FSDT_GSX_NUMPASSENGERS does not exist. It is curious and suspicious to me that the value returns is the same from the last LVAR successfully read.

I'll try and make a test case where I manually set an LVAR, read it, then read an LVAR I know does not exist via the 0xD6C/0xD70 method.

Cheers

 

[John Dowson]

2 hours ago, Luke Kolin said:

Sorry I wasn't more clear. I am not using Lua, I'm using offsets 0x0D6C and 0x0D70.

Ah, ok. Would have been helpful to say that at the start...

I would have to check the code for that offset to see that happens if the lvar doesn't exist, but I would think that this is not handled. it just calls the next level function (whatever that is) to get the lvar value and lets that handle the case where it doesn't exist and then just writes the value returned to the offset. I can check the code if needed, but better to just test and see what you get.

2 hours ago, Luke Kolin said:

I'll try and make a test case where I manually set an LVAR, read it, then read an LVAR I know does not exist via the 0xD6C/0xD70 method.

Ok. But why are you using offsets to read lvar values? If doing this in code, maybe better to use the WAPI API directly (or one of its wrappers) rather than the old FSUIPC SDK. But that is for MSFS only,  so I guess if you want compatibility for both FSUIPC6 and FSUIPC7 then you would have to use offsets.

John

[Luke Kolin]

On 6/13/2024 at 2:09 PM, John Dowson said:

I would have to check the code for that offset to see that happens if the lvar doesn't exist, but I would think that this is not handled. it just calls the next level function (whatever that is) to get the lvar value and lets that handle the case where it doesn't exist and then just writes the value returned to the offset. I can check the code if needed, but better to just test and see what you get.

This seems to match I've discovered... if the LVAR does not exist then the previous value that was in the offset is retained. I can work around this by clearing the offset block in advance (I'm only reading from 24 to 48 bits at a time, so a since 64-bit long write can clear them out in one operation).

In a perfect world, I'd prefer them to be set to zero, but I can also see advantages to this behavior as well (I can write a default value to the offset prior to the read). At the very least, it may be helpful to annotate the programmers guide to note this behavior in the case of an uninitialized LVAR.

On 6/13/2024 at 2:09 PM, John Dowson said:

Ok. But why are you using offsets to read lvar values? If doing this in code, maybe better to use the WAPI API directly (or one of its wrappers) rather than the old FSUIPC SDK. But that is for MSFS only,  so I guess if you want compatibility for both FSUIPC6 and FSUIPC7 then you would have to use offsets.

I need to maintain compatibility back to FSUIPC4 🙂 so this is my preferred way to go. (Technically even farther, but I can no longer validate the FS2002/FSUIPC2 path and the FS9 path doesn't have GSX support). It's a testament to the great work that you and your father have done - I've been working on this application since the FS9 days and it's usually just a day or two of work to support a new simulator. It's a a great abstraction layer.

Cheers

[John Dowson]

18 hours ago, Luke Kolin said:

if the LVAR does not exist then the previous value that was in the offset is retained.

Yes - in the offset functionality for lvars, if the lvar doesn't exist, then nothing will be written for read requests and write requests won't be processed either.

19 hours ago, Luke Kolin said:

In a perfect world, I'd prefer them to be set to zero, but I can also see advantages to this behavior as well (I can write a default value to the offset prior to the read). At the very least, it may be helpful to annotate the programmers guide to note this behavior in the case of an uninitialized LVAR.

The result offset is not set to zero as the lvar doesn't have a zero value, and, as I have said, I do not think that lvars can be uninitialized, at least those not created via the Gauge API. I can update the documentation to state the behavior when the lvar doesn't exist.

19 hours ago, Luke Kolin said:

I need to maintain compatibility back to FSUIPC4 🙂 so this is my preferred way to go. (Technically even farther, but I can no longer validate the FS2002/FSUIPC2 path and the FS9 path doesn't have GSX support). It's a testament to the great work that you and your father have done - I've been working on this application since the FS9 days and it's usually just a day or two of work to support a new simulator. It's a a great abstraction layer.

Understood, and thanks for the kind words.

John

[John Dowson]

On 6/17/2024 at 11:12 AM, John Dowson said:

I can update the documentation to state the behavior when the lvar doesn't exist.

The documentation did say that 0.0 would be written if the lvar doesn't exist. This is incorrect, and I have updated this now (for the next release).

John