Jump to content
The simFlight Network Forums

ark1320

Members
  • Posts

    591
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by ark1320

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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.
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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 ..
  20. 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)
  21. 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)
  22. 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
  23. 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
  24. 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
×
×
  • 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.