Pete Dowson

  • Content count

  • Joined

  • Last visited

Community Reputation

81 Excellent

1 Follower

About Pete Dowson

  • Rank
    Advanced Member
  • Birthday 08/27/1943

Contact Methods

  • Website URL http://

Profile Information

  • Gender Male
  • Location Near Stoke-on-Trent, UK
  • Interests Flight Simming, Steam Railways, Table Tennis

Recent Profile Visitors

14,555 profile views
  1. Switching aircraft

    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
  2. 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
  3. 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
  4. 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
  5. -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
  6. P3D v3.3.5 crash

    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
  7. Microsoft Security problem

    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
  8. 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
  9. P3D v3.3.5 crash

    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
  10. P3D v3.3.5 crash

    Further to my last test suggestions, before doing any of that, please ty 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
  11. P3D v3.3.5 crash

    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
  12. P3D v3.3.5 crash

    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
  13. P3D v3.3.5 crash

    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
  14. Microsoft Security problem

    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
  15. P3D v3.3.5 crash

    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: (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