ark1320

I created a temporary folder in the FSX modules folder and moved all my Lua scripts into this temporary folder to hide them from FSUIPC. I also renamed my FSX.cfg file so FSX would have to build a new one. I then rebooted the computer an restarted FSX. After all that, I still got the same strange green bar, with a message which is definitely from one of my own scripts, when I loaded and then reloaded a file as described above. Amazing! The only other text displayed was Shift+Z info, the Cockpit View Zoom setting, and the Parking Brakes set message. Al

I get the same results with the Test2 dll as I did with Test1 dll. I have noticed another strange thing. If I start FSX and load a flight, and then hit the ESC key and return to the Free Flight page of FSX, and then click on Fly Now to reload the same flight, when the flight reloads I immediately get a 3380/32FA type green bar one line display on the screen that is related to a Lua script that I have been using for years. And the display remains on the screen instead of closing after a few seconds as it normally would. This happens even though I did not run any Lua scripts since FSX was started, and this also happens when I start with different initial flights as well , but not with all initial flights. And if after returning to the Free Flight page as described above I reload a different flight then what was initially loaded, then the strange green bar display may or may not appear. And if it does display it is not always the same. I thought maybe some type of corrupt display information was getting saved with a stored flight, but didn't see anything in the .FLT file. This probably makes sense since this strange display is not seen on the initial flight load, but rather on the reload of the flight. I was also wondering if FSUIPC saves information on scripts that have been run in a cache, or maintains a keystroke buffer, and perhaps something in the cache or buffer has become corrupt? I can't understand what is triggering the strange green bar display when no Lua scripts have been run since a restart of FSX. Despite two attempts, I wasn't able to roll back the latest Win10 update. For some reason the Restore operation couldn't find a file it wanted to restore. . Al

Unfortunately, the test FSUIPC.dll did not help. I see that I had a Win10 update on 8 Feb. I'm not sure if this problem existed before that time or not, but I will do a Restore to roll back that update to see if it makes a difference and will let you know. I sincerely appreciate your efforts on my behalf. Al

Yes, once an ipc.ask() script starts working, all scripts using it work until FSX is restarted. Once in a while, the scripts do work right away after an FSX restart, but this does not happen very often. My point, a poor one perhaps, was that holding the script activation key down, and thus making repeated calls to the script, did not help. I have used scripts with ipc.ask() quite a bit in the past without any problem, and I can't put my finger on what has changed in the last week or so. Very odd. Thanks very much for the time you have spent on this. Maybe the problem will go away with the next forced Win10 update -- one can always hope! Al

With both FSUIPC 4.959 and 4.962: Displaying multiple lines with ipc.writeSTR(0x3380, "string") with rare exception, required two or three calls to the script (key inputs). If, however, I first called a script with a single display line via ipc.writeSTR(0x3380, "string"), then the multiple line ipc.writeSTR(0x3380, "string") display worked with the first call (key input). My comment about seeing the problem with different scripts, restarting FSX each time, was just to say the problem did not seem related to a particular script. I will be glad to try any experiment that may help track down the problem. I don't have the No Repeats! turned on under the Keys Presses tab, but holding down a key still didn't help. Thx, Al .

Hi Pete, Ran an experiment by going back to FSUIPC 4.959 -- above problem went away. Then went back to FSUIPC4.962 and the problem returned. Did this experiment twice with the same results. Some other info that may be helpful: - there is no problem with scripts that use the ipc.writeSTR(0x3380, "string"); ipc.writeSW(0x32FA, 2); display -- seems to work every time. - when running a script that uses ipc.ask(), nothing is initially displayed, but if I then hit a key that calls a script using the ipc.writeSTR(0x3380, "string") display, this triggers the ipc.ask() argument to display along with the keystroke. Sometimes just any two keystrokes seems to trigger the ipc.ask() to display its argument and the keys there were inputted. - once the script with the ipc.ask() gets working, it continues to work ok until the next start of FSX, so it seems to be some type of initialization problem perhaps. - multiple scripts with the ipc.ask() function show the same problem. Thx for any ideas, Al

Pete, In the FSUIPC.ini file all the Lua scripts are listed and numbered under the [LuaFiles] heading. Over time many scripts have been added and deleted so the number sequence is no longer close to contiguous. For example, the first listed script is numbered 19, half way down the list is the script numbered 1, etc. So I had the 'brilliant' idea of deleting all the entries under [LuaFiles] and letting FSUIPC rebuild a contiguously numbered list. That was a bad idea, I found out, because the key and button assignments are made based on the Lua script numbering. Fortunately, I had a backup and was able to recover (I have about 60 scripts). So my question is, is there a way to preserve the script - key/button assignments if the scripts are renumbered? Thx, Al

