Pete Dowson

Unfortunately, installing that BGL here doesn't cause any problems at all. It processes perfectly normally. Here are the results in the Runways.txt log file: ============================================================================= TestScenery\scenery\AF2_UAFG.bgl ============================================================================= Airport UAFG :N42:38:52.5106 E077:01:53.6307 5496ft Country Name="Kyrgyzstan" State Name="" City Name="Chelpon Ata" Airport Name="Chelpon Ata" in file: TestScenery\scenery\AF2_UAFG.bgl Runway 34 /16 centre: N42:38:50.8909 E077:01:48.7192 5496ft Runway 34 closed for take-off Runway 16 closed for landing Computed start 34 : Lat 42.642120 Long 77.032560 Start 16 : N42:39:07.3796 E077:01:41.5092 5496ft Hdg: 162.0T, Length 4100ft Computed start 16 : Lat 42.652817 Long 77.027835 Hdg: 342.000 true (MagVar 4.000), Concrete, 4100 x 110 ft *** Runway *** UAFG0340 Lat 42.642120 Long 77.032562 Alt 5496 Hdg 338 Len 4100 Wid 110 *** Runway *** UAFG0160 Lat 42.652817 Long 77.027832 Alt 5496 Hdg 158 Len 4100 Wid 110 COM: Type=6 (TOWER), Freq=128.00, Name="×åëïîí Àòà" Taxipoint #0, type 1 (normal): N42:38:31.8430 E077:01:57.1923 -- Forward Taxipoint #1, type 1 (normal): N42:39:10.1007 E077:01:40.3137 -- Forward Taxipoint #2, type 1 (normal): N42:38:57.3697 E077:01:45.9286 -- Forward Taxipoint #3, type 1 (normal): N42:38:58.2768 E077:01:49.9358 -- Forward Taxipoint #4, type 1 (normal): N42:39:07.0233 E077:01:41.6685 -- Forward Taxipoint #5, type 1 (normal): N42:38:33.3008 E077:01:56.5580 -- Forward Taxipoint #6, type 1 (normal): N42:38:54.3895 E077:01:52.3740 -- Forward Taxipoint #7, type 1 (normal): N42:38:58.0824 E077:01:51.0559 -- Forward Taxipoint #8, type 1 (normal): N42:38:55.2317 E077:01:52.0278 -- Forward Taxipoint #9, type 1 (normal): N42:38:54.6810 E077:01:52.2466 -- Forward Taxipoint #10, type 1 (normal): N42:38:55.5557 E077:01:51.9008 -- Forward Taxipoint #11, type 1 (normal): N42:38:56.1712 E077:01:51.6431 -- Forward Taxipoint #12, type 1 (normal): N42:38:56.3655 E077:01:51.5644 -- Forward Taxipoint #13, type 1 (normal): N42:38:57.1106 E077:01:51.2650 -- Forward Taxipoint #14, type 1 (normal): N42:39:00.5768 E077:01:49.9615 -- Forward Taxipoint #15, type 1 (normal): N42:39:00.8683 E077:01:51.2828 -- Forward Taxipoint #16, type 1 (normal): N42:38:59.8641 E077:01:51.7300 -- Forward Taxipoint #17, type 1 (normal): N42:38:59.5402 E077:01:50.4186 -- Forward Taxipoint #18, type 1 (normal): N42:39:00.3824 E077:01:49.1504 -- Forward Taxipoint #19, type 1 (normal): N42:38:58.4064 E077:01:52.3224 -- Forward Taxipoint #20, type 1 (normal): N42:38:59.3458 E077:01:49.5429 -- Forward Gate 1 [#G0]: N42:39:00.3824 E077:01:51.5016 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 162.3T Gate 2 [#G1]: N42:39:00.0585 E077:01:50.1802 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 162.2T Gate 3 [#G2]: N42:38:59.2486 E077:01:51.9989 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 341.5T Gate 4 [#G3]: N42:38:58.9247 E077:01:50.6938 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 341.8T Gate 5 [#G4]: N42:38:57.3050 E077:01:52.1857 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 72.4T Gate 6 [#G5]: N42:38:56.3655 E077:01:52.5478 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 72.4T Gate 7 [#G6]: N42:38:55.4261 E077:01:52.8742 Type 3 (GA Ramp Medium), Size 14.0m, Hdg 72.4T Gate 8 [#G7]: N42:38:54.5190 E077:01:51.4050 Type 2 (GA Ramp Small), Size 10.0m, Hdg 72.4T Gate 9 [#G8]: N42:38:55.3289 E077:01:51.0589 Type 2 (GA Ramp Small), Size 10.0m, Hdg 72.4T Gate 10 [#G9]: N42:38:56.1712 E077:01:50.7421 Type 2 (GA Ramp Small), Size 10.0m, Hdg 72.4T Gate 11 [#G10]: N42:38:57.0134 E077:01:50.4298 Type 2 (GA Ramp Small), Size 10.0m, Hdg 72.4T Taxipath (Name #0): Type 1 (Taxi), Start#=2, End#=3, Wid=15.24m Taxipath (Runway 34): Type 2 (Runway), Start#=4, End#=2, Wid=33.53m Taxipath (Runway 34): Type 2 (Runway), Start#=4, End#=1, Wid=36.58m Taxipath (Runway 34): Type 2 (Runway), Start#=5, End#=2, Wid=33.53m Taxipath (Runway 34): Type 2 (Runway), Start#=5, End#=0, Wid=36.58m Taxipath (Name #0): Type 3 (Parking), Start#=8, End#=G6, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=9, End#=8, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=9, End#=6, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=9, End#=G7, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=10, End#=8, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=10, End#=G8, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=11, End#=10, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=11, End#=G5, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=12, End#=11, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=12, End#=G9, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=13, End#=12, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=13, End#=7, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=13, End#=G10, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=13, End#=G4, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=14, End#=G1, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=15, End#=14, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=15, End#=G0, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=16, End#=G0, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=16, End#=G2, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=17, End#=16, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=17, End#=G1, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=17, End#=G3, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=18, End#=14, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=7, End#=3, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=19, End#=7, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=19, End#=G2, Wid=12.19m Taxipath (Name #0): Type 3 (Parking), Start#=7, End#=G3, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=20, End#=18, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=20, End#=3, Wid=12.19m Taxipath (Name #0): Type 4 (Path), Start#=17, End#=20, Wid=12.19m Taxiname: #0 = TaxiWay : G6-8-9-6 TaxiWay : G7-9 TaxiWay : G8-10-8 TaxiWay : G5-11-10 TaxiWay : G9-12-11 TaxiWay : G10-13-12 TaxiWay : G4-13-7-3-2 TaxiWay : G1-14-15-G0 TaxiWay : G0-16-G2 TaxiWay : G1-17-16 TaxiWay : G3-17-20-18-14 TaxiWay : G2-19-7-G3 TaxiWay : 20-3 FSM A/P UAFG, lat=42.647919, long=77.031563, alt=5496 So I'm afraid is looks more complex that this, and so far very specific to your system. I've never had any other similar crash reports for MakeRunways at all. Unless I can reproduce it I don't really have much chance of finding it. But one last stab. In the case where it crashes with this file enabled you should still have a partially completed log (Runways.txt). I know you said it was too large, even ZIPped, to send, but could you at least extract the last few entries so I can see where it got to? Pete

