Pete Dowson

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.

Can you please enable SimConnect logging (via a SimConnect.INI file in the P3D documents folder -- see the FAQ subforum thread entitled "FSX HELP: Logging SimConnect". Then find the log produced and show me the first 30 or 40 lines. Are the other three DLL's being loaded okay? Just in case it is one of the other Modules you are loading which is somehow stopping FSUIPC being loaded, please also try re-naming the DLL.XML file (as, say, DLL.XMLX) and re-running the FSUIPC Installer so it makes a new one with only FSUIPC loading. This is onlyas a test, of course. Oh, and please look in the ProgramData P3D folder, where the SCENERY.CFG file it. Check that the DLL.XML you might find there isn't duplicating any of the entries in the AppData one you got the above one from. Pete

Hmm. There's something really really strange with your system. That multi-line mechanism is used by Radar Contact (among others) for its menus, and has worked well for many many years (back several versions of FS -- FS2000 was it, or 2002?), with exactly the same code. Also, I see now that you find 4.959 and 4.962 act the same, which of course they should because they use the exact same code. Ah, so you still mean it only happens once per session? I'm not sure of the relevance of that remark. Sorry. I'll think on it. I can't do anything till tomorrow in any case. Yours is the other report of anything like this, even over all the years that this display facility (not just the Ask function, that is only one user of it) has existed. I can't help thinking that there's something odd about your system somewhere. Pete

Unless your string has multiple lines (i.e. includes newline or return characters in it, then that's not using the same facility. Have you tried a multiline string? If not, please do so. ("\r" or "\n" will start a new line). It must be some timing oddity in FS. There's no difference between 4.959 and 4.962 in this area -- excepting likely the timing of things, which sounds rather critical in this case. The calls are just that, calls to functions in the Sim. FSUIPC doesn't have any control over what it then does. Strange. Obviously something gets speeded up (or slowed down). I think maybe the first time, the window is actually being created. The later times it is just being "unhidden". Do you mean they all have the weird delay/wait on the first time, separately, even in the same session? If so, since they will all be using the same window, that makes my immediately previous surmise incorrect. I really can't do much without being able to reproduce it. I suppose I could try calling the same sim function twice each time on the assumption that the first time didn't work, but that seems rather extreme. If I do something like that, do you want to try it? Pete

That just reduces traffic being set according to values in the traffic files. There's nothing built into FS or P3D which actually deletes traffic, except when they get jammed and can't move for a while, or are forced to do go-arounds several times. Pete

Sorry, I don't have any PMDG aircraft, even for FSX, let alone P3D. Ask in the PMDG and P3D forums. Pete

Even more intriguing, not to mention 'strange'. If I set a value to a Global "HOBHR4", the ipcInit plug in still crashes with a nil value for it. So it must actually set it to nil deliberately, before trying to do impossible arithmetic with it! ... No. I just put traps in FSUIPC where the Lua "ipc.set" and "ipc.get" functions ar processed, and ipcInit calls neither. So it isn't actually trying to get that value before using it. Curiouser and curiouser. I can't really do anything else. I think you are in the hands of your panel builder support. But do try the alternative methods of assigning I mentioned, just in case. Pete

As a matter of interest, and curiosity, I installed that "ipcInit.lua" plug-in into my P3D modules folder. Being named "ipcInit" it gets loaded automatically when the system is started -- it doesn't even wait till the sim is "ready to fly" (as the ipcReady.lua would have to), so I had to enable Lua debug/trace mode beforehand ("DebugLua=Yes"). This isn't very informative, because, being compiled there's no logging of the actual commands which are being executed. The log you get, in the case of any aircraft I may be using at least, is: 30811 Running in "Lockheed Martin® Prepar3D® v3", Version: 3.4.22.19868 (SimConnect: 3.4.0.0) 30811 Initialising SimConnect data requests now 30811 FSUIPC Menu entry added 30811 LUA.0: beginning "E:\Prepar3D v3\Modules\ipcInit.lua" 30811 LUA.0: ipcinit_SOURCE.lua:10 30811 LUA.0: Global: ipcPARAM = 0 30811 LUA.0: ipcinit_SOURCE.lua:11 30811 LUA.0: ipcinit_SOURCE.lua:12 30811 LUA.0: ipcinit_SOURCE.lua:13 30811 LUA.0: ipcinit_SOURCE.lua:14 30811 LUA.0: ipcinit_SOURCE.lua:15 30826 LUA.0: ipcinit_SOURCE.lua:16 30826 LUA.0: ipcinit_SOURCE.lua:17 30826 LUA.0: ipcinit_SOURCE.lua:18 30826 LUA.0: ipcinit_SOURCE.lua:19 30826 LUA.0: ipcinit_SOURCE.lua:20 30826 LUA.0: ipcinit_SOURCE.lua:21 30826 LUA.0: ipcinit_SOURCE.lua:22 30826 LUA.0: ipcinit_SOURCE.lua:23 30826 LUA.0: ipcinit_SOURCE.lua:24 30826 LUA.0: ipcinit_SOURCE.lua:25 30826 LUA.0: ipcinit_SOURCE.lua:26 30826 LUA.0: ipcinit_SOURCE.lua:27 30826 LUA.0: ipcinit_SOURCE.lua:28 30826 LUA.0: ipcinit_SOURCE.lua:29 30842 LUA.0: ipcinit_SOURCE.lua:30 30842 LUA.0: ipcinit_SOURCE.lua:31 30842 LUA.0: ipcinit_SOURCE.lua:32 30842 LUA.0: ipcinit_SOURCE.lua:33 30842 LUA.0: ipcinit_SOURCE.lua:34 30842 LUA.0: ipcinit_SOURCE.lua:35 30842 LUA.0: ipcinit_SOURCE.lua:36 30842 *** LUA Error: ipcinit_SOURCE.lua:36: attempt to perform arithmetic on global 'HOBHR4' (a nil value) It seems it never actually sets Global variable HOBHR4, at least it doesn't on its own. Are you sure there isn't another Lua file in your Modules folder which is also being run? Presumably one of those lines above (10-35) checks the name of the aircraft you load, or perhaps the existence of a specific L:Val, the if it matches what it wants, sets a value to that Global -- but if so, it must do that all in one line because there's no "jumps" (no discontinuity in the lines numbers showing the execution order). At present I just cannot imagine what this plug-in could do to nullify the action of your assigned axes, which you say work fine when this plug-in is removed. I might try creating the global HOBHR4 in another Lua to try to stop yuor plug-in crashing. Pete

I'm sorry, but there is no way simply deleting AI aircraft will affect anything else. It is merely a simple call to a built-in P3D (and FSX) function. If P3D messes other things up when other objects are deleted then you need to report it to L-M. The same option is used by the FSUIPC Traffic Zapper and by all of the several AI traffic management utilities around. There's no magic and nothing special, it is just faster at doing it because it is built into the process, not an external process. BTW 4.962a is available in the Download Links subforum. But there's nothing changed regarding aircraft deletion. Pete

Have you ever try assigning to the more usual FS contorls in FSUIPC instead of "direct to calibration". Then try both with, and without, calibration. There are also other options which you can try, but one step at a time. If you are in the habit of deleting everything every time you update FSUIPC I am not surprised things change. You probably made other changes now lost. And I have STILL never seen any log with the data I requested. I think it is a bit pointless me trying to help if you don't do such a simple thing, now requested at least two or three times. If you don't want me to help any more, so be it. Pete

Then there's some thing badly wrong with that plug-in. I can't check it because whoever wrote and supplied it has compiled it. Usually such plug-ins are readable source.. Is it actually from A2A or did you get it from someplace else? This "SimPanel" company? The fact that it crashes when you load a different aircraft shows it is in error in the first place. I think your only recourse is to ask the folks who made it. Pete

I wonder if that's something to do with that Lua plug-in, which failed when you ran a different aircraft (see earlier post). Deleting everything in the Modules folder would have deleted that. It wasn't one I recognised. Where did it come from? No, there won't be. Show me that "rogue" plug-in if you can find it (file name ipcinit_SOURCE.lua), and see if you can find why you installed it, or what did install which also installed it. Pete

The only thing that would do is restore the INI file to default. You did that before, you said. What does your new one look like? Pete

Your log is cut off at the very point you enabled the axis logging! Why? What's the point of showing that to me? The only odd thing there is this: 4511407 Aircraft="Beech Baron 58" 4512032 *** LUA Error: ipcinit_SOURCE.lua:36: attempt to perform arithmetic on global 'HOBHR4' (a nil value) What is that bad Lua plug-in? I suspect the problem is that the A2A aircraft does not heed the controls sent by FSUIPC. Pete

Nor me. although if you've only tested it with an add-on aircraft, the A2A, it may just be because that aircraft has bend coded to only accept the regular axis controls at the normal SimConnect priority level. So, make sure you load a default aircraft. Then in FSUIPC's logging tab, enable the axis logging. OK out and use the aileron -- perhaps just one movement from centre to full left, then full right, then back again. See if it works in the default aircraft, and if not then the resulting log should show what is going on. Pete

If the two PCs are so close to each other, you can connect them with a short cable. The modem connection would only be used for Internet connection -- WideFS doesn't use that. If you don't have two Ethernet ports on the connected PC, just use a cheap switch. BTW, what exactly is "cute" about my question? Pete

If you can see them and calibrate, then they are sent on to P3D. There's no way the cannot be. You must disable controllers there. Assignments are not really relevant, it is whether they are enabled or not. Your assignments are very odd. You have these devices: 0=Saitek Pro Flight Yoke1=BU0836A Interface2=Saitek Pro Flight Cessna Trim Wheel3=Pro Flight TPM System4=Saitek Pro Flight Rudder Pedals but you assigned your aileron and elevator (for the "Piper Pa-28-180 Cherokee 4" only) thus: 0=1X,256,D,1,0,0,0 -{ DIRECT: Aileron }-1=1Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- In other words, to the Bodnar board, not the yoke. Why is that? The only other assignment is to the Aileron, for all other aircraft: 0=1X,256,D,1,0,0,0 -{ DIRECT: Aileron }- Pete

Sorry, not that those logs are relevant now, but they would be of no use anyway. I see I made a typo in the instructions. The lines to add are: Debug=Please LogExtras=x20 Pete

What do you mean by a "new keystroke window"? Do you mean a new menu? I use this facility all the time with both GSX and ProATC/X and have never had a problem yet. But then I use FSX-SE. There were quite a lot of problems with the SimConnect menu in P3D earlier on. How are you responding with the menu selections -- what do you use for that? Oh, and why aren't you using the current version of P3D (3.4.22) which odes have more bugs fixed? The text menu intervention really just sends the menu when it captures it -- via a hok placed into the P3D Window.DLL. It cannot miss one (as the log would show if you looked), but maybe your connection to your Client isn't good, or the PC being used is loaded with other things? I can't really say. You can check (in the FSUIPC logs) to see the menu test (or at least the first part of it -- menus are several separate lines), and you can also enable some data logging in WideClient. And there's no way anything I ocan do which will ever crash ProATC/X. That's something else you have going on there. I'd check on their Forum if I were you. Maybe it can't handle all the SimConnect events you are throwing at it. No, it won't appear o the server -- because that never needs a response it can be suppressed there. I can't suppress the menus because then SimConnect never sees the selection you make. If you are getting intermittent results with that it does rather further indicate a WideFS transmission or reception problem. The intercept facility is not selective, sorry. You don't need to display those but you can't stop them being intercepted and transmitted. It cannot know or be aware of anything FSUIPC and WideFS or the lua script are doing. It is an entirely separate process. But if you are using it on the same PC perhaps this is part of the loading on that PC stopping the screen updates. No. I have used it quite a lot with P3D, but I'm now back to FSX-SE because it performs so much better with the amount of AI Traffic I like. And I've used this facility for a couple of years now, with both GSX and ProATC/X, since they came out. I'm sure you have a local problem, and probably on that PC. You are using a wired network link, I hope, not wireless? I always have to advise against using wireless connections for WideFS. They never work reliably enough. Pete