Pete Dowson

Wow! Really? That's very kind of you. Paypal to petedowson@btconnect.com Pete

Please ALWAYS post support questions to the Support Forum, not to places like the FAQ subforum, which is a reference place for others to find things. I've moved this one for you. Sorry, there is almost no useful information here. You are programming a Key press to do something in FSUIPC's Key assignment tab? To do what, exactly? What is this "input field" you speak of, where you expect a "K" to appear? Why would a "K" appear anywhere in any case if you have assigned it to do something? You really do need to be much more explicit. i.e -- What is "K" assigned to do? An FS or FSUIPC control? Which? Or something else? -- How is your program actually sending it? Via a Windows facility, via some FSUIPC controls? What? -- What is supposed to happen when the "K" is used? I also need ALWAYS to know things like version of FSUIPC (the number, exactly), and the version of P3D. Have you tried using FSUIPC's logging facilities to examine your problem? Pete

I've looked at the code, and I think I might have messed up the offset for the second 777X data area when I added the 747 data, which is also wrong. I'm just fixing both now. If you write to me at petedowson@btconnect.com I'll send you a revised version (tomorrow) which I'd like you to check for me and let me know. Pete

So others, in the same data block, are okay? FSUIPC just receives the entire data set in one block from SimConnect. It doesn't interfere with any of it. Because the data was too large for the space, it just splits it into two parts: 6420 - 65EB and 6C00 - 6CEC If something was going wrong, the whole of one or the other would be wrong. I've no idea what all those crossed out lines in your last message are about, but there's nothing there about any other 777X offsets, so which other 777X offsets have you checked? As I said, I can't check here. I've never had the 777X. I need to know if all the data is wrong, or just the second part, or only isolated values. If it is just isolated values that must be some other interference, because the data is moved en bloc from the memory supplied by Simconnect. Pete

Sorry, I don't know what is changed. I recently added the PMDG 747 data, mapped to the same locations, but that would not conflict as you can only have one aircraft loaded at a time. I have not knowingly changed the 737NG or 777X offset mapping in the process of adding the 747 ones. I don't have any PMDG aircraft, so you'll need to tell me. Are all of the PMDG 777X offsets unpopulated? Can you check as many as you can please? Pete

Is anyone still interested in checking the PMDG 747 mapped offsets? I didn't seem to get the emails I expected. If interested, email me please petedowson@btconnect.com. Pete

For anyone interested in trying a new option and letting me know how they get on, download the interim update FSUIPC4962c_TEST.zip This allows you to set a separate preference for deleting excess traffic at your planned airports of Departure and Arrival. (Sorry, not alternate as well at present, but I might consider adding this if folks do actually use it enough and the facility appears to be useful). The new parameter, in the [Traffic Limiter] section of the FSUIPC4.INI file is PlannedAirportsPreference=50 As with the others, the default is 50, but it will be set the same as a previously set GroundPreference value initially. For this to operate fully you need to have a plan loaded in FSX/P3D. Since it doesn't know your planned departure until the plan is loaded, it will initially assume that the nearest airport IS your departure airport. This will be confirmed or changed when the plan is loaded. The "GroundPreference" value determines the probability of excess aircraft being deleted from any airports within FS's "reality bubble" EXCEPT your departure and arrival airports. In that case it is this parameter which decides the probabilities. So you could, for example, set the GroundPreference to 75 to get rid of more ground traffic at other airports, but put this one down to 25 to ensure more traffic at your planned airports. When you first run FSUIPC with this new feature, it will set the added PlannedAirportsPreference value to the same as the GroundPreference, so that nothing will change unless you change this or the other parameter. It is tested here but I'm not sure yet how effective it is for real flights,, which I've not got time for at present. Keep your current FSUIPC4.DLL to return to in case of problems, and let me know how here you get on, please. Pete

I think you need to report this to L-M. Have you already checked through the crash reports already there. L-M will probably ask you to test with no add-ons at all first, then add things back bit by bit. I think you should do that in any case, before reporting on that Forum probably. The first Windows crash above is in something called "MicrosoftEdge". I don't think that's anything to do with P3D, is it? Maybe it's another indication of something else wrong in your system. Pete

Did you fully uninstall the previous device? Otherwise registry entries will still say that the old one is still there, and trying to read non-existent devices is likely to give problems. Go t the Control Panel - System and uninstall from there as well as uninstalling any programs associated with it. I see that one of your devices is constantly re-connecting. This: 209094 ***** HID USB device reconnected: re-initialising FSUIPC connections occurs many times, each time immediatley after the other, during start up. That's not good. FSUIPC isn't polling for new devices, it simply asks Windows to notify it if any are freshly connected. However, this in itself should not make P3D crash, though it may hang it. Unfortunately, though you say you found the Windows crash details you show none at all, so there's nothing to point out which P3D or System component actually crashed. Pete