FSUIPC updated. I'll report back if I figure out what the problem is. Thx, Al

Pete, Following up on your suggestion about an interaction/conflict with display logic, I wonder if the handy little script below ( not mine ), which displays touchdown vertical speed, might be contributing to my ipc.ask() problem? I've also now noticed I am having the same type of ipc.ask() display problem with another script different than the one above, which further supports your display logic conflict theory. Why entering a value suddenly allows the ipc.ask() message, and the entered value, to then both display is baffling. Thx, Al ipc.setowndisplay("FPM", 0, 60, 6, 1) function logvs(off, val) if val ~= 0 then -- if on ground flag just set, get VS, convert it and log it vs = ipc.readSD(0x030C) --original was 030C then 31A0 vs = vs * 60 * 3.28084 / 256 ipc.log("Vertical speed at touchdown = " .. math.floor( (vs * 10^2) + 0.5) / (10^2), 5) ipc.display(math.floor( (vs * 10^2) + 0.5) / (10^2), 45) -- 30 means display for 30 sec end end -- set to call above routine whenever "on ground" flag changes event.offset(0x0366, "UW", "logvs")

Hi Pete, I have a Lua script that uses the ipc.ask() function inside a while true do loop. When the script is activated with a key stroke, the contents of the ipc.ask() is displayed on the green bar window as expected, but only about half the time. The other times nothing at all appears until an input is provided at which time both the contents of the ipc.ask() and the input that was provided is displayed, all before a carriage return is entered. It is as if the input to the ipc.ask() is required before the script is activated. I can't seem to track down the cause of this behavior. I would appreciate hearing any ideas you may have. The while true loop is below. Thanks, Al FSX, FSUIPC 4.96, Win10 (Edit: Just realized I put this in the wrong subforum but don't know how to move or delete it. Sorry. Moderator please move to Support subforum.) while true do move_distance_nm_str = ipc.ask(" Enter Distance to Move A/C in NMs (0-500), or just the ENTER key for 0 NM \n\n * to Exit " ,1) if move_distance_nm_str == "*" then ipc.exit() --terminate the Lua script end move_distance_nm = tonumber(move_distance_nm_str) --convert string to a number if move_distance_nm == nil then move_distance_nm = 0 break elseif move_distance_nm >= 0 and move_distance_nm <= 500 then -- if values good, exit while loop break else ipc.writeSTR(0x3380, "Invalid Entry"); ipc.writeSW(0x32FA, 2); --display on green bar for 2 sec ipc.sleep(2000) end end

Pete, I think I figured it out. I need to 'reverse' the calculations you show for converting offset 0x0560 and 0x568 to degrees in order to get back to the flight sim format (whatever that is) for latitude and longitude, and then use the ipc.writeDD() command to write these values back to offsets 0x0560 and 0x0568. Al

Hi Pete, I'm trying to figure out how to format/convert latitude and longitude values (both of which I have in degrees) so I can use a Lua script to write these values to offsets 0x560 and 0x0568. I don't understand what the appropriate units are for writing to these offsets, and what the appropriate ipc.write command to use would be. The goal here is to move an aircraft to a lat-long location. I would appreciate any suggestions. Thx, Al

Pete, To hopefully save you some time, I think the problem was my error (I was 'helping' Angelo). For some reason (age problem, maybe? ) I forgot to put Lua in front of the Lua script names in the [Auto] section of the FSUIPC.ini file like: [Auto] 1=Lua Throttle_Idle_1 2=Lua Throttle_Idle_2 3=Lua Throttle_Idle_3 4=Lua Throttle_Idle_4 As a result, the event.button command did nothing. Until Angelo can give this fix a try, it likely is not worth your time to look further into this. Al

Pete, If it wasn't for FSUIPC and the superb support you provide as accurately expressed by the posts above, I don't think I'd be in the the flight sim hobby. FSUIPC and Lua scripts have become absolutely key to my enjoyment of flight simulation. If there was a Flight Sim Hall of Fame (and there should be), you would be in it for sure! Al

In case it helps someone, it now seems the source of the CTDs was actually an out of date ASUS utility program, AI Suite II, that needed to be updated for Win10. AI Suite II runs at startup and provides access to the Bios and motherboard settings. Al

