ark1320

It all works now with you latest version of FSUIPC7. The Offset Status documentation is quite clear. I just had forgotten it was BCD ☹️ -- sorry. Another age problem I guess. Sigh. Thanks for the help. Al

John, The good news is I can now at least get the transponder in the steam gauge C172 to respond using your new FSUIPC7. The bad news is the value displayed in the transponder is wrong. I tried an experiment and get the following results when setting the C172 transponder using, for example. ipc.writeUW(0x0354, 0010) which displays 0002 in the C172. Code Written Code Displayed in the C172 0000 0000 0001 0001 0010 0002 0100 0064 1000 0360 So it seems the values being written are getting scrambled somehow. I don't see anything "common" in these results. However, values read back are apparently being interpreted as a Hex value. If I set the transponder with the mouse in the VC and then read the value with ipc.readUW(0x0354) I get: VC Transponder code Value read back and displayed 0000 0 0001 1 0010 16 0100 256 1000 4096 Al

That interesting. I just tried again with the the C172 (Steam gauge), and I can't write or read the transponder, even if I change the code in the sim. Al

John, I have tried the C152, C172(Steam gauge), and DA-40s(NG and TDI), all with nothing in my Community folder -- so all vanilla a/c. I can set the transponder mode in these a/c via offset 0x0B46, but can't set or read the 4 digit code with offset 0x0354. Thanks, Al

Hi John, Just tried offset 0x0354 again with FSUIPC v7.06, but still can't access the transponder in a default plane. Unfortunately it seems Asobo changed something wrt the transponder unless the problem is local to my system for some reason. Take care, Al

As best as I can recall, before the recent MSFS update on 9 March I could set transponder codes by writing to offset 0x0354, e.g., ipc.writeUW(0x0354, 1234). This offset no longer seems to work (can't read or write transponder codes) after the MSFS update. I would appreciate if someone could confirm (or not) they are seeing the same thing. Thanks, Al

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

Yes, HGO is correct, a typo on my part. Thanks very much for this solution. 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

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

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

I understand. Thanks, Al

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

Hi Pete and John, Below in blue is basically how I explained the situation to Jean-Lua, the RXP GTN750 developer, and below in green is his response. I don't know how to answer his question about how FSUIPC knows to update an offset value. He is trying to help and any info you can provide me to pass back to him will be appreciated. Thanks, Al Part of my statement to RXP: So SimConnect is the communication interface between the sim and FSUIPC. When FSUIPC reads a value via SimConnect it saves that value to a specific FSUIPC memory location, what FSUIPC calls an "Offset". My Lua script simply reads the value in that "FSUIPC" memory location. So in the case of the variable (A:GPS WP NEXT ID, string), FSUIPC gets the current value from SimConnect and stores it in "Offset" 0x60A4. The value in this location is suppose to be updated any time SimConnect sees the value of GPS WP NEXT ID change. But for some reason, it seems that once the GTN750 is turned on, SimConnect can no longer see the value of the variable GPS WP NEXT ID. Before the GTN750 is turned on, SimConnect does see the value of GPS WP NEXT ID and the Lua script which reads the associated FSUIPC offset works correctly. Response from RXP: Now I see what you mean with SimConnect. The question therefore is: how does FSUIPC gets notified the value changes? 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. Which begs the question how did they implement their code reading simvars using SimConnect and updating their internal table of values exposed via their "offsets" with regard to values changing automatically and especially this one. This also begs the question whether the level at which we're shadowing the simvar is low level enough into the FS code. I believe it is very low level indeed but it might be SimConnect is using its own alternate path to accessing the data and exporting it. One way to answer this would be you using SimConnect directly instead of FSUIPC in order to cross check whether this is working. I suspect it will but I might be wrong.

I have a XML gauge test window that I use when writing XML gauge code. It monitors the values of gauge Avars and Lvars. I've been told by a developer on FSDev that there is no difference between an Avar and a simulation variable with the identical name because the simulation variable is just the Avar that has been made available though SimConnect. But while the Avar (GPS WP NEXT ID in this case) is definitely being updated correctly, what's being communicated through SimConnect to FSUIPC is not. Why not is what I hope to find out from RXP. Al

But when I monitor (A:GPS WP NEXT ID, string) with an XML test window it always holds the correct value when the GTN 750 GPS changes the next waypoint. So for some reason FSUIPC is not getting accesses to this variable. I wonder if there is a simvar table that FSUIPC accesses that is suppose to hold copies of variables like (A:GPS WP NEXT ID, string) and it is this table that is not getting updated because of the GTN750 coding. Hopefully I'll get some details when RXP responds to my PM. Al

Hi Pete, I have not heard directly back from RXP (GTN 750 provider) yet. However, I was told on FSDev that making the GTN work requires 'hacking' into the P3D sim code, and that's why every time P3D is updated, the GTN code has to be updated as well. And in response to another issue on the RXP forum, the RXP developer said: "The RXP GTN is at least exporting all essential simvars necessary for direct interfacing if needed, although it also includes a technology to overriding the default simvars so that the GTN output data is transparently feed into the simvars other gauges are reading". While I don't understand all the implications of this, I have to wonder if the default simvar GPS WP NEXT ID is being overriden by the GTN but is not being "transparently fed" into the simvar that FSUIPC accesses? I'm still hoping to get a direct response to the PM I sent RXP. Al

I sent a message to RealityXP who provides the RXP GTN750. If I learn anything to shed light on the situation I'll report back here. Al

An Aircraft variable (Avar) is a P3D variable usually associated with a particular Key Event. For example, the Avar (A:GPS DRIVES NAV1, bool) is the XML variable that toggles in response to the Key Event (K:TOGGLE_GPS_DRIVES_NAV1), also known as FSUIPC control 66375. Thanks for all the feedback, Al

Al Where are you seeing that? "" is a null string, meaning it consists only of a zero. "" is just the way of writing it as a string in a programming language like Lua I thought "" represented an Empty string that I could test for from https://www.lua.org/manual/5.1/manual.html where it said: string.len (s) Receives a string and returns its length. The empty string "" has length 0. Even though I was not checking length, this suggested (to me at least) that you could check to see if a response string was empty by testing for "". Also, in the FSUIPC Lua Reference document for ipc.display() it says "To remove a display prematurely, send a null string (“”). So again I thought I could check for "". The code below does display NULL, so checking for a null or empty string by testing for "" does seem to work. Or maybe I misunderstand the point you are making. val = "" if val == "" then str_val = "NULL" else str_val = "NOT NULL" end ipc.writeSTR(0x3380, str_val) ipc.writeSW(0x32FA, 5) ipc.sleep (5000) Thanks, Al

Below is what I get when I monitor offset 0x60A4 with FSUIPC logging. HGO was the initial next waypoint ID based on the flight plan I initially loaded via the P3D4 flight planner. I also monitored the Avar (A:GPS WP NEXT ID, string) in my XML test window. When I first activated the GTN750, the Avar changed from HGO to GARMN. Using the GTN750 flight plan page, I first loaded HGO as the next waypoint (same as in the P3D4 flight planner) and then in succession changed the next waypoint to three different waypoints using just the GTN750. Each time I did this the Avar (A:GPS WP NEXT ID, string) changed to the correct next waypoint ID. However, I don't see any such changes in the FSUIPC6.log file below (which hopefully I set up correctly). So would a reasonable conclusion be Simconnect is not seeing the Avar change for some reason? Al 82797 Planned flight from KCOS to KDEN 82797 C:\Users\Al\Documents\Prepar3D v4 Files\VFR City Of Colorado Springs Mun to Denver Intl.pln 87156 Monitor IPC:60A4 (AsciiZ) = [3]"HGO" 87156 Monitor IPC:60A4 (U8) = 72 87156 SimRead: 60A4="GPS WP NEXT ID" STR8: "HGO" 95141 Monitor IPC:60A4 (AsciiZ) = [0]"" 95141 Monitor IPC:60A4 (U8) = 0 95141 SimRead: 60A4="GPS WP NEXT ID" STR8: "" 153781 ### Mode: PAUSE on

I looked at the Avar (A:GPS WP NEXT ID, string) with a test window for variables that I use when writing XML code. After loading a simple flight plan using the P3D flight planner, the Avar did hold the correct next waypoint ID, and the test Lua script worked. When I then turned on the GTN750, the waypoint ID in the Avar changed to "GARMN". If I then loaded the GTN750 with the same flight plan as I had set up using the sim's flight planner, the Avar once again held the correct next waypoint ID, but the Lua script accessing offset 0x60A4 failed as described in posts above. Apparently offset 0x60A4 was not updated with the next waypoint ID after "GARMN" was replaced with the correct waypoint in the Avar. With the aircraft sitting on the runway I then changed the next waypoint a few times using the GTN750 and the Avar changed correctly each time, but offset 0x60A4 did not get updated, at least not with a printable value as the test script repeatedly failed, and the log file for ipc.writeSTR() repeatedly showed strange characters as detailed above. So perhaps there is a simconnect update issue of some kind once the GTN750 is active? Thanks, Al

For test purposes I was just trying to check for ("") as a possible response and if found display "EMPTY". But from the log file info above, it doesn't seem the response is (""). Thanks, Al

Good idea! If I program in the else set to "UNKNOWN" , I do get UNKNOWN displayed. Without the else set to "UNKNOWN", the log shows this when using the statement next_waypt_info = ipc.readSTR(0x060A4, 10) 3557031 KEYDOWN: VK=88, Waiting=0, Repeat=N, Shifts=2 3557187 LUA: "C:\Users\Al\Documents\Prepar3D v5 Add-ons\FSUIPC6\Modules\TestScript.lua": killed 3557250 .. This key is programmed in FSUIPC6 'Keys' options 3557297 WRITElua 3380, 11 bytes: 00 00 00 00 00 00 00 00 47 48 00 ........GH. 3557359 WRITElua 32FA, 2 bytes: 05 00 If I change the readSTR() to allow for 40 characters instead of just 10 [ ipc.readSTR(0x060A4, 40) ] the log shows this: 3705375 WRITElua 3380, 41 bytes: 00 00 00 00 00 00 00 00 47 48 3D A2 E5 78 43 40 ........GH=..xC@ 3705375 74 E6 5F C3 8A 28 5A C0 53 F6 ED 08 66 34 A7 40 t._..(Z.S...f4.@ 3705375 00 00 00 00 00 00 00 00 00 ......... 3705437 WRITElua 32FA, 2 bytes: 05 00 .. I don't know what to make of all this, I will try talking to RealityXP to see if they have any ideas why the GTN750 is impacting the "GPS WP NEXT ID" sim variable, or maybe just FSUIPC6's access to the sim variable. Al ..

I've been doing some more testing in P3Dv5. It seems the problem described above is related to the use of a third party GTN750 -- the RealityXP unit in this case. If I load an aircraft, even an addon a/c, and enter a flight plan using the sim's flight plan planner without activating the GTN750, the 0x60A4 Offset (GPS WP NEXT ID) works as expected with my little test script below. But if I activate the plane's GTN750 after using the sim's flight planner, then the test script fails. What I don't understand is why when the script fails there is no response at all (not even the 'green bar" appears) since as you can see from the test script I check for nil, and "", and 0 responses. Thanks for the help, Al next_waypt_info = ipc.readSTR(0x60A4, 10) -- GPS ID next waypoint if next_waypt_info == nil then next_waypt_info = "NIL" elseif next_waypt_info == "" then next_waypt_info = "EMPTY" elseif next_waypt_info == 0 then next_waypt_info = "ZERO" end ipc.writeSTR(0x3380, next_waypt_info) ipc.writeSW(0x32FA, 5) ipc.sleep (5000)

To follow up a bit on the post above, if I run the test script below as shown, nothing is displayed at all, so it seems the ipc.readSTR(0x60A4, 10) at the second line is replacing the "ID Test_1" from the first line with an unprintable character of some kind. If I comment out the second line, ID Test_1 is displayed as expected. If in the orignal scirpt as shown I just uncomment the third line, ID Test_2 is displayed as expected, so the script does run with the second line active. If I replace the second line with next_waypt_info = ipc.readDBL(0x6048) --distance to next GPS waypoint the correct distance value to the next waypoint is displayed. So FSUIPC6 does "know" what the next waypoint is. The flight plan I 'm using for these test is simply KCOS to KDEN (about 65 NM), so KDEN is the "next waypoint". So it seems to me FSUIPC6 may have a bug that is preventing it from accessing the sim GPS next waypoint ID info for some reason, or maybe that info is not available in P3D ver4.5 or ver 5.1 (although GPS WP_NEXT ID is a listed sim variable), and so what ends up in offset 0x60A4 is an unprintable character of some kind. Maybe? Thanks for any ideas, Al EDIT: Offset 0x60A4, GPS String ID of next waypoint, does work in MSFS with FSUIPC7. So perhaps there is a bug in FSUIPC6 (or P3D)? next_waypt_info = "ID Test_1" next_waypt_info = ipc.readSTR(0x60A4, 10) -- GPS ID next waypoint -- next_waypt_info = "ID Test_2" if next_waypt_info == nil then next_waypt_info = "NIL" elseif next_waypt_info== "" then next_waypt_info = "EMPTY" end ipc.writeSTR(0x3380, next_waypt_info) ipc.writeSW(0x32FA, 5) ipc.sleep (5000)