Pete Dowson

Moderators
  • Content count

    30,425
  • Joined

  • Last visited

Community Reputation

79 Excellent

1 Follower

About Pete Dowson

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

13,729 profile views
  1. Really? From the Windows Event Viewer? Why would you do that? I can refer back to any type of system or application event logged there, in case of investigations needed later. Hmm. I think there must be something wrong in the SimConnect part of your P3D, as all the FSUIPC weather stuff now (additionally) prevented by the "WeatherReadFactor=0" option is all just standard SimConnect weather calls. There are no hooks, no clever code, nothing other than properly documented SimConnect stuff. (All the 'clever' stuff is switched off by the "NoWeatherAtAll=Yes" option). The problem is solving that one. I've no idea how to do that, and unless you can do without a weather App which needs FSUIPC (eg change to AS16 or Opus or REX) you'd need to resolve it. It would be worth reporting both the WEATHER.DLL and UTIL.DLL crash details to Lockheed-Martin, on the support forum. One little thing you could try, though I don't think it would make any difference, is force FSUIPC to use one of the FSX versions of SimConnect (which you'd need to install if you don't have one already ... see what the FSUIPC4 Installer found, logged). To make it use a different SimConnect DLL just remove the SimConnectP3D3.DLL from the P3D Modules folder. The reason I don't think that will change things much is that the SimConnect DLLs are really only an interface for applications into the real SimConnect code, which is spread around in the main modules. Yes, like WEATHER and UTIL. Pete
  2. Aha! Sorry -- mea culpa. Yes, the Weather reads are still being done. Unfortunately, when I tested, I'd already set "WeatherReadFactor=0". Please retry with that set too. I'll fix the "NoWeatherAtAll" option to assume that too (4.955g). Pete PS could you also please give the module offset in UTIL.DLL when you get it crashing there? I have an example of a UTIL crash in FSX-SE and I'd like to compare the code in the same area, to see if this is a more common thing.
  3. No, it becomes irrelevant. FSUIPC just doesn't touch weather at all, and removes all the weather options from the menus. So, something else is corrupting memory somehow. Just because it receives a request from an application doesn't mean it does anything with it. Were you running your weather app? Please show me the log. It means that links made into WEATHER.DLL and other parts related to the weather facilities were not made. Please show me logs not try to interpret them yourself. Pete
  4. I don't really know. Apart from Weather, FSUIPC doesn't really have anything to do with UTIL.DLL. In fact I've no idea what UTIL.DLL does in any case. Normally corrupt weather data crashes WEATHER.DLL, FSUIPC itself, or SIMCONNECT. Since you downloaded 4.955f, did you try with NoWeatherAtAll=Yes, as documented in the Changes PDF? That was the point of getting 4.955f, wasn't it? (With that set, if FSXWX sets weather through FSUIPC, it won't work -- but this is only for a test). Then the next test is to see if it is scenery location specific or aircraft specific, which would point to an error in one of those if so. You would need to load with a different default starting place and / or different aircraft. [LATER] I had a look at the P3D3 version of UTIL.DLL -- P3D now names all the exported functions, so it gives a little inkling as to what it does. It seems to be a collection of utility functions, to do with Lat/Lon conversions and calculations, 3D scenery computations, and simple more general stuff like copying strings, allocating memory, and so on. So basically it could be used by WEATHER.DLL or any other part of FS. (FSUIPC doesn't use it at all). Pete
  5. If it appears to Windows as a standard joystick device, with buttons and maybe axes, then, yes, FSUIPC will see it -- but it must have a registered ID number (0-15) in Windows. Quite a few devices seem to install without such being assigned -- this is becoming more frequent with Windows 10, but it occurs sometimes in Windows 8 as well. Sight of the FSUIPC4 log file content would have been useful. You can force an ID for it using the JoyIDs program -- see the FAQ subforum. The very first entry there is "Fixing joystick connections not seen by FSUIPC". Pete
  6. After what changes? No, I'm not sure I do. By "P3D real time weather" do you mean the built-in weather facilities in P3D, or is "Realtime Weather" a product name. I googled it but came up with nothing relevant to FS or P3D. And isn't FSXPilot an iPad or Android App. doesn't it have its own interface to FS/P3D? SimObjects? What's that? How os it related to FSUIPC? All those are definitely symptoms resulting from corrupt weather data being loaded by SimConnect. To show it is weather related try setting the "WeatherReadFactor" parameter in the INI file to 0 (it defaults to 2). This stops FSUIPC reading the weather from SimConnect at regular intervals. FSUIPC 4.955f (released yesterday, by coincidence -- see the Download Links subforum) also includes a special diagnostic option to stop FSUIPC having anything to do with weather at all, so that could be used to further prove things one way or the other. You say you have tried deleting the wxstationlist.bin and all of the .wx files, and so far this has always sorted this sort of problem. Are you sure you deleted the files from the correct folders? The .bin file is the User AppData Roaming folder for Lockheed Martin P3D3 I think. The .wx files will be in the Prepar3D Files folder in Documents. Pete
  7. Problem Creating Mouse Macros

    By sheer luck I saw your post, in the FAQ subforum. That's a repository for answers to frequently Asked Questions, it is NOT a place for general support questions. Please always post in the main Support Forum. I've moved it for you so it could be answered. I see you posted the same question twice, a few hours apart. Maybe you were concerned about not getting a reply, but you won't when you post to the wrong place. I've deleted the duplicate. No, That is completely wrong. FSUIPC doesn't track mouse movements, or even mouse clicks. The mouse macro making method involves FSUIPC placing a hook in the code inside FS where the FS mouse action code determines what to do when you click, and directs it to the appropriate Gauge. FSUIPC simply records the last part, so that it can call the code directly without any mouse being involved. Mouse Macros are not appropriate for 90% of newer add-on aircraft (or even most default aircraft), because this method depends upon the Gauge being written to precise rules, the Microsoft FS9 C/C++ standard gauge SDK. When they don't operate on a specific aircraft or gauge you need to use other methods. With the PMDG 737 (and the 777) this is easy -- PMDG provides "custom controls" for pretty much every function, on all of its gauges. These are listed in the PMDG SDK 2header" file (.h type) for the aircraft, as installed by the PMDG installer. In FSUIPC you merely assign to <custom control>, giving the number of the control worked out from that file. Pete
  8. FSUIPC4.dll error

    I think it's a SimConnect module loading glitch, which is a bug in FSX and FSX-SE related to its "trust" checking (the system which asks if you really want to load a module when it's new or a new version). Microsoft knew about it right back to the start of FSX, but never managed to fix it because it is so elusive -- it doesn't happen to everyone, nor very often, but sometimes can be very persistent. I think it is some timing clash between different activities during loading, and it very very timing dependent. The module concerned (FSUIPC in this case) doesn't actually get to run by the time the problem occurs, it is in the loading process. Pete
  9. FSUIPC4.dll error

    That shows everything was fine. Pete
  10. FSUIPC4.dll error

    No "of course" about it. I get such warnings a lot with BGLMANX.DLL (the module used by GSX), but sometimes it continues okay. However, there's really no way I can help without more information. If FSX-SE crashes there will be crash details -- either grab them at the time, or refer to the Windows "Event Viewer" for the application log showing the error. Also, if FSUIPC is loading and running at all there will be a Log produced, "FSUIPC4.LOG", in the FS modules folder. Please find that and paste its contents here. It will show how far FSUIPC is getting. Pete
  11. FSUIPC Requesting Data Best Practice

    Since calling FSUIPC via the Process request involves your program's process being suspended, and FS effectively "interrupted" (well, another message to process, which gets passed on to FSUIPC), and then another action by the operating system to resuscitate your process, it is generally much more efficient to group your data requirements so that there's only one batch to process. Unless your Process call includes Writes to Offsets which invoke some sort of action in FS, the processing of a batch takes almost no more time for more data or less. It's pretty much just memory copying. Anyway, with only a 5 second polling rate, such performance considerations are negligible. There are programs which request hundreds of data items at a time every 20 milliseconds or even more often -- then it becomes much more significant! You can test these sorts of performance things yourself using the supplied FSInterrogate2 utility (in the FSUIPC SDK). You can batch select a large number of items and have it retrieve them continuously in quite a tight loop. See how much data can be continually requested this way before the affect on FS performance becomes noticeable. And in performance terms it doesn't matter whether you leave it connected or not -- but always leave it connected if you expect to make another request: only disconnect when you no longer need any more updates for your current session -- OR when you get a timeout and need to keep trying to reconnect (eg over an FS crash, or some inordinately long delay in FS). Pete
  12. LostActivationKey

    No need. As pointed out in the FAQ thread entitled "READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS key", you just need to go to your SimMarket account and retrieve it. This applies to any and all purchases made through SimMarket where keys are involved. Pete
  13. Well, FSUIPC is not interfering or affecting the keyboard, so it can't be FSUIPC. There must be something else you are accidentally invoking which is also using those keypresses and it intercepting them. Have you tried assigning the Yoke buttons to the ATC MENU controls, instead of key-presses? If those work it should show it is something to do with keypresses only, and you would need to check what other add-ons you have which might be doing it. Pete
  14. Getting Current Flap Detent Value

    Thanks! Could you post it as a new item in the User Contributions sub-forum, please? It won't get lost then! ;-) Pete
  15. The wind effective at the aircraft is the one shown at the top of the screen when you use Shift+Z. Compare that with the wind indicated on your ND by your SimAvionics software. It should be the same, and it should be what it is using. I've never used SimAvionics, but I have used other such packages -- Project Magenta for years, and now Prosim737 for that last two years. Both have always given good precise autolands, with maybe sometimes the only problem being a tendency to 'flare' too much a float a bit before touching down. Of course gusty weather will mess things up, as will any sort of turbulence whether caused in the weather or by aircraft landing in front of you. Short lived changes in the wind won't show on the read-outs on the ND etc, but will have an effect. Weather apps like AS are quite good at providing this sort of weather phenomena, but ASN and AS16 also have a facility for fixing the wind at the aircraft which you could try. I note that you also say the flight director does nothing when the ILS needle moves to one side. That is suspicious. Surely, that IS the flight director indication? If it suddenly moves off it sounds like it is changing course abruptly, which suggests either a wind direction change (which the A/P should at least attempt to compensate for) or some data anomaly such as the runway direction or the magnetic variation (though I don't see how it could suddenly read a different value if it acquired the correct centreline and direction earlier). Pete