Okay. 02C8 is the current V/S, and 030C is a copy of that until the moment of touchdown, at which time 030C is no longer updated. In the 4.943 log the touchdown detection appears to be here: 6488472 Monitor IPC:02C8 (S32) = -911 6488472 Monitor IPC:030C (S32) = -911 6488488 SimRead: 02C8="VERTICAL SPEED" [also 0842] [also 030C] FLT64: -3.56170797639 because 030C is not updated later than that. In the 4.949 log the same point is reached here: 1991446 Monitor IPC:02C8 (S32) = -149 1991477 Monitor IPC:030C (S32) = -149 1991477 SimRead: 02C8="VERTICAL SPEED" [also 0842] [also 030C] FLT64: -0.584607480251 So, yes, when touchdown is detected the V/S is lower in the later version. Now the V/S figures after both of these occurrences are very low indeed. In the 4.943 log it decreases to -0.55, -0.13, -0.10, -0.09 .... remaining very low for the rest of the time, though still changing. In the later version the same applies: -0.35, -0.10, -0.01 etc, also remaining very low for the rest of the time, though still changing. The place in the 4.949 log where comparable touchdown speeds are seen is here: 1983459 Monitor IPC:02C8 (S32) = -911 1983521 Monitor IPC:030C (S32) = -911 1983521 SimRead: 02C8="VERTICAL SPEED" [also 0842] [also 030C] FLT64: -3.56359434419 which is a full 8 seconds earlier, and the aircraft is still descending at a decreasing but similar sort of rate thereafter for quite some time. So it really isn't as if the detection of the touchdown is being delayed by an inordinate amount. Now all this is directly using the V/S figures being provided by FSX-SE via SimConnect. There's really no way I know of that FSUIPC can actively change those values. So it is rather inexplicable. Something else is different too, though, looking at the log. In the 4.949 case you appear to be running ASN. In the 4.943 case it looks like something different, because these lines indicate a different weather control in operation, one using FSUIPC I suspect: : 5928943 NWI weather clear actioned 5928943 External weather discarded ASN's hooks are definitely there in the 4.949 log: 3541 ASN Running? Smoothing is by ASN Perhaps you need to make things more equal in order to get a comparison. It looks like with ASN the aircraft is floating very gently down to touchdown. Try with no weather control program at all. In fact no weather (clear it before the test) to ensure conditions are identical. Pete

