Pete Dowson

You mean they aren't seen as any of the button numbers 0-31? So you can't assign them? So are those 3 buttons not part of the 10 you mentioned here: " I have programmed the TQ, tiller and Yoke ( a total of 7 axes and 10 buttons)"? Ah, I know nothing about those. They are in the range assigned to Mark Hastings, originally for the 777 package. Is that Sim-Avionics? But you've not managed to assign to them? What button numbers show up in FSX for these buttons? Does FSUIPC show any response at all when pressed, or a different already-programmed button number? Pete

Not really, except that it is definitely a good idea to do it a step at a time, re-booting between each addition, and testing each one as you go. Pete

FS reacts to "controls" -- such as those you assign in its biutton and keypress assignments, and also in FSUIPC's assignments. You surely must have already at least tried to assign controls to button or keypresses? You must have used some, even if only the "G" keypress by default assigned to GEAR TOGGLE. Your joystick axes are assigned to controls too, for ailerons, elevator etc. Clear so far? Well "custom" means made specially. So PMDG has "custom controls" for all the operations in their 737NGX cockpit. Custom controls have names assigned by PMDG, but FSUIPC doesn't know the names. But all controls have NUMBERS as well, and FSUIPC allows you to assign to a entry in its lists called <custom control>, then give the actual number. To work out the number of a 737NGX control you will need to refer to the PMDG file I told you about. I don't have or use PMDG aircraft, so that's really the most I can do to help, but if you have any specific questions, rather than a blunt "I don't understand anything" I can try to answer. After all, "didn't quite understand" is really no use without saying what the 'quite' bit was! :-) Pete

Yes, well ... if there's no SimConnect.DLL at all it can't connect. I thought you'd used FSXWX before, so how come you needed to "install FSX-SP2-XPACK interface (v10.0.61259.0)" in one of your earlier tests? I'm not surprised. The exported names are all wrong. You have to INSTALL SimConnect, not copy in a DLL. The "SimConnectP3D3.DLL" is not the same, it is my own creation to save folks having to install an FSX SimConnect. The only thing you seem to have changed in all of this is that it now always crashes in WEATHER.DLL, not in UTIL.DLL. I suppose that's progress (is it always at the same offset in WEATHER.DLL? If so, what is the offset?). But it does indicate something up with your specific system -- I've no other reports of such consistent crashing, only those due to corrput weather files which have always been fixed by deleting them -- and, after all, FSUIPC is in use on thousands of installations. Registered or not, without those special parameters to stop it, FSUIPC is always reading weather. I really have no more advice to give. I assume you've already eliminated all other loading programs, eg via DLL.XML and EXE.XML, in case they are interacting somehow? Perhaps a clean start is in order? Pete

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

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.

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

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

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

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

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 "header" 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

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

That shows everything was fine. Pete

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

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

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

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

Thanks! Could you post it as a new item in the User Contributions sub-forum, please? It won't get lost then! ;-) Pete

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

If it isn't weather and not scenery corruption then you have a problem with your computer. Maybe a dodgy memory stick. Pete

Even so, FS will be loading different weather data for that area, so if the current weather data has any corruption which affects that it can cause a crash -- or in this case, judging by these details:- a crash caused by memory corruption (FSUIPC does not extend as far as having an offset in its module as far up as 6A596340 -- that is plain corruption). Such corruption is caused by by pointers or size values in data. Unfortunately the WX data files are not checked by FS when loaded. The fact that you get a crash 90% and not 100% of the time is also indicative of corruption causing incorrect memory references which sometimes, depending on previous goings on, are still valid process addresses. It could also be a corruption in one of the BGL's or textures loading for that scenery. To distinguish between Weather corruption and Scenery corruption you can stop FSUIPC reading the weather by using: WeatherReadFactor=0 which you will find, to change, in the [General] section of the FSUIPC4.INI file, in the FS Modules folder. Of course, even though by doing this FSUIPC is doing basically nothing at all in an unregistered state, FS still might crash because it reads the same data. The only way to be sure it isn't the weather is to delete the weather files (.WX) from your Flight Simulator X Files folder you Documents, and the wxstationlist.bin from the same folder as the FSX.CFG file. If it is scenery corruption I guess the only solution would be to uninstall and reinstall that scenery. Pete

Ooops! It's an outright error in a table in FSUIPC! It IS reading the day of the week, not month! It's been that way since those offset values were added, some 10 years ago! Seems like you are the first person to use that one, or at least the first to have bothered reporting it! So thanks! Would you need an interim update, or just wait for the next release? Pete

Actually, just to correct Thomas (sorry, Thomas), Monat, Tag = ipc.readStruct(0x0244, "2SB") should certainly get the Month in "Monat" and the day of the Month in "Tag", though of course "2UB" would be more appropriate than "2SB" since the month and day cannot be negative (not that it matters with this range of values). So, what exactly are you getting for the day of the month? (Remember, this is the date in FS, which is often being set by the last flight you loaded -- it isn't necessarily your computer system date). I'll check this here ... [LATER] Ah! it looks like it s getting the Day of the Week in 0245 instead of the day of the month. I'm just checking to see if it's a bug in FSUIPC or in FS ... Pete

What exactly are you assigning to? In the controls list there appears to be GPS Clear Button GPS Clear All Button GPS Clear Button Down GPS Clear Button Up I would assume that the plain "Clear Button" send a momentary pulse whilst to hold it down you send "Down" on the press and "Up" on the release. Pete

FSUIPC knows nothing about any specific joysticks or yokes, and I've not even heard of this one. There is certainly no force feedback provided by FSUIPC. As far as I knew, you must assign directly in FS for force feedback, assuming it is to a standard it understands.. FSUIPC can calibrate axes no matter where they are assigned, because that part works on the FS controls for the surfaces you assign to, not on the joystick inputs themselves. I'm afraid I don't really know what they mean about the interface for "third party software" -- presumably any program which knows this device and has programming for it. Maybe there's a hardware Forum where you can get more advice? Otherwise just follow the guidelines given for FSX use. BTW underlining whole paragraphs certainly doesn't make them very easy to read -- quite laborious in fact. I would suggest you don't do that in future! Pete