Pete Dowson

I see Thomas has answered this part. (Thank you Thomas). [LATER] Tested here, and it isn't actually so ... see next post. Winkey isn't an optional shift key in WideClient, at least not for generating and sending -- see the list in the documentation. The only place it is supported is in the ButtonKeys option, for operating FSUIPC's virtual buttons from the Client keyboard -- i.e. IN rather than OUT. Pete

In that case it sounds like they use the SimConnect facilities to read the buttons, though I didn't know they were also disabled when you disable controllers in FS. Do they offer keystrokes as an alternative? If so maybe you can assign to keystrokes? Though it depends how they capture those -- should be okay if they do it the same way, through SimConnect. Pete

Seems you need to ask on the PMDG forum then. Pete

What you are describing only happens on the ground. It is an FS bug. You don't arm spoilers on the ground in any case. Test and calibrate in the air. Pete

Maybe your hat has a problem then, because all directions are the same -- it's FSX which processes the number sent by the Controller's driver. Pete

Select the normal FS axis control option, NOT the direct to FSUIPC one, as I said! Pan view is in the drop down list, in the P's. They are in alphabetic order! No one else has ever not been able to find things in the drop down!!! I've no idea what you are getting up to! :-( Pete

I said FS control "Pan view", NOT any of the direct FSUIPC controls! Don't select "direct to FSUIPC"! You don't calibrate hats! Pete

How were they so "mapped"? If Opus is reading the buttons directly itself then other assignments in FSUIPC or FSX won't interfere or be relevant. It may be a good idea to ask Opus support. Not sure why or how mouse scripts or macros come into it. Mouse macros are ways of calling mouse functions in gauges. Opus doesn't use aircraft gauges for these functions, does it? Pete

Please yourself. I never used that feature in EZDOK. But if you aren't using FSUIPC for it then your problems aren't anything to do with FSUIPC. You need to ask at EZDOK support. If you assign in FSUIPC, use the axis assignments and assign to the FS control "Pan view". Pete

So why on Earth entitle your thread with the rather insulting "Yet another ..."? If you look through the thousands of support questions on this forum you will see hardly any crashes due to FSUIPC4. Those crashes which are reported are almost always due to using the wrong version, or having FS read corrupt weather files. Unfortunately that is crash data for version 4.929 so it tells me nothing. For crash information to be at all usefull it must relate to the latest current version, even if interim. So please copy the latest DLL into your modules folder and try again. You can download it using this link: FSUIPC4934h.zip One crash which can point to FSUIPC and which I can do nothing about, is when the weather data being used is corrupt. I notice from your FSUIPC4 log that the sim got as far as where FSUIPC enables the weather interface. FSUIPC then starts asking SimConnect for the weather. If any of the .WX files being read are corrupt -- eg in this case the one associated with your default flight: \\JAMMER-PC\FSX\FLIGHTS\OTHER\FLTSIM.FLT then SimConnect will crash during one of the calls made by FSUIPC4. Whether this gets blamed on Weather.DLL or on FSUIPC4.DLL is then a matter of timing. If it is in FSUIPC4 (and it rarely is) I might just be able to do something about it -- so please run the FSUIPC4 updated version from the link above and show me the Windows crash data. The other file which can get corrupted and cause similar crashes is wxstationlist.BIN, in the same folder as your FSX.CFG file: C:\Users\jammer\AppData\Roaming\Microsoft\FSX Both these files are binary and completely unchecked so any bad data in them can cause problems. This was a gross oversight by MS which was never fixed. So, after you've run the test with the interim FSUIPC4 update, please try loading FSX after deleting the .WX file and the wxstationlist.BIN file. Don't worry about them, they aren't needed -- the BIN file will get regenerated and the WX weather will simply revert to default and will then be set again by ASN. If this doesn't work, please try running FSX without ASN because it might be a conflict with whatever version of that program you are using. Pete

So, have you assigned the hat switch in FSUIPC or in FS or in both? And what to? It is difficult getting enough information from you! ;-) Pete

and, as I asked: Does the Log file show any errors? Pete

No. Just installing FSUIPC changes nothing at all. It simply acts as a data interface to client applications. Why have you registered FSUIPC if you aren't using it? Pete

You need the version number of FSUIPC, not a date! It is easy enough to find -- it is shown in the options, on screen, it is shown in the Log file, and it is found in the DLL properties. Does the Log file show any errors? Pete

You are only logging Axis inputs -- the flooding I was talking about tend to be the other events. However, I don't know what you are doing with that spoiler axis. Do you keep moving it very very fast so somehow resulting in alternate larger numbers and zero (???), or is the axis faulty, or is it the PMDG aircraft trying to set it to zero against your wishes? If I were you I'd test things on a default aircraft before worrying about your axes on a PMDG one. Pete

It means the registration key is invalid, a fake, made to look real so accepted by the installer but resulting in deactivation of a number of FSUIPC features, including supplying data to applications. Pete

Assuming you are talking about reactions in a fighter or stunt aircraft, where you expect and need an immediate response, and not in an airliner which has natural inertia in all axes and even throttle results on the engines, there are only two causes of delays I can think of, and they should usually be barely noticeable. The first is using the Filter option in FSUIPC's calibration. That needs a sequence of inputs to formulate the next result going into FS, and can in some circumstances and controls produce a slight lag. The filter option is only suitable for drastic control instability, of the type usually caused by bad power supplies. The second is caused by having the Delta value, in the axis assignments tab, set too low. The default of 512 or 256 should be good for a properly calibrated (in Windows) axis. If it is too low you will get multiple small changes flooding the message queue. There is actually also a third possibility I've just thought of and that is where add-on aircraft (or other programs, actually) are flooding the message queues with commands too. I've noticed that some of PMDG's aircraft repeatedly send the same controls over and over for no reason apparent to me. To see if this sort of thing is responsible, enable Event logging in FSUIPC's logging page and take a look at the log generated. Pete