The two values I gave you represent two different offsets, containing different values! They are not joined as a long name! There are 4 entries in the 4 entry table so you can enter up to 4 values! That's the point. You only need to use 2 out of the 4! Up to 4 different offsets can be monitored, but not bundled together! Offset monitoring is documented in the section on Logging in the User Guide. Pete

Oh dear. It is just text. Just look at the log in an editor, such as Notepad. Select the whole of it by dragging the mouse, Copy (Ctrl+Insert), then, in your message, position the cursor with the mouse and press Shift+Insert. This is called "copy and paste" and it is a very useful technique to use in most things to do with file editing and messages! Pete

Show me the FSUIPC4.LOG file from the FSX Modules folder. You can paste the whole thing in a message here. Pete

Well there are only minor changes between c and f, namely: 1. Correction to erroneous error message when assigning buttons 2. Extra logging for ASN WXreadar file problems 3. Fixes for errors in Lua functios to do with setting and clearing bits in values 4. A new Lua ext library function, "hasfocus" and that's it. All those changes only do anything if you are using the mentioned items, no changes whatsoever have been made to anything you would be using in normal running. As I said, sometimes when there is actually a problem occurring, you only actually get a resulting crash when the memory layout changes a little. If the update to FSUIPC really is the change which precipitated the result you are getting then I do think it's a pre-existing problem in any case which simply hasn't before resulted in a crash. You'll need to give me your email address. I'm not uploading one. But please also read what I'm saying above. There was an "e" release too -- 9th February. The "d" release was a test only, and went to specific folks only. Pete

Please ZIP up the BGL and email it to me -- petedowson@btconnect.com. Pete

