Pete Dowson

Apart from updating to 4.957b, what else changed? Are you still on an old version of P3D? If it closes using the Close button, then why are you trying to KILL it instead? "KILL" replicates what Task Manager does when you use it to end the process. It is ruthless and saves nothing. Why aren't you using "CLOSE"? Not easily. I don't have that version. And honestly I don't think that's it. I can look at adding some extra logging to see exactly what is done to the process. But it is more important to know what version of P3D you are using, and if not the latest, why not. Most of the termination problems with P3D have now been eradicated and by default with P3D 3.4 FSUIPC now does close SimConnect. Maybe that timing difference has affected the way LINDA behaves. You can make FSUIPC avoid calling SimConnect close by adding CallSimConnectEnd=No Or, conversely, force it to by CallSimConnectEnd=Yes By default it depends on the version of P3D. Pete

Okay, thanks. I'll do some checking here. Maybe it's always been this way. Pete

Can you tell me which version of FSUIPC this is with, and show me the assignment you made, please (the entry in the INI will do fine)? Pete

Of course. Did you not yet follow the suggestion in the thread I pointed you to? That has worked in all other similar cases! I'm surprised you've not followed through yet! Pete

How do you "do it manually"? Does LINDA start up another program, or is LINDA.EXE always the process name and its initial Window stays opens? I suspect something else it stopping LINDA terminating, even forcibly, at that time. Is LINDA not written to terminate normally? Can it not close itself? The KILL parameter still certainly works fine. I use it every day. Pete

There's been no change whatsoever in this area. "RunIf" options can only operate IF FSUIPC did actually start the program. It sounds like the program was already running when FS started, so that the "if" operated and FSUIPC did nothing. If you are going to use "KILL" please use "Run1=" not "RunIfi=". It makes no sense with RunIf to have FSUIPC try to CLOSE or KILL it. Pete

Since Win8, sometimes USB devices get installed without a proper ID number being registered. The way FSUIPC works it needs a proper ID number assigning. Win 10 seems particularly annoying in this respect, and it seems to affect Saitek devices quite severely. There are also often problems where only half of the throttle movement is seen. All this is to do with Registry entries for the device. The latter problem, if you have that as well, is only solved by Registry editing and I think it is covered on the SAitek site. Win7 was and remains, in my opinion, the best operating system MS has ever produced. It's a shame they no longer support it (though it seems you can still buy it!). See the FAQ thread I referred you to. Pete

Well, nothing to do with throttles has changed in FSUIPC for years. So there's obviously no explanation in that direction -- maybe your throttle has packed up? So, you blame FSUIPC, not Win10? If you can use throttles in FS you can certainly use them in FSUIPC. But maybe changing to Win10 messed the registry ID numbering up for that device. Check the thread in the FAQ subforum entitled "Fixing joystick connections not seen by FSUIPC". Pete

I think Aerosoft's more sophisticated Airbus, like the PMDG 737NGX and 777X aircraft, need assignment to the regular Axis Throttle controls, with no FSUIPC calibration. Pete

You cannot, and you don't need to. It is not used as an email address, only as part of your identify for the registration code. Pete

Aircraft are only specifically selectable through the normal aircraft selection menus. You can load flights by writing the flight filename to an FSUIPC offset (see offset 3F00). So your best way would be to set up appropriate pre-prepared flights for each aircraft and select them that way. You can either write a program interfacing to FSUIPC to do this, or have one or more Lua plug-ins doing the same, responding to assigned buttons or switches. Pete

No, not directly -- only the order in which Windows ennumerates them when asked. I assume that's to do with it's USB scanning. The easiest thing to do is swap the USB plugs over. Pete

No, just address the servers specifically in the WideClient.INI files. Provide the ServerName or ServerIPAddrr parameters,and specify the Protocol to be used. Otherwise they will attach to whichever Server broadcast they see first. Pete

Yes, that's normal. The FSUIPC "no reverse zone" calibration will map that entire range to 0-16383. There's no way FSUIPC can send a negative value through that calibration. So the reverse is arriving along some other route. Right. And as I asked before, which actual assignment in FSUIPC's menu have you assigned to? That can be important too! i.e what is the name of the control you are using. There are at least 3 ways of assigning throttle. Also, as I asked before, have youactually disabled controllers altogether in P3D? If not then it will interfere. Finally, what aircraft are you using? Pete

