Pete Dowson

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

Okay. I found some spare time and tried it. I can confirm that it works fine with the as-yet unreleased P3D version 2.3 -- this is with the early Beta1. I'm not able to test it with 2.2 10438 because I am not in a position to re-install it. Maybe it was a bug and is now fixed, but my guess is that it's to do with your bad 10438 install. I actually went to LFPV as in your first example, tuned to 286.0 and within 5 seconds the autotune set 286.5. The signal is strong even on the runway at LFPV. My normal test is Whitegate near EGCC, on 368.5, because it is local to me, but for that I need to get nearer and off the ground. If you still have problems you'll need to try to do the tests I told you about. Pete

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", the ground vehicles shouldn't matter. Perhaps you could check? FSX only generates traffic within its "reality bubble", which I think is 80nm around the user aircraft. FSUIPC ignores all but the nearest 96 on ground and 96 in the air -- that's a limitation of the offset tables it maintains. However, in order to determine which of the aircraft are the nearest it has to read all of them, and compute their distance according to yours and their latitude/longitude. I could limit the range for the data being supplied by SimConnect to less than the "reality bubble" size, but one of the main uses of the tables is for TCAS, and that can be up to 80 nm I think. I'll check further on that. (My range is 200 km, based on the bubble size). It would be nice if I could restrict the range for ground aircraft separately, but it isn't an identifiable group -- of course they change status in any case. As it is I am checking aircraft parked at airports up to 80 nm away just to see if they are withing the nearest 96. I have them all, and what makes them heavy on performance is mostly AI traffic. The latest verston of EGLL Extreme, with the Terminal 2 open, was a HUGE performance killer on my PC and I had to turn the traffic down quite a bit. It's just the sheer number of gates -- more gates, more aircraft. Pete

I think the about display is generated from another module -- the DLL for different languages I think. It sounds like you may have not got all the correct components of the 10438 copied over from their ZIP. To check the EXE, right click on it and select Properties - Version. Probably then best to re-copy all of the parts from the ZIP over again, and re-check. It works fine for FSX. It's pretty simple. I would suspect a P3D bug, but I'll check and report it next week -- if it is still the same in 2.3, that is. Pete

Not according to the version number of the P3D exe, as saved in the INI file you showed: FSVersionUsed="Lockheed Martin® Prepar3D® v2",2.2.10437.0 Maybe you didn't install the update correctly? You don't need to understand it. If you just bothered to go to the Logging Tab in FSUIPC options, you will see on the right-hand side words matching those I said, like "Offset" and "Type". I knew I didn't need to actually explain what they meant because you can simply match the words -- they are there, on the screen. ;-) I can understand that you then might not know where to look to see the results. I'll help. just check the "normal log" option below (that's the checkbox with those words next to it), do the test, then show me the log. Well, it's so unimportant to you, and you really can't match my words to words on screen, yes, I can look. Maybe next week. I rarely run P3D at all. But first try again with the 10438 update for P3D properly installed. If I've not come back by a week tomorrow, remind me, because after that I'm on holiday in Poland. ;-) Pete

Or just change the 123's to 122's in the WideClient.INI file. Well, I did say, many messages back, that until you actually press the button it obviously cannot show anything. Folks have many many buttons each with different assignments. What do you think it should show? I did ask you if the joystick number and button was blank, and you said yes, so I told you to press a button, and you said you did but it was still blank. that's why, for most of this thread, I've been concerned that you were losing the joystick connection!! It isn't really a mess. with only two buttons assigned and one keypress, it couldn't possibly be a mes! You ought to see some folks INI files! Yes, you can delete anything you like. Pete

There is no FSUIPC version which works properly with your installed version of P3D 2.2. you MUST apply the 10438 update as made clear in the sticky at the top of the forum and also in the Changes notice included in the ZIP file for 4.931. And, yes, please now update to 4.934 also. You can check this yourself -- I won't have time for a couple of days. All the AutoTuneADF option does is try the frequency with .0 and .5 alternately. You can Monitor this in FSUIPC logging, right-hand page. Offset is 0356, Type U8. That should be changing between 0 and 5 at five second intervals whilst no ADF signal is detected. If it is doing this, then the option is working but maybe the signal strength indication from P3D is broken. That is in offset 0C1C, type U32 and needs to be 50 or more for a recognised signal. Note that this option can also be disabled by a non-zero value in offset 3108, type U8. Check there too -- this option is used by some applications (I don't recall what they wanted it for!). Pete