GPS String ID of Next Waypoint

[John Dowson]

All standard (user object/aircraft) data is requested via simconnect using the SIMCONNECT_DATA_REQUEST_FLAG_CHANGED and SIMCONNECT_DATA_REQUEST_FLAG_TAGGED flags, so we only receive the data value from simconnect when they have changed.
This is the case for all the data we request/receive.

 

[ark1320]

8 hours ago, John Dowson said:

All standard (user object/aircraft) data is requested via simconnect using the SIMCONNECT_DATA_REQUEST_FLAG_CHANGED and SIMCONNECT_DATA_REQUEST_FLAG_TAGGED flags, so we only receive the data value from simconnect when they have changed.
This is the case for all the data we request/receive.

 

I am not familiar with how SimConnect works, but the above data acquisition approach sounds like what RXP was referring to when he said:

"If they're not polling often, and they are relying on SimConnect telling them, there is no way in the current implementation because the RXP code is interposing between consumers and the simulator so that it is in fact "shadowing" the underlying value.

In other words, as long as you're asking the simulator for the variable value, it will always work. But if you're waiting for an event telling you it has changed, this will not be triggered because underneath the override, the FS code is still running its own internal update and value code".

So I guess this explains the "problem", and why the Lua script fails when the GTN 750 is active, which is unfortunate since the RXP GTN750 is a very "popular" P3D GPS unit.

Thanks,

Al

[John Dowson]

1 minute ago, ark1320 said:

So I guess this explains the "problem", and why the Lua script fails when the GTN 750 is active, which is unfortunate since the RXP GTN750 is a very "popular" P3D GPS unit.

Yes it does. But there is nothing we can do in FSUIPC to fix this. It needs to be fixed in the RXP GTN750. We are requesting this data in the standard way - they need to correct their software so that SimConnect recognises the value has change and provides the value when updated.

John

 

[ark1320]

5 minutes ago, John Dowson said:

Yes it does. But there is nothing we can do in FSUIPC to fix this. It needs to be fixed in the RXP GTN750. We are requesting this data in the standard way - they need to correct their software so that SimConnect recognises the value has change and provides the value when updated.

John

 

I understand.

Thanks,

Al

[ark1320]

2 hours ago, ark1320 said:

But there is nothing we can do in FSUIPC to fix this. It needs to be fixed in the RXP GTN750

Unfortunately, RXP also says there is nothing they can do because of the different versions of SimConnect they have to deal with, etc.    

Had a thought ( it happens! ). Would it be reasonably possible to create a FSUIPC 'function' similar to that which allows existing Lvars to be read, so existing Avars could also be read, e.g., ipc.readAvar("A:GPS WP NEXT ID") ? Then a Lua user could poll an Avar if necessary.  I have no idea what this would entail to implement, but it would be a powerful feature if reasonably doable. Most Avars are not directly writeable (their value is usually determined by K events) so a corresponding ipc.writeAvar() capability would not be as useful.

As I said, just a thought,  for sometime in the future perhaps.

Al

[ark1320]

Well, the good news is the RXP GTN750 generates a bunch of Lars, such as (L:rxp.hsi.dme_distance_nm) which is the distance to the next GPS waypoint, and (L:rxp.gps.nav_id) which holds the ID of the next GPS waypoint.

The bad news is the next GPS waypoint ID is stored (encoded) as a string of 8 ASCII characters in L:rxp.gps.nav_id. So, for example,  when I read this Lvar using ipc.readLvar() when it holds a 3 character waypoint ID like BRK ( which is a VOR ), since Lvars can only hold numeric values, the value I get back is 1.7451561201336e-310 !

So how to start with a value like 1.7451561201336e-310 and end up with the BRK ID is the challenge (to say the least).

Al

[John Dowson]

14 hours ago, ark1320 said:

Had a thought ( it happens! ). Would it be reasonably possible to create a FSUIPC 'function' similar to that which allows existing Lvars to be read, so existing Avars could also be read, e.g., ipc.readAvar("A:GPS WP NEXT ID") ? Then a Lua user could poll an Avar if necessary.  I have no idea what this would entail to implement, but it would be a powerful feature if reasonably doable. Most Avars are not directly writeable (their value is usually determined by K events) so a corresponding ipc.write.Avar() capability would not be as useful.

No, this is not easy to do. Lvars are accessed directly via a function provided by the Panels.dll. Simulator variables come via a request to simconnect (where you have to set-up a data definition, a request, a group and priority, and finally request the item) and the value is received in a callback message in a different thread. There is also the added complexities of the types - lvars are all double (64bit floating point numbers), whereas each simulator variable has a specific type.
This has also been requested before.

[Pete Dowson]

9 hours ago, ark1320 said:

So how to start with a value like 1.7451561201336e-310 and end up with the BRK ID is the challenge (to say the least).

You need it in hexadecimal. There must surely be a way of doing that just in Lua, but as a test I used User offsets. This Lua plug-in works 

x = 1.7451561201336e-310

ipc.writeDBL(0x66c0,x)

y = ipc.readSTR(0x66C0,8)
ipc.log(y)

The result is a 6 character string, space filled, but in this case it is "HGO", not the "BRK" you seem to have expected. Here's the part of the FSUIPC log where I also monitored offset 66C0 whilst running the above plug-in:

   231687 Monitor IPC:66C0 (U32) = 0x204F4748
   231687 Monitor IPC:66C4 (U32) = 0x2020
   440781 LUA.2: HGO   

I'd like to work out a way of doing this in pure Lua but I cannot think of where to start at present.

If a common use of L:Vars is to store string values it might be worth adding a special ipc.readLvarSTR function to the FSUIPC Lua library, but there are too many other things to do at present. 

Pete

 

[ark1320]

3 hours ago, Pete Dowson said:

The result is a 6 character string, space filled, but in this case it is "HGO", not the "BRK" you seem to have expected.

Yes, HGO is correct, a typo on my part.  Thanks very much for this solution.

3 hours ago, Pete Dowson said:

If a common use of L:Vars is to store string values it might be worth adding a special ipc.readLvarSTR function to the FSUIPC Lua library, but there are too many other things to do at present.

This sounds like a very good idea whenever time and workload permit.

Jean-Luc, the RXP GTN750 developer, suggested this:

You might want to persuade FUIPC developer giving you the option to read and write any var value as an array of bytes. This could be invaluable an option and this could help solving some other types of problems you couldn't solve otherwise regardless of RXP waypoint ID question.

The reason I'm exporting the string value into the bytes of a double is because there is no other way unfortunately. The SDK doesn't provide the means to reading custom string L:vars. The issue you're having is LUA because in C,C++ or even C# you could deal with the value as bytes.

Al

 

[ark1320]

5 hours ago, Pete Dowson said:

I'd like to work out a way of doing this in pure Lua but I cannot think of where to start at present.

Yes, that would be good. Two possible approaches I'm thinking about are to convert the Lvar value into an 8 byte Lua array if possible, or maybe use the string.format() function to convert the Lvar to hex characters.  I don't know if either of these ideas are workable at this point.

Al