Oh dear. That's nothing to do with ipcBin files. That just forces a Pause when an aircraft crash (not a Sim crash) is detected, to stop it auto-reloading the flight!!! The option controlling the ipcBin file use is "Reload FSUIPC data" which defaults to "Never". Please don't just enable options without knowing what they do. Leave them to default. I suggest you do have a look at the FSUIPC User Guide some time. All this is described on pages 17-20. Pete

Aha! The ipcbin files are optionally produced and reloaded. They store the complete state of all FSUIPC offsets, which includes the 3380 / 32FA ones. Folks normally only use those when they are using complex cockpit accessories, like Project Magenta, and want to be able to continue a flight from where it crashed or was aborted without having to set the whole cockpit up again. Unless this is what you need I suggest you turn off the options for this on the Miscellaneous tab in FSUIPC options. I haven't heard of anyone using those options for many many years. I used to, but it doesn't really help with ProSim (I changed from Project Magenta a couple of years back). Pete

FSUIPC 4.961 is not supported. It was replaced by 4.962 six days ago. Please ALWAYS check for new versions before reporting a problem. it only wastes both our times. Pete

Oops. Sorry. My error. I clciked on your link which downloaded it to a folder on my PC, then I picked up the wrong file!! :-( I was rather distracted, with guests here today and trying to do several things at once. Please, unless files are really very long, just paste their contents into the message. Use the <> button to enclose them for tidiness. I've just done that with your last message, above, so you can see what it looks like. If the text is very long, it puts scroll bars on the right rather than showing it all at once. I agree, there's no Lua plug-in being run by FSUIPC, and no display sent either. I have no idea where your FSX installation is getting that from, sorry. Pete

You've got something wrong then. It's a built in function in FS and P3D. What, renaming the DLL.XML? No, that is wrong. P3D ALWAYS loads DLLs and EXEs from both files. Pete

As shown in the Log, you are still runningyour Ask application which is most certainly still in the Modules folder: 370830 KEYDOWN: VK=65, Waiting=0, Repeat=N, Shifts=0 370845 .. This key is programmed in FSUIPC4 'Keys' options 370908 KEYUP: VK=65, Waiting=0 370908 LUA.0: beginning "E:\Steam\steamapps\common\FSX\Modules\Ask.lua" 370955 LUA Asks: " Enter Distance to Move A/C in NMs (0-500), or just the ENTER key for 0 NM * to Exit " 374683 LUA Reply: "a" 374683 KEYUP: VK=13, Waiting=0 Pete

Where's the logging I suggested? It's no use saying these things without presenting information. There's absolutely no storage or memory of Lua actions or display scripts. There's no where for them to be stored. You've got something else going on there and it's only unexplained because you won't do the diagnostic actions I suggest. Pete

No, not at present. It complicates what is currently a very simple facility. There's already an utility program which can do that. The amount of programming additions just to do that would actually exceed the amount needed to implement the facility in the first place. If I thought it would be wanted to go that far I wouldn't have started implementing it. It was to be efficient and simple. And such an addition would also tend to defeat the object, which was to limit the effect on performance of a lot of traffic. Deleting traffic far away or out of sight really doesn't actually help that much. It is precisely the reduction of nearby traffic, at the airports you are at, which helps. Just reduce the Ground parameter. When it is zero is doesn't even consider deleting ground traffic. I'm sure you can finf somethnig to suit you. Pete

If the display is from a Lua plug-in then you most certainly have a Lua plug-in being executed. There's no way any such thing will be produced by a flight file and anything else like that. The displays are howver produced by lots of other programs, of course, as well as through normal things like Shift+Z to display coordinates, frame rates and so on. It is the same display mechanism. No, no way. Enable Button/Key logging and Lua Debu/Trace options in the Logging tab in FSUIPC.It will show you what Lua plug-in is being run, if any. Maybe through an "Auto" section you've forgettoen about. Pete

There will almost certainly be a crash report, then. And if there was no log produced (and the SimConnect log actually says it wasn't even loaded), then it most certain was not FSUIPC which crashed. At least on loading. If there's a Windows crash report for it, then I needed to see it -- check the Windows Event Viewer. If there's no crash report, then it didn't crash. Yes. That is why FSUIPC 4.962 followed on from 4.961 so quickly. There was a bug in 4.961 which caused crashes ON EXIT from FS (unless you disabled the OOM check). It is those end of session crashes which cause the warning next time you load. There is a writeup about this in the change notes included in the release. It is always best, before reporting a problem, to see if has been fixed first. Pete

"Throws an error"? Or do you mean it gives a warning where you have the options to run it or not? There's a big difference. You should try running it -- it may just be the annoying FSX SimConnect trust bug (which does NOT apply to P3D!). It might take several attempts. If there is really an error then I need to see the details, the actual crash report with error type and module offset. However, the current supported version is 4.962, so please update first! If an FSUIPC4.LOG file is produced before a crash I need to see that. The SimConnect log isn't much use except possibly to show that, in fact, FSUIPC did not run at all (therefore it can't crash), so it is probably just the trust bug. That log also shows you have the most DLL's loading in FSX I've ever seen. I count 17 actually loading. Your DLL.XML file is in error in any case -- there are THREE attempts to load MV_WXM.DLL (the second two fail, of course!). Also it looks like you have Active Sky installed, but that vital component it needs, as_btstrp.dll isn't listed as loaded. Pete

Well, maybe 100 mSecs is not enough delay. But the trouble with a large delay is that it could result in missing keypress responses when the user does actually see the first. I've increased it to 1 whole second, mainly just out of curiosity. Download FSUIPC4962b_TEST2.zip Pete

This shows it is timing related. I've checked the code -- step for step identical between 4.959 and 4.962. Not only that, but whereas the Lua display facilities use hacked calls direct into FS/P3D code, both the Ask and all 3380/32FA requested displays, single line or multiline, use regular SimConnect facilities -- no hacks, no strange code at all. The SimConnect function is "SimConnect_Text". So the problem looks like it may be a bit of a Win10 incompatibility with FSX's SimConnect coding. I'm afraid you won't get that fixed in FSX. I suppose there's a small chance it would get fixed in FSX-SE if DoveTail games can be made interested. I've tried it on my one and only Win10 PC (a Surface Pro, mainly only used to keep up with emails and so on, on the move), and I don't get your results on that. Anyway, what I've done, for the present, and mainly to see if it works, is that on the very first call to display anything with SimConnect_Text, I repeat the exact same call 100 mSecs after the first. I've no idea whether it will help, but if you'd like to try it and let me know, download FSUIPC4962b_TEST.zip and let me know. My new PC came with Win10 pre-installed. I had so many problems. Regular utilities I depend on didn't work properly -- crashing now and then, and quite innocuous drivers I need for some of my cockpit hardware not working at all. After struggling for a week with the awful thing I cleared the disk and started again with Windows 7 Ultimate. I am currently universally on Win7 (except on my Surface Pro as mentioned above) and will be staying with Win7 for good now! Best O/S Microsoft ever made (XP was their second best -- I only recently updated three of the mini-PCs inside my cockpit from XP to Win7 because ProSim's display modules were updated and needed .Net Framework 4.6 or later.. Pete

Not a good idea, except as a test. Next time you run FSUIPC installer it will add to the one in the AppData folder, and then there will be a conflict. There may be something wrong with the DLL.XML file there. I can't see what offhand. Compare the structures of the two files. XML is very finicky, the slightest error can make the whole thing invalid. Didn't you try renaming and reinstalling FSUIPC, as a test, as I suggested? If that works then there's definitely either something wrong with the original, or one or other of those earlier DLLs being loaded is somehow clobbering the others. The SimConnect log I suggested would help work that out. Pete

There is no "4.96" or "4.692". The current full version is 4.962. The link in the Schiratti "Dowson page" always points to the current release. It is only the text which is not always updated -- it isn't my website and I don't have control over it, so it tends to only show the major numbers. There are too many intervening releases a year! As Thomas says, there are always update details in the place I can control, the Download Links subforum here. Pete

Unfortunately the Log with Lua is not really that useful at all, because you don't have the axis logging enabled for that one! See this: 219 LogOptions=10000000 00000001 for the "no lua" one, with this: 234 LogOptions=00000000 00000001 for the "with lua" one. That first "1" digit is the axis log option! Later you did enable that logging: 306328 LogOptions changed, now 10000000 00000001 306437 *** AXIS: Cntrl= 65786 (0x000100fa), Param= 50 (0x00000032) SPOILERS_SET 306453 *** AXIS: Cntrl= 65786 (0x000100fa), Param= 53 (0x00000035) SPOILERS_SET 331203 C:\Program Files (x86)\Lockheed Martin\Prepar3D v3\SimObjects\Airplanes\beech_baron_58\Beech_Baron_58.air 331406 Aircraft="Beech Baron 58" 331937 *** LUA Error: ipcinit_SOURCE.lua:36: attempt to perform arithmetic on global 'HOBHR4' (a nil value) 348718 LogOptions changed, now 00000000 00000001 but then changed aircraft soon after. Why? And why are you disabling that option afterwards? Better whilst investigating this if it was on from the start, as it was in the case of the "no lua" one. BTW do the axes start working immediately after the Lua plug-in crashes? Because it won't be running then. Or has it managed to do some permanent damage? Have you contacted the authors of that plug-in, to see what they say about this? Pete P.S. Again, you posted a log without the final close messages included (the With Lua one). Please don't cut it short.