ark1320

Hi Pete, Does the ipc.display and setowndisplay combination work in P3Dv4? I recall there have been some issues with this in the past. I'm trying to help a friend but unfortunately don't have P3D myself for testing. Scripts I've written using ipc.display that work in FSX on my friend's machine are not displaying anything in P3Dv4. Thanks for an update on this, Al

I forgot to mention I'm using the boxed FSX, but it sounds like in this case the answer is the same regardless of which sim is being used. Thanks for the response, Al

Hello Pete, Is there a way to control the transparency of the window created by the ipc.setowndisplay command? I would like to reduce the transparency to increase readability of the info displayed in the window. Thanks, Al

Yes, a good lesson! Thanks very much for the help. Al

Hi Pete, Below is information from the FSUIPC4.LOG files for the Baron 58 and B737. Al Baron B58 1141 SimConnect_Open succeeded: waiting to check version okay 1141 Trying to use SimConnect Acc/SP2 Oct07 1141 Opened separate AI Traffic client okay 3563 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0) 3563 Initialising SimConnect data requests now 3563 FSUIPC Menu entry added 3594 C:\Users\Al\Documents\Flight Simulator X Files\Default Safe Flight Baron 58 35L KCOS.FLT 3594 C:\FSX\SimObjects\Airplanes\Beech_Baron_58\Beech_Baron_58.AIR 4219 Monitor IPC:060C (U8) = 0 50313 Aircraft loaded: running normally now ... 50313 User Aircraft ID 1 supplied, now being used 50641 System time = 18/10/2017 16:30:02, Simulator time = 11:49:47 (17:49Z) 50641 Monitor IPC:060C (U8) = 2 50641 SimRead: 060C="IS GEAR RETRACTABLE" INT32: 2 (0x00000002) 51406 Aircraft="Beech Baron 58 EPAV" 51641 Starting everything now ... 51719 ASN active function link set 51719 Ready for ActiveSky WX radar with additional data B737 1109 SimConnect_Open succeeded: waiting to check version okay 1109 Trying to use SimConnect Acc/SP2 Oct07 1109 Opened separate AI Traffic client okay 3609 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0) 3609 Initialising SimConnect data requests now 3609 FSUIPC Menu entry added 3625 C:\Users\Al\Documents\Flight Simulator X Files\Default Safe Flight Baron 58 35L KCOS.FLT 3625 C:\FSX\SimObjects\Airplanes\Beech_Baron_58\Beech_Baron_58.AIR 4297 Monitor IPC:060C (U8) = 0 59859 C:\FSX\SimObjects\Airplanes\B737_800_Default_Modified\Boeing737-800.AIR 139719 User Aircraft ID 1 supplied, now being used 140015 System time = 18/10/2017 16:40:14, Simulator time = 11:49:47 (17:49Z) 140015 Monitor IPC:060C (U8) = 2 140015 SimRead: 060C="IS GEAR RETRACTABLE" INT32: 2 (0x00000002) 140797 Aircraft="Boeing 737-800 EPAV" 141000 Starting everything now ... 141094 ASN active function link set 141094 Ready for ActiveSky WX radar with additional data 141156 Plug-in thread table check:

Pete, The default a/c I tried were the Baron 58 and the B737. Al

Yes, I get the value 2 for a number of different default and add-on a/c. I guess as you say it is a case of non 0 means true. I'll be careful to code accordingly in the future. I don't know how I managed to post in the wrong forum this time -- sorry. Thanks for the help, Al

Hi Pete, When debugging some code I found that when reading offset 060C with ipc.readUB(0x060C) for an a/c with a retractable landing gear the value returned was 2 instead of 1 as specified in the offset documentation. Is this just a simple documentation typo, or perhaps is there some additional significance (some characteristic of the landing gear) associated with the "2" versus the "1" ? With a fixed gear a/c the value returned is 0 as expected. Thanks, Al FSX with SP2, FSUIPCv4.971, Win10

I think I understand now. If I have three functions assigned to one button or key and want two of them to be general and one profile specific, I just need to put the two general function assignments in the General section of the FSUIPC ini file, and put all three function assignments in the a/c profile specific section of the FSUIPC ini file. Thanks for the help Thomas. Al