Pete, When I went to collect more log data much to my surprise I found the problem had gone away, at least for now! I can't explain it -- maybe there was some kind of Win10 update behind the scenes. Hopefully the problem won't come back, but this kind of magical fix leaves me a bit nervous. Best, Al

Luke, I've been trying to figure out what has been causing the CTDs for about two weeks now and have noticed the faulting module varies, but the two most commonly reported faulting modules are: KERNALBASE.dll, path C:\WINDOWS\System32\ API.dll, path C:\FSX\ and FSX.exe is located in C:\FSX. FSUIPC seems to work fine as long as I don't try to reload an a/c. Al

I recently upgraded from Win7 to Win10. FSX seems to run OK, but one problem I'm having is if I attempt to change a/c from within the sim using the aircraft drop down menu after loading a flight, I get a CTD every time. Through process of elimination over the past two weeks the problem seems to be related to FSUIPC 4.955C, or FSUIPC's interaction with FSX under Win10. If I disable FSUIPC in the FSX dll.xml file, the problem goes away; if I re-enable FSUIPC, the CTDs return. This happens even with every other dll.xml program entry disabled except dll.xml itself. I have tried reinstalling FSUIPC4 but that didn't help. What is particularly strange is I have FSX-SE on the same machine and it does not exhibit this CTD problem. FSUIPC log file is below. After loading my default flight with a C172, I tried to switch aircraft to the default Baron 58 and the result was an immediate CTD. Thanks for any ideas. Al ********* FSUIPC4, Version 4.955c (14th June 2016) by Pete Dowson ********* Windows version reported as 6.2.?.9200 fsx.exe version = 10.0.61472.0 Reading options from "C:\FSX\Modules\FSUIPC4.ini" Running inside FSX on Windows 8.0 or later Module base=66DA0000 User Name="Alan Klayton" User Addr="arklayton@comcast.net" FSUIPC4 Key is provided WIDEFS7 not user registered, or expired 47 System time = 17/08/2016 12:13:00 47 FLT path = "C:\Users\Al\Documents\Flight Simulator X Files\" 47 ------ Module Version Check ------ 47 acontain.dll: 10.0.61472.0 47 api.dll: 10.0.61472.0 47 controls.dll: 10.0.61472.0 47 fs-traffic.dll: 10.0.61472.0 47 G3D.dll: 10.0.61472.0 63 language.dll: 10.0.61472.0 63 sim1.dll: 10.0.61472.0 63 visualfx.dll: 10.0.61472.0 63 weather.dll: 10.0.61472.0 63 window.dll: 10.0.61472.0 63 ---------------------------------- 78 Trying to connect to SimConnect Acc/SP2 Oct07 ... 94 FS path = "C:\FSX\" 453 ---------------------- Joystick Device Scan ----------------------- 453 Product= Saitek Pro Flight Rudder Pedals 453 Manufacturer= Saitek 453 Vendor=06A3, Product=0763 (Version 1.1) 453 Serial Number= Saitek 453 Product= Saitek Pro Flight Yoke 453 Manufacturer= Saitek 453 Vendor=06A3, Product=0BAC (Version 3.4) 453 Serial Number= Saitek 453 ------------------------------------------------------------------- 719 LogOptions=A0000000 00000001 719 ------------------------------------------------------------------- 719 ------ Setting the hooks and direct calls into the simulator ------ 719 --- CONTROLS timer memory location obtained ok 719 --- SIM1 Frictions access gained 719 --- FS Controls Table located ok 719 --- Installed Mouse Macro hooks ok. 719 --- Wind smoothing fix is fully installed 719 --- G3D.DLL fix attempt installed ok 719 --- All links checked okay 719 ------------------------------------------------------------------- 719 SimConnect_Open succeeded: waiting to check version okay 719 Trying to use SimConnect Acc/SP2 Oct07 2047 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0) 2047 Initialising SimConnect data requests now 2047 FSUIPC Menu entry added 2078 c:\users\al\documents\flight simulator x files\Default Safe Flight C172 35L KCOS.FLT 2078 C:\FSX\SimObjects\Airplanes\C172\Cessna172SP.AIR 2516 Monitor IPC:024C (S32) = 3560696 4500 *** EVENT: Cntrl= 66514 (0x000103d2), Param= 0 (0x00000000) ATC_MENU_CLOSE 12656 Monitor IPC:024C (S32) = 3316512 22547 Monitor IPC:024C (S32) = 3176272 24438 System time = 17/08/2016 12:13:25, Simulator time = 12:13:03 (18:13Z) 24703 Aircraft="Cessna Skyhawk 172SP EPAV" 25422 Starting everything now ... 26594 Advanced Weather Interface Enabled 32531 Monitor IPC:024C (S32) = 3127844 49531 Sim stopped: average frame rate for last 25 secs = 29.8 fps 49531 Max AI traffic was 2 aircraft 52719 Monitor IPC:024C (S32) = 3123900 87469 C:\FSX\SimObjects\Airplanes\Beech_Baron_58\Beech_Baron_58.AIR 94359 System time = 17/08/2016 12:14:34, Simulator time = 12:13:28 (18:13Z) 94359 *** FSUIPC log file being closed Minimum frame rate was 30.1 fps, Maximum was 30.9 fps Minimum available memory recorded was 3055Mb Average frame rate for running time of 25 secs = 29.8 fps G3D fix: Passes 11205, Null pointers 0, Bad pointers 0, Separate instances 0 Maximum AI traffic for session was 3 aircraft Memory managed: 25 Allocs, 25 Freed ********* FSUIPC Log file closed ***********

Just to close the loop in case someone else has a similar problem: The solution to this problem was to 'elevate' the Logitech SetPoint program to start in admin status. FSX-SE normally runs elevated (in admin mode) and FSX does not, and neither did SetPoint, so SetPoint and FSX worked fine together, but FSX-SE did not. SetPoint is started at bootup, and Win10 will not allow a Startup program to automatically run elevated. So I now use the Task Scheduler to delay the startup of SetPoint for 30 seconds which allows it to be started elevated, and so it now works fine with FSX-SE. Al

No, FSX-SE does not see the four specialty keys in the assignments dialogue, but FSX does. FSX-SE does see all the 'normal' keys, however. What seems really strange is that when FSX-SE is running if I start up a little key detection program (KeyCodes3.exe) that displays what key codes are generated when you push or release a key, it does see the specialty keys! Al

The log showed FSUIPC doesn't see anything when I push the keys in question when running FSX-SE. And I can't find anything 'extra' running with FSX-SE compared to FSX which is still installed and responds to the keys in question. Very strange, perhaps a result of the upgrade process from Win7 to Win10. In Win7, both sims worked as expected. There is a Win10 update due out tomorrow, guess I'll just wait and see what happens after that. I'm out of ideas. Thx, Al

Logitech Setpoint is a software utility for assigning operations/or keystrokes to Logitech mice buttons and keyboard keys. I use Saitek yoke, throttle quadrant and rudder pedals for controllers. When FSX-SE is running and I have have FSUIPC in the key presses tab, it does not see the specially key I set up. It does see it in the key presses tab if FSX is running, so something is capturing the keystroke before FSUIPC can get it when FSX-SE is running. I am using FSX-SE in the Steam 'Off-line' mode. I have tried copying the FSUIPC.ini file from the FSX modules folder to the FSX-SE modules folder, but it has not made a difference. Al

Hi Pete, I recently upgraded to Win10 and am running both FSX and FSX-SE with FSUIPC4.955c. Using Logitech SetPoint, I set up some specialty keys I don't normally use to generate key sequences, such as Ctrl+num8, for activating Lua scripts. The strange thing is that while this works with FSX, it does not work with FSX-SE -- there is no apparent response. However, if I 'manually' generate the key sequence Ctrl+num8 by pushing the individual keys, the Lua script is activated in FSX-SE. FSX-SE identifies Ctrl+num8 as available for assignment, so there is no conflict there. Something must be trapping the use of the specialty key when FSX-SE is running. Any ideas on what I could check? Thx, Al

Hi Pete, Each script (or autopilot function) would have a user selected key assigned to it, but each function will have a fixed ipcPARAM value assigned by me. I assume the missing word in the quote above is ' detect' ? Is there a limit on the number of Lua scripts that can be listed in FSUIPC.ini at one time? Thanks very much for all the info. Al

Hi Pete, I have a set of 12 individual Lua scripts that allow the assignment of keys to 12 autopilot functions in FSX. The scripts are small, typically about 20 lines or less each. My question is, would it be better (more efficient operationally) to combine all these scripts into one script and then differentiate the particular functions using 12 ipcPARAM values (perhaps by defining 12 functions and using a large if-then-elseif statement), or leave them as separate scripts? Or perhaps given the small size of the scripts, it doesn’t make much difference either way? I don’t know if Lua scripts are reinterpreted or recompiled on each call, or if there are other timing considerations when interfacing with FSX, etc. Thx, Al