Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by ark1320

  1. 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
  2. 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 o
  3. 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.74
  4. 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 determi
  5. 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 u
  6. 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"
  7. 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
  8. 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
  9. 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 r
  10. 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
  11. 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
  12. 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
  13. 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)
  14. 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 0x6
  15. 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
  16. 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 c
  17. 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" a
  18. 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 w
  19. 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);
  20. 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
  21. 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
  22. 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 the
  23. 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
  24. 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
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.