Hi Pete, If under the General button area of FSUIPC.ini I assign three functions (gear down and two Lua scripts) to button 19 as shown below, all works well. 450=PY,19,C66080,0 -{GEAR_DOWN}- 451=PY,19,CL95:R,0 -{Lua Landing_Params}- 452=PY,19,CL52:R,0 -{Lua AppchAltCalls}- However, if I make one of the Lua script assignments Profile Specific to aircraft A by moving it from the General area to aircraft A's button assignment area, only that script works for aircraft A, the two remaining button 19 functions under the General button area no longer work for aircraft A. I assume this is because in some sense I have made button 19 itself profile specific to aircraft A rather than just the associated Lua script. Do you see anything I can do to resolve this issue? Thanks, Al FSX, FSUIPC 4.971, Win10

Hi Pete, Are the FSUIPC4 Offsets at the same locations in FSUIPC5? I'm trying to determine if it is reasonable to expect that most Lua scripts written for FSX using FSUIPC4 will run in P3Dv4 using FSUIPC5. Thanks, Al

HUD Parameters for FSX HUDparameters.lua is a Lua script that displays flight parameters in a small text window that pops up when the script is selected by an assigned key or button if the aircraft is in the air. Parameters displayed are: · Indicated Airspeed (IAS. Kts) · True Airspeed (TAS, Kts) · Ground Speed (GS, Kts) · Mach# (when above a user settable altitude, currently 25000ft) · Altitude (ALT, ft) · Radio Altitude (RA, ft) · Vertical Speed (VS, ft/min) · Vertical Speed per Nautical Mile (VS/NM, ft/NM) · Attitude Indicator pitch (AI, degrees) · Flight Path Angle (FPA, degrees) The top of the script contains user settable values for the size and location of the display, the altitude above which the a/c Mach# will be displayed (default is 25000ft), the data update interval in milliseconds (default is 2000), and whether or not data is to be logged in HUDparameters.log (default is 0, off). These values can be set using a text editor like NotePad. A registered copy of FSUIPC is required to execute the Lua script. Simply copy the script to the Modules folder of FSX and use FSUIPC4 to assign a key, button or switch to toggle the script on and off. The script turns off if the aircraft is on the ground. HUDparameters.zip

My understanding is FSW is built on FSX to some degree, but in general FSX addons, a/c, etc are currently not compatible with FSW. Al

Hi Pete, Has DTG made any effort to coordinate with you regarding using FSUIPC with their soon to be released 64 bit FSW sim? If not, FSW is likely a non-player for me, Thx, Al

Hi Pete, The documentation on event.offset() says "The function is also executed initially, when the plugin is first run, in order to initialise things". In my application, event.offset() is used inside a nested function. That is, function A calls function B, and event.offset is part of function B and calls function C when the offset changes. However, if I understand correctly, the initial execution of function C will happen the first time function B is called even if the offset has not changed value -- is that correct? Thanks, Al