-ve (negative) numbers are those less than zero. Subtract 1 from zero and you get -1 (minus one). You must have done some arithmetic in your school days? Forward thrust values vary from 0 (zero) for none to 16383 for full thrust. Reverser thrust is less than 0, varying from -1 to -4096 or thereabouts (the max reverse thrust is defined as a percentage in the Aircraft's CFG file -- 25% is normal, and 25% of 16384 is 4096). If none of the values shown in FSUIPC's tabs are negative then it cannot be FSUIPC which is making the throttles go into reverse. You either have some other assignment or something else interfering. So you've assigned throttles in P3D, not in FSUIPC? You have no axes assigned in FSUIPC? Pete

No. I was reasonably confident that this change would work around the difference in 3.4, so I prepared and now released this version as the current version. Thanks for the help in testing. Pete

What MSE documentation, or FSUIPC? Virus checkers aren't looking at text but program fragments. They have a library binary code sections which they compare to. They'd be well out of luck with FSUIPC because it is compressed and scrambled and only becomes code when it is finally loaded into FS's memory. Random matches could easily occur but be totally meaningless. Pete

And what is "the latest version" of FSUIPC? I always need version numbers. Folks have said "latest" and it has turned out they meant the "latest they had noticed" -- actually over a year ago! Version numbers are really quite easy to find and even easier to quote. And where assigned, which may be more important? If in FSUIPC, have you disabled controllers in P3D? And how are they assigned -- to which actual controls? Unless you have dual assignments, conflicting, it sounds like something is wrong with the throttle values arriving from the device. Reverse is only set by -ve numbers being sent to P3D, so somehow your calibration is doing that -- or more likely the values from the axis are going haywire. You can actually see the numbers in both the assignments tab in FSUIPC and the calibration tab, so did you look? Did you check to make sure they are smoothly increasing? So you've seen it before? How did you get it then? I've never heard of such a problem. Pete

I don't think b or c will fix any crash in Weather. I really can't deal with the other modules of P3D. If you have set "NoWeatherAtAll=Yes" then FSUIPC isn't going anywhere near that module in any case. So, there's no point in waiting. If you still get weather crashes now then you have some other corruption or problem in P3D I'm afraid. Pete

Further to my last test suggestions, before doing any of that, please ty FSUIPC4957b.zip. I've made some small changes to the way the FixControlAcceleration option works which I hope is more, er, secure! If that version proves okay, as I hope, I'll make it the current Release. Pete

The Weather crash is certainly not FSUIPC -- it is only happening when FSUIPC is present because it still causes SimConnect to read the weather. To stop that entirely you'd need to set "NoWeatherAtAll=Yes". Have you tried deleting the wxstationlist.bin and the .WX files? That's fixed such problems in the past. I'm hot on the trail of the FixControlAcceleration problem, which is more complicated. I've definitely concluded that it isn't at all realted to Weather. I hope to have it fixed today -- a version 4.957b or c. Pete

There is one other quick check you could do, please. Enable event logging. Do this by adding "LogEvents=Yes" to the [General] section of the INI file (to save loading FS, changing the logging option, and restarting it). Try both with the FixControlAcceleration off and on -- I'd like to compare the two resulting logs, please. Some non-axis events are evidently occurring immediately you start FS, because the place where it crashes if in that path, checking arriving non-axis events. Normally you'd get no such events until you operated a switch or keypress. I think some add-on aircraft send their own events, but you appear to be loading default aircraft. In fact one thing is a little odd there: 17722 C:\Users\Adam\Documents\Prepar3D v3 Files\Baron B58 NZAR Default Start.fxml 17722 H:\Program Files (x86)\Lockheed Martin\Prepar3Dv3\SimObjects\Airplanes\beech_baron_58\Beech_Baron_58.air Your default loading loads the Baron, but then, a minute or so later: 83757 H:\Program Files (x86)\Lockheed Martin\Prepar3Dv3\SimObjects\Airplanes\A2A_T6_Texan\t6.air So it isn't crashing immediately? You are going into the menu? This also suggests another test -- elminate any possibility that corruption in the loaded Flight file is doing it. Can you make the default something other than Baron B58 NZAR Default Start.fxml, or perhaps even temporarily rename it so it doesn't load? Thanks, Pete

Hmm. Strange. The pointer is definitely wrong. I can only think it starts off incorrectly and then doesn't get trampled on further. I'll think further on how to narrow it down. Maybe another interim update. Thanks for all that testing, but from my perspective you only needed to show it still crashed with those WX changes. Seems it isn't releated to WX corruption after all, so it is still a bit mysterious at present. You can just move them out of the Documents folder to test. Are they all the same as the original one? If not then, yes please. At least each different one. I'll get back to you. Pete

FSUIPC is fine. MSE is getting a false positive. You'll need to report it to MS -- I'm sure there must be a mechanism for that. . Meanwhile there must surely be a way of making an exception in that package.. Are you using the 4.957 Installer BTW? There's no other supported version for P3D at present. Pete

Right. I think your diagnosis is maybe mistaken, but understandably. I believe you are treating a symptom not a cause. I don't think you are fixing anything, just maybe avoiding it, or delaying it. I've done some rigorous testing of the FixControlAcceleration option here, with P3D 3.4, and as far as I can see the crash is occurring because part of the memory in which FSUIPC stores data, like the address in memory of the control acceleration timer, is getting corrupted. I suspect other nearby values are getting corrupted too, but these have no overt symptoms (as yet). Can you please re-enable the FixControlAcceleration option with this interim update: FSUIPC4957a.zip (just copy the DLL into the Modules folder). If I am right, there will be a log entry instead of a crash saying: ### ERROR! Control Timer Memory point is corrupted! Should be XXXXXXXX but now YYYYYYYY If this does occur with no crash, then please follow my recommendations above for checking with and dealing with Weather corruption problems. (FSUIPC will restore the correct pointer value after the log entry and will hopefully continue as normal). This sort of misleading symptom is quite frequent when there's memory corruption. The symptoms can vary a lot, and in fact sometimes there aren't any, at least not via a crash. I've know weather corruption to make a crash only in certain parts of the World, or only when changing aircraft. The possible symptoms are as endless as there are memory locations to be trodden on. Thanks, Pete