Buttons are not tested "simultaneously". You simply make the actions of one or more buttons conditional on the state of one or more other buttons with the latter pressed and held first -- as you then go on to describe, in fact. This is covered in the manual. You need to edit the FSUIPC INI file to do these things, but it isn't hard. See the "Compound Button Conditions" section, around page 16 in the Advanced User's manual. Pete

FSUIPC doesn't throw such exceptions -- it is the Client DLL.or your application. And there is no reason for it to do so just because of an updated version number. The check in the FSUIPC interface code in the application or client DLL checks that the version number is not less than 1.998e, because that is the earliest version supporting the code supplied in the FSUIPC SDK. It sounds like your user has either got his computer date set to one earlier than his registration, or he has got an invalid or even illegal registration key. To check for either problem tell him to remove the FSUIPC4.KEY file from the Modules folder. If it then works okay the computer date or registration is probably bad. Other than this, I'd need to see the FSUIPC4.LOG file -- a complete log with the simulator closed down. Pete

Please look at the [JoyNames] section of your FSUIPC INI file. Are both cards identified with the same identical GUID? Or are they different? There are two possible causes of this problem. The most likely is that as far as Windows can see, the two cards are completely indistinguishable. In that case the GUID will probably have been generated by Windows on the basis of which one it saw first. Which it sees first will depend on the USB socket used, so if this is the case you probably simply need to swap sockets. The other possibility is that you are not using Joystick Lettering. With unique names or GUIDs the use of FSUIPC's lettering (in place of numbering) will ensure that no matter where you plug things in, FSUIPC can still match up the number to the device. This does depend on unique names or GUIDs, however. Please do refer to the user guide for FSUIPC. There's a section on joystick lettering which should help. Regards Pete

Well, something is telling FSUIPC that version number, assuming it is still shown that way in the FSUIPC4.INI file. Please check the FSUIPC4.LOG file -- show that to me please. There it logs the version returned by SimConnect. You could also check the FSUIPC4 Installer log file, which will also show the version number direct from the EXE properties. [LATER] I just checked my code, and the line which goes into the INI file contains the same information as the line in the LOG file, and is the version number as supplied by SimConnect. In my case, when I was using version 2.2 build 10438 the LOG line showed: Running in "Lockheed Martin® Prepar3D® v2", Version: 2.2.10438.0 (SimConnect: 2.2.0.0) So, I still think your update is done fully and it would be worth re-copying the files/folders across. It can't do any harm and will avoid any problems possibly caused by mismatched modules. Okay. Sorry, then, FSUIPC is doing what it should. I think you need to take this to A2A. Regards Pete

Thanks for confirming. I'll need to do some checks here to make sure it hasn't messed up the vehicle deletion option. For stationary vehicles at your gate it should work okay. I only ask for details of vehicles within 50 metres of your aircraft in any case. The trouble is, and its the same with aircraft, you have to lodge a request for all "Add Object" events very early on, before the first flight is loaded, because the range-limited request, made later, only gives changes. If I don't ask for all object changes when very first starting I don't get those already there when you start your flight. And the "Add Object" events are not range limited, so it would get ground vehicles from all airports within the "reality bubble". I seem to remember it was one of the failings of this part of SimConnect which I reported and which MS agreed to fix "in a later version". Ha ha. What should happen is there should be no need for the initial Add Object event detection, only a complete set of information within the range specified when actually requested, and thereafter changes -- additions and removals. Regards Pete

Please try FSUIPC 4.934h Throw all you can at it. I've changed the type of data request used for ground vehicle data to be once-only, rather than with updates every second, as I have to do with aircraft (so that they can be tracked). I'm hoping this will not adversely affect the facilities for deleting the vehicles when appropriate, But it should help with this problem. I think these "too many requests" errors arise because it has to put them into a table so it can do the updates every second. When it's a one-off it probably doesn't need tabulating. If this doesn't work I'm afraid the only answer is to turn the option off after all (i.e. DeleteVehiclesForAES=No). Pete

Strange that there can be so many. I'll check my code again to see whether there's something wrong there. Ooops! Apologies -- typo in the line "The airport traffic is filtered out in FSUIPC, and is only read (to see if it needs to delete duplicates for AES/GSX) if the parameter "DeleteVehiclesForAES" is set to "No"" It should (obviously?) read: "The airport traffic is filtered out in FSUIPC, and is only NOT read (to see if it needs to delete duplicates for AES/GSX) if the parameter "DeleteVehiclesForAES" is set to "No" So could you repeat but with 'No', please? Can you tell me if that log (or a repeat of that test) contains the line 56067 ## Starting everything now ... because if it does then maybe a delay before requesting data will help. If the message is not there at all then I'm puzzled , because the way it is coded in 'g' is not to request any AI data will after the point where that message should occur. I'll get back on this. May be tomorrow now though. BTW, I just checked. I have always run with Airport Scenery Density set to 5. Odd that I don't see the problems. Pete

Okay, I checked, and, on the 737 at least, TCAS range is actually only about 40 nm. so i've reduced FSUIPC's traffic range from 200 km down to 100 km. I've also moved the initial request for Simconnect to supply AI data till AFTER the complete initialisation of everything else -- i.e. after the point where FSUIPC logs "Starting everything now ...". None of this had been necessary before -- you're the first to overload the system with AI! I can't think of anything else I can do really. Please try it, with all of the original traffic which caused the problem. Let me know if you still get all those "too many request errors", because i'm worried those will still occur even if they don't actually stop you getting the Lat/Lon. Link to interim update: FSUIPC 4.934g Regards Pete