Pete -- thanks very much for the further explanation -- very helpful. A related question please: the event being monitored by event.offset() is the on-ground flag in offset 0x0366 which has a value of 1 when the aircraft is on the ground. If the aircraft bounces during landing, and thus is only on the ground for a small fraction of a second perhaps during the bounce, is there a reasonable chance the bounce will be 'missed' as far as the on-ground flag is concerned because of sim or script timing issues (e.g., the sim was busy doing other things when the bounce occurred and so the on-ground flag didn't change)? Thx, Al

To clarify a bit, my situation is that the function called by event.offset() is logging aircraft data and may typically run for 8 to 10 seconds. During that time, the location being monitored by event.offset could change so as to trigger a second call to the same logging function while the first is still running, and thus my questions above. Thanks very much for the help. Al

Hi Pete, I am using the command event.offset(offset, "type", "function-name) in a script that is listed under [Auto] in the FSIPC.ini.file. My questions are: 1. If the command makes two sequential calls of “function-name” and the first called function is still running when the second call occurs, are there now two instances of the function running, or did the second call terminate the first function? 2. If two instances of the called function would be running (which is what I think), what might be a good way to terminate the first function when the second call is made? Thx, Al

Thanks Pete and Thomas, good info. Al

Thanks for the info. Just to to clarify, I assume that, in general, editing changes made directly to the FSUIPC.ini after FSX has loaded will not "be in effect" until FSX is restarted (although perhaps something like an edited compound switch assignment might be immediately activated by a subsequent Reload all buttons operation). Thx, Al

Hi Pete, Two questions please: Is there a way to access the FSUIPC tabs, like Key Presses or Buttons+Switches, to make changes without first having to load a flight? When you use the Reload all buttons or Reload all keys features, is the complete FSUIPC.ini file reloaded so any direct edits made 'elsewhere' to the file will be updated as well? Thx, Al

Hello Pete, Offset 0x31C8 is described as vertical acceleration relative to the world axes. Am I correct in understanding that this acceleration is a measure of the time rate of change of an aircraft's vertical velocity, as we normally think of it, relative to the earth's surface? For example, this would be a measure of how an aircraft's vertical velocity is changing with time during landing. And offset 0x3068 is described as vertical acceleration relative to the body axes. I assume the body in this case is the aircraft. So if the aircraft is flying 'level' (meaning not pitched up or down), I assume this acceleration value would be the same as the 0x31C8 value, but would otherwise differ with the pitch of the aircraft since, for example, in a steep climb the vertical axis of the aircraft is no longer vertical relative to the earth's surface. I would also like to ask about how often, on average, would you estimate these values, or offsets in general, get updated? My understanding is values in FSX nominally get updated about 18 times per sec, or about once every 56 milliseconds. Is this a reasonable number for the typical update rate of an offset? Thanks, Al

NpCmoveAircraft is a Lua script in the Numberpad Control family of FSX scripts that can be used to move an aircraft to a new position. Each step includes prompts for the required input and format. User inputs include: The distance to move (NMs) The direction to move (degrees magnetic) The desired altitude (ft) The desired aircraft heading (degrees magnetic) The desired aircraft IAS (Kts) and landing gear position -- up (u), down (d) or fixed (f) Or - For any of the five inputs the user can simply enter a carriage return (Enter key) to signify No Change for that particular entry Prior to the move the aircraft can be on the ground or in the air. So, for example, NpCmoveAircraft can be used to simply turn an a/c around, move it to the other end of a runway, reposition it for another approach after landing, jump ahead in cruise, catch up to another a/c, etc. NpCmoveAircraft works with default FSX aircraft and many add-on aircraft that adhere to the standard FSUIPC offsets. A registered copy of FSUIPC is required to execute the NpCmoveAircraft Lua script. Simply copy the script to the Modules folder of FSX and use FSUIPC to assign a ‘hot key’, button or switch to activate the script. NpCmoveAircraft.zip

Well, a friend running the same Lua scripts does not see the delay problem I described above with the ipc.ask() function, so I still have a bug of some type to hunt down. If I find it I'll report back. Thx, Al

Pete, As you thought, the 'failure to display as expected' issue seems related to timing. I ran the following experiment using the same flight in all cases: If I waited 10 secs after the flight loaded (after the a/c appeared on the runway) to activate the Lua script with the ipc.ask() function, it worked as expected 8 times in a row, restarting FSX each time. If I waited 5 secs after the flight loaded to activate the Lua script with the ipc.ask() function, it failed to display as expected 8 times in a row, restarting FSX each time. By fail I mean nothing was displayed as a result of the script being activated by a keystroke. So somewhere between 5 and 10 seconds seems to be a critical delay time for the script with the ipc.ask() function, at least on my machine. This is probably why my script worked as expected only part of the time. I didn't wait long enough to test it. If I waited a sec or less after the flight loaded, a different Lua script using a single line ipc.writeSTR(0x3380, "string") function worked 8 times in a row, restarting FSX each time. So it seems that on my machine the single line ipc.writeSTR(0x3380, "string") function is not nearly as time sensitive as the ipc.ask() function. Finally, inline with a comment you made in a post above, when I modified the above ipc.writeSTR(0x3380, "string") function to display two lines, the script behavior time-wise was the same as it was for the script with the ipc.ask() function. Al