And what was the previous version of FSUIPC you were using. And what other things have you changed? FSUIPC is very unlikely to be causing any sort of crash in NTDLL itself. There most certainly haven't been any changes in Lua which would affect the use of DynamicFriction.lua. I do think there is a particular problem in the SimConnect part of P3D3.1 which does cause NTDLL crashes, and it may simply be that the slightly different memory arrangements you get with different versions of any add-in create a crash in situations where otherwise it would simply be some sort of data glitch. There have been quite a few reports of crashes in NTDLL on the L-M forum. Mostly they tend to be access violations (error 5). Yours is error 0x374, which doesn't even appear to be listed in the usual MSDN list of codes. The only possibly lead I found using google is https://technet.microsoft.com/en-us/library/hh859221.aspx which appears to be talking about the file system and an error trying to delete something. Could you be using FSUIPC's autosave at all? Else I don't think FSUIPC specifically deletes files in normal operation. I suggest that you add your report to those already on the L-M forum. Regards Pete

The problem for Registration is that if I allowed both AND email to be different, and subsequently found that the keys had been copied to others or plastered on the Net for anyone to use, how would we be able to name the culprit? Surely it is easy enough to use the same name in both cases, even if it is now different. It was that way for the email address too for the first 5 years of this registration system, which is now over 12 years old, with very very very few problems over all those years! Pete

"Many" error 126? For how many different DLLs? Sorry, that makes no sense. Of course, it would be better to show me the actual log so I could see what you are possibly misinterpreting. However, as pinned in post #3, the answer is to install SimConnect. Pete

FSUIPC's list is actually made from the internal list in P3D, contained in their "Controls.dll". FSUIPC doesn't invent them. The names can be obscure at times. In this case they are really not particularly obscure. There is a document listing them all provided in your FSUIPC Documents subfolder, in the Modules subfolder -- as pointed out in the Installation document. If you search this list for "View" you'd find, among many, others these NEXT VIEW PREV VIEW NEXT SUB_VIEW PREV SUB_VIEW I think one pair is usually assigned to A/Shift A and the other to S/Shift S, but I'm not sure which is which offhand as I never use the keyboard. In general, if you want to find precisely which FS control is being used for any action, button or switch, just go to FSUIPC's logging tab and enable Event logging. Then when you use it it will be logged with both number and name. To make it easier you can even select the "console log". Then, if you (temporarily) run P3D in Windowed mode, you can view the Log file in real time in its own Window. Pete

Because you are allowing longer for the Event to occur, so there's more chance of it occurring and FSUIPC trying to reenter the Lua interpreter whilst it is already running. No, because I never had any reason to suspect anything else would ever enter the Lua interpreter in the thread I created specifically for it. I don't have a clue how to tell if something has done. Maybe it is possible, maybe not. If the DLL author has a clue I could try protecting things my end, of course Okay. Thanks. I'll take a look. That is only because the sleep applies to the whole thread. the thread is suspended till the end of the sleep. no events are checked by the thread until the sleep ends. I've no idea at present how my part of the thread code can check that something else hasn't already called the interpreter in the same thread. Maybe I can do something like check it's internal stack memory position, if I can find it. Or place some sort of unique value (a generated GUID) on the stack and see if it is still the top item. Sounds a bit dodgy though. Pete

No, it can use two different email addresses, but must have the same name. Pete

After sleeping on it I awoke with a little more clarity of thought (though re-reading it I see it actually might be more cloudiness of thought!) I think that it is likely that the saitek DLL is using the Windows callback mechanism to allow it to instigate its callback, in the same thread as the Lua plug-in. Windows will be seeing to the preservation of registers and stack whilst the callback is in operation, and resume that once the called-back function exits. However, I think there must be some sort of clever mechanism programmed to prevent the said Lua plug-in being "called back" whist it is actually running. Because the Lua stack and so on is NOT the machine-aided stack maintained by the Windows mechanism, but its own data structure. The only safe time for the Lua callback function to be called is whilst an event is being awaited. That is probably why it doesn't work if you do not use events. However, since you find it crashing when the event occurs "at the same time" (really meaning, probably, just before, very close in time -- they cannot happen actually at the same time), I suspect this means it happens just AFTER the FSUIPC code has made the call into the Lua interpreter to execute the event function. So the problem is likely a defect in the way the Saitek DLL is somehow detecting when it is safe to execute the callback. I've no idea how it would tell that the Lua thread is engaged inside the Lua interpreter, but it would seem that whatever method is used it is not foolproof. This raises a question, though. It this is indeed what is happening, and the plug-in has to use events for it to work in the first place, then how would it ever work without danger of a crash for any plug-in using it? One must suppose that others are using it, and that it has been tested -- so what is different about the others? Or do they only use some more predictable event, like event.timer, which is somehow detected by the DLL? To investigate that you could try one more alternative -- a timer event instead of an infinite loop, reading and testing the offset each time. Pete

Hmm. Even with a sleep included? In what way didn't it work? I assume it doesn't crash. Does it just not get any of the callbacks? Without understanding how it works I really can't explain that. Yes, please. I'd be most interested. Pete

Actually, after having a long think after I posted the above reply, I realised that I don't really understand how callbacks, such as the one you have, actually work. I must presume that the callback function is executed in the same thread as the rest of the plug-in, the one FSUIPC or WideClient specifically created for it. If so then since execution of a thread can only take place once -- i.e not in two places simultaneously -- the execution by FSUIPC of its scan for events and its ultimate call to the event function when one occurs -- must be suspended whilst the callback function is being executed. Therefore, if this logic is correct, you can't actually get both happening together. The "stack" we are talking about for Lua is not the normal CPU processor stack, of which there's one per thread, but its own data area storing all sorts of things including variables, functions, and so on. Where my mind rather boggles is trying to work out how all that is handled when the Saitek callback is called after FSUIPC has effectively exited the Lua program part altogether, pending the event. I'm getting rather old for all this complexity. These things used to be easy, but I have fewer working little grey cells these days (blame the beer and wine! :cry: ).I think we might need assistance from the clever chap who wrote that Saitek DLL. Do you have contact with him? Have you asked for his help too, already? Pete

I suspect that the problem is because the Lua interpreter is actually not running whilst an event is awaited. The Lua plug-in is effectively "dead" until revived by the event occurring. The thread itself is still running however, checking for the event conditions. As soon as the event occurs, my code in the thread is attempting to call the event function. I assume the code creating the callback itself must be running in a separate thread, otherwise effectively FSUIPC would not be able to check for its events -- that thread is running in the callback checker. So, when that separate thread then attempts to call the specified callback function, in my thread, then no matter which comes first, callback or event, things become very precarious. Who is now controlling the code flow? How is the Lua interpreter going to deal with re-entry when it is already executing? I can see why the stack could get completely corrupted. I don't see any way out of that. As far as I can see it's a design impossibility (or certainly a designer's nightmare!). It would have been better for that Saitek DLL to signal its intervention with your call supplying an offset to be changed so that you could have an event based on that (as well as the one you have). FSUIPC processes one event at a time, so they would be properly sequenced. Unless that DLL can be changed I suggest your only recourse it to avoid using the event and instead use an infinite loop, checking your event offset each time. You'd probably need to include an ipc.sleep call for performance reasons, but at east the Lua interpreter is still active though the thread be suspended. BTW please update your FSUIPC. I don't support old versions. Current is 4.949f. Pete

Right. So it seems that download didn't complete, or went wrong in some way. You might need Steam support. Pete

Please always post support questions to the Support Forum. The .Net DLL subforum if for programming questions when using Paul Henty's .NET DLL. No old version of FSX-SE, or no old version of FSX? If you had a previous version of FSX, how did you uninstall it? FSX tends to leave traces in the REgistry if you aren't careful. Evidently the installation of FSX-SE went wrong then, because that only happens if the registry entries for the sim aren't correct. If FSX.EXE was missing then the FSUIPC installer would not have accepted the path you entered (it does check). The fact that you got that message means the Inmstaller most certainly did see FSX.EXE at that location. What told you that FSX.EXE was missing? Evidently either Steam had not finished installing before you attempted to install FSUIPC, or some checks the Steam App applies showed that it did need re-downloading. Why not? I should think allowing Steam to finish installing, or even re-installing, would be the most sensible and best way to solve your currently bad installation. BTW there is an FSX/FSX-SE forum on AVSIM which would be able to help more fully with general FSX/FSX-SE questions like these. Pete

No, not without more information! I can't even envisage what you are talking about with the little you say I'm afraid. First please state version numbers -- FSUIPC and WideClient. It would of course help to know where this "callback" function is, because my Lua libraries don't have anything like one -- events are the closest to callbacks. And why not show the actual Windows crash event data -- at least that shows also the module name and offset within it? That's always useful. I am also confused by the mention of "WideClient or FSX". Where is this lua plugin running, and are you getting assorted errors on both PCs? Finally, do the errors logged in Lua correspond to the time you get the crash and if so where? Maybe you need to show the log too, along with the Lua program it corresponds with? Pete

Sorry, there's no way I'm going to be writing special programs for all the assorted hardware and software applications out there. This is why I provide the documentation and Lua references for user's to help themselves, and the SDK to enable programmed applications. In any case the Garmin software might already include facilities to read from Garmin GPS devices. If so you may be able to use a program which emulates two linked "virtual" serial ports, as documented in the read-me for GPSout, and mentioned in the Download Links subforum above. That's how I used to link FS to Jeppesen's FliteMap (before cheaper and easier alternatives such as Aivlasoft's EFB came along). BTW that website you link to contains very much out of date and unsupported versions of much of my software and should certainly not the the prime reference. I expect much of the other stuff there is way out of date too. Pete

Note that sometimes this entry will contain only the changed modules. You will need the main release installed first. The best place for those is fsuipc.com The FS modules here, when supplied without Installer once extracted need copying into the folder containing FSUIPC itself. For versions before FSUIPC6 that will be the Modules folder within your FS or P3D installation. Otherwise it will be wherever you selected at installation time -- by default your P3D Add-Ons folder in your Documents. Please note the format here. The links for all the updates are listed first. For interim releases notes about changes are often listed separately, below that. Otherwise refer to the History or Changes document within the package. FOR MSFS Install FSUIPC version 7.4.18: Install FSUIPC7 FOR Prepar3D 4, 5 & 6 (64-bit) Install complete FSUIPC version 6.2.1: Install FSUIPC6 This is the 64-bit version and is valid for Prepar3D version 4 from 4.3, and versions 5 and 6. PFCFSX driver for FSX, FSX-SE and P3D, and PFCcom64 driver for P3D versions 4 & 5 and MSFS (FS2020) PFCFSX+PFCcom64 -- minor updates for FSX -- 64-bit version for use with P3D 4 & 5 included -- Now updated to operate with FSUIPC7 as well. -- 5.051: Fixed initialisation timing so that connection check option works with FSUIPC7. -- 5.060: Fixed potential crash with access to FSUIPC's EventList (for button assignments) -- 5.061: Fixed problem with Key entry for button assignments -- 5.062: fixed problem sending keypresses to P3D PFC HID device driver for FS9, FSX, FSX-SE and P3D PFCHID includes PFChid.DLL for 32-bit sims, and PFChid64.dll for P3D4 , P3D5 and MSFS (FS2020) PFChid64.DLL version 5.143 is compatible with more recent Cirrus 2 consoled, including radio stack. FOR FSX, FSX-SE and Prepar3D Install complete FSUIPC version 4.977 Install FSUIPC4.977 for FSX, FSX-SE and Prepar3D versions 2.5, 3.0 - 3.4 (32-bit only: all versions to date of release). Please be sure to read the IMPORTANT note included in the ZIP. Changes since 4.96 are now included in the History document in the FSUIPC Documents folder supplemented by the Changes document in the ZIP. If you already have a correct installation of FSUIPC4 you can download just the replacement DLL FSUIPC4977.zip and copy the DLL from within the ZIP directly to your FSX or P3D Modules folder, overwriting the previous version. It includes a fix for a crash caused by a spurious XBox 360 controller entry being added to the registry when in fact no controllers are connected at all. This seems to be occurring with the latest versions of Windows 10 on the Surface Pro, in particular, but may occur on other systems. This version supports the FSX-SE Beta build 63003, but with restricted operation. Please see the IMPORTANT notes for FSX-SE users included in the ZIP. It also allows the SimConnect.DLL in the FSX folder to be used if it is installed there by the latest non-beta installer (version 62615). That location appears to be the new alternative to using the troublesome WinSxS methods. Note that FSUIPC4 is not supported on any version of Windows before Windows 7, and will probably not work on such versions in any case. FOR ANY FS or its DERIVATIVES (but use on FS2004 and before not supportable) WideFS version 7 - including WideClient 7.160 and WideCloser 1.0.2 Full release including documentation. -- signature removed -- See WideClient changes below. WideClient 7.160 -- 6.999x adds "ReconnectMinutes", a facility to automatically reconnect periodically. -- 6.999y fixes a bug in event.offset for strings which now truncates the string length to <= 256 -- 6.999z2 adds Lua global sharing over network (with FSUIPC 4.958 or later) -- 6.999z3 adds more facilities to the Lua "wnd" library - title, show and hide. (See latest Lua docs) -- 7.14 includes a variety of minor changes, with the only one likely to be noticed by most users being that ButtonScreens are fully drawn on connection even on current Windows and video driver versions. -- 7.141 fixes a possible "DATA REQUESTS OVERFLOW" problem with clients -- also: includes improved Lua ext library functionality, more reliably finding the top level Window in an application so that messages and state changes will take effect. -- also: supports 64-bit applications using the 64-bit "64-bit External User kit for C/C++" available in the Useful Additional Programs thread. -- 7.145 adds new support for Lua "textmenu" plugins, with a package of such plug-ins included. -- 7.146 fixes a small bug in the Lua TextMenu local File display option, and includes improved plug-ins -- 7.151 has some minor improvements incorporated. -- 7.153 fixes possible hang when lua function ext.text is used with a null Window (i.e. width, height both zero). -- 7.154 fixes a problem with text wrapping for the Lua event.textmenu text file display. -- 7.156 fixes minor errors in the TextFile facilities in event.textmenu. -- 7.157 adds protection against stack clashes with heavily used ipc.set and ipc.get use in plug-ins. -- 7.160 build environment update, no functional changes FOR FS9 AND EARLIER ONLY Install complete FSUIPC version 3.999z9b Install FSUIPC 3.999z9b for FS9 and before -- For changes see the History document in the full install update. Note that FSUIPC3 and WideFS6 are no longer supported. But a free Registration is provided: Name: free user Email: fsuipc@free.com FSUIPC3 KEY: Y8ZG SUWH TIQ2 WideFS6 KEY: IUT7 DBMK 1EU1 FSUIPC version 3.999z9b only, for those with 3.999z1 or later already installed FSUIPC 3.999z9b -- Fixes an ancient and obscure bug which nevertheless can crash FS on loading with certain INI file arrangements. -- The z9b update merely enables Registrations purchased after the end of 2015 (and until FSUIPC3 was retired from sale) to work. PFC driver version 2.41 for FS9 and earlier PFC 2.41 (ZIP includes documentation) For further products, please see fsuipc.com.

FSUIPC version 4.949f is released, with Installer (because of the Lua documentation update) and includes the facilities you requested, ext.hasfocus including the handle and process name variants. Pete

FSUIPC 4.949f is now released, with Installer (because it includes updated Lua documentation), and this corrects the problem with the spurious button 0,0 assignments.. Pete

Sorry, I've no idea. If the device can be linked via serial cable (or a USB cable pretending to be a normal serial cable), and the device can be set to read standard NMEA sentences and take those instead of any internal GPS readings, then yes. But you need to refer to the Garmin documentation. All GPSout does is send out the data on a COM port using the speed you specify and with the specific sentences you specify. The rest is entirely up to the device at the other end. Pete