ark1320

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)

Could someone please confirm that Offset 60A4, GPS String ID of next waypoint, works in P3Dv4.5 or P3Dv5.1. I can get Offset 6048 (or 60EC), GPS Distance to next waypoint, and Offset 6081, String ID of previous waypoint, to work But not Offset 60A4. I get no response at all as if the code won't run, even if I test for a nil response. The simple test code I'm using (that does work with offset 6081) is: next_waypt = ipc.readSTR(0x60A4,10) if next_waypt == nil then next_waypt = "NIL" end ipc.writeSTR(0x3380, next_waypt); ipc.writeSW(0x32FA, 3); ipc.sleep(3000) The next waypoint for this test is just a VOR, or an airport ICAO code, so the actual waypoint String ID is 4 characters max. Thanks for any ideas, Al FSUIPC ver 6.0.12

Andreas -- In my view, FSUIPC tries to provide access to as many existing sim events and variables as possible. Note there is no TOD variable provided by the sim. However, third party add-on programs, such as SimCars (or Lua scripts) can calculate a TOD point based on sim variable information it gets via FSUIPC , and also likely from additional information (flight plan, WX, etc) that the user enters directly into the third party program. So FSUIPC is a utility, a tool, to facilitate such calculations and the subsequent TOD pause. My $0.02 . Al

I'm not familiar with SmartCars, but I can see that if SmartCars knows the flight plan and tracks the flight progress it could calculate a TOD point, and then use FSUIPC to pause the sim when that point is reached. It's calculating the TOD point that I don't think FSUIPC does. Al

Well, interesting. I think the earliest version of FSUIPC I've used is FSUIPC4. I just don't recall a FSUIPC "TOD feature", and when I search the current Offset Status documentation for FSUIPC6 I don't find any reference to TOD. There certainly is the ability to Pause the sim, or to detect that the sim is Paused (Offsets 0x0262 and 0x0264), but these offsets are not tied to the TOD. There are also events (controls) for Pause Off, Pause On, Pause Toggle, and Pause Set (not sure what this does -- maybe pauses or unpauses the sim based on the state (0 or 1) of a variable). Again, I don't see these events as necessarily tied to TOD. I expect John or Pete will comment at some point to make things clear. Al

John will have to answer that, but I don't think any previous version of FSUIPC had that feature. Seems to me FSUIPC would have to know or have access to some details of your flight plan (e.g., the desired BOD waypoint and desired BOD altitude). Al

That could be. At the moment FSUIPC7 cannot access MSFS Lvars or Hvars, but John Dowson has said he is looking into how FSUIPC7 might be able to do so some time in the future. Al

So using the above we can estimate the time to TOD as Time to TOD(hr) = [Current Total Dist to BOD point - Descent Dist]/ Ave Ground Speed =[Current total Dist to BOD point - 3 x Descent Alt Change]/Ave Ground Speed Al

BTW, a good estimate for the distance required for a 3 deg descent is Descent Dist(NM) = 3 x altitude change in 1000s of feet. So, for example, if you will need to lose 25,000 ft from the TOD to the BOD, we get Descent Dist = 3 x 25 = 75NM And the rate of descent that will be required is Descent rate(ft/min) = 5 x Ground Speed(NM/hr) This is a 'ballpark' estimate as well since chances are you ground speed will not be constant throughout the descent. Al

Just to clear, the pause Lua script has nothing to do with smartcars or any VA. If you can estimate the time until TOD, then you can manually set the sim to pause accordingly. But the script is time based; I'm not aware of anything inherent in FSUIPC that will calculate the TOD point in NM for you and then pause the sim based on that distance from a BOD waypoint. Al

You might find this Lua script useful. It lets you pick a future time to pause MSFS. https://forum.simflight.com/topic/91605-set-future-pause-for-msfs-or-p3d/ Al

The offset status spreadsheet that's included with the latest version 7.0.4 of FSUIPC7 shows offset 0E8E in red, Not Working. Al

The screen shot I added above shows how it looks on both a 24" and 32" screen with the "We are" replaced by two spaces to center things a bit. Al

Problem showed up on both 24" and 32" screens. It got my attention because I think it all fit OK at one point, so I wondered what had changed on my system. In any case, replacing the "We are" with two spaces in the bat file text line centers things so all fits fine -- at least for now! 🙂 Al

I noticed today the word cabin is cut off in the FSUIPC7 opening screen as shown below . While this is certainly not important in itself, it makes me wonder if I have a wrong setting somewhere that will cause a problem elsewhere. So I would like to know if anyone else sees this. I am using FSUIPC version 7.0.4. If this issue is unique to my setup I should probably try to figure out what changed. Thanks, Al

John recently said FSUIPC7 does not currently have the ability to read and write MSFS Lvars, but may be able to do so some time in the future. Al

SetPauseP3Dv4&5.lua can be used to pause P3Dv4.5 or P3Dv5.1 from 1 minute to days after the script is run. Put the script in the same folder as FSUIPC6.ini and assign a key or button to activate it in the usual way. When the script is first run you will see where here an example pause time of 135 minutes has been entered, and as a result you would see As the script runs the time will be counted down in minutes and displayed so after two minutes with the above example you would see Finally, just before the sim pauses you will see To cancel a pending (future) pause, just rerun the script and select the cancel option (*). You will see a brief cancel message. The sim pauses in the usual manner and can be unpaused with the standard "P" key. The sim pause function is a toggle operation. So if you set a future pause time, and then manually pause the sim using the P key, then when the pause time is reached the sim will be unpaused by the script. While this is somewhat interesting, I'm not sure how useful it is. The script SetPauseFSX.lua below is very similar to the above, but for FSX. SetPauseP3Dv4&5.lua SetPauseFSX.lua