ark1320

Thanks John. Al

If a profile specific aircraft section does not have a specified [AXES.xwz] section, does it automatically use the [AXES] specification in the general, non-profile section of the FSUIPC.ini file? Thx, Al

In previous sims I have always disabled controllers and set up all my axes using just "Send Direct to FSUIPC Calibration". In MSFS it seems I need to make use of the Sensitivity and Reactivity settings as well ( using just the FSUIPC axes slope curves do not seem to be sufficient in my case). If I still use "Send Direct to FSUIPC Calibration" for my axes in MSFS, will the MSFS axes Sensitivity and Reactivity settings be applied to the axes data output from FSUIPC? In other words will the axes be "processed" twice? Or would it be better to just use the MSFS axes controls? Thx, Al

I put together a little Macro test file MacroTest.mcro that looks like this: [Macros] 1=L:PITOT_L=SET,0 2=L:PITOT_R=SET,0 3=L:PITOT_L=SET,1 4=L:PITOT_R=SET,1 In the resultant FSUIPC6 Key Assignment dropdown list, the 0 and 1 SET values do not show up, so the dropdown has what looks like duplicate entries. That seems confusing, am I doing something wrong? I had expected the actual SET values associated with each line in the Macro file to show up in the dropdown list to facilitate the key assignment process. For SET, the FSUIPC user manual says: Set copies the parameter in the Macro invocation to the identified Lvar. Alternatively, a value can be given explicitly here, by “Set,n”. It is not clear to me what is meant by "Macro invocation" -- is this referring to the Parameter field associated with the dropdown list? If you do have to enter the desired SET value in the Parameter field, what is the utility of using SET, n in the Macro file? Thanks, Al

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

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

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, Al

Is there a way to restart FSUIPC6 without having to restart P3D? Thanks, Al

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

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