Jump to content
The simFlight Network Forums


  • Content Count

  • Joined

  • Last visited

  • Days Won


ark1320 last won the day on January 10

ark1320 had the most liked content!

Community Reputation

11 Good

About ark1320

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
    Colorado, USA

Recent Profile Visitors

2,191 profile views
  1. Hi, Just saw your question here-- sorry I didn't notice it sooner. You need to put the Lua script in the same location as your FSUIPC.ini file, and then use FSUIPC to assign either a keyboard key or button to activate (call) the script. Al
  2. Well that's interesting. What I'm doing is calling a script that sets a flag after a delay -- the delay (set by the user) could be from about 0.5 to 3 seconds or so, and the script could be recalled before the delay has run its course. So I could implement the delay with ipc.sleep(), or use a delay loop that looks for a change in time using ipc.elapsedtime(). With respect to the blocking system call issue you mentioned, does the delay loop approach have any advantage over using ipc.sleep()? Thanks, Al
  3. I know that if when a Lua script is running you re-invoke (recall) the same script, the previous script is 'killed' and replaced by the 'new' one. My question is, if the script contains an ipc.sleep() function and that ipc.sleep function is active when the script is re-invoked (i.e., the script is sleeping), is the original script, and the ipc.sleep action, still instantly killed? From some simple tests I tried it does seem 'everything' is killed when the script is re-invoked, but just wanted to check here in case someone has experienced something different in this regard. Thanks,
  4. Is there a way to restart FSUIPC6 without having to restart P3D? Thanks, Al
  5. Hi John, The download for FSUIPC 7.0.8 seems to install as ver 7.0.7, at least that's what the installer says, and what it says under the 'new' installed FSUIPC7 'Help > About' dropdown, and also what the Win10 Control Panel Programs and Features shows. Perhaps just a file naming issue? So not sure what version has really been installed. Regards, Al
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  • 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.