Pete Dowson

Okay. So you have a device "joystick 2" which has a button (11) which is continually flickering on and off. Look in your FSUIPC INI file, find the [JoyNames] section. That will tell you the name of Joystick 2. Unplug that device. check that the problem is no more. There was a problem like this (only not so frequent) on early versions of the Saitek yoke, I believe. In fact I added a special facility to FSUIPC to help resolve it. The spurious button presses were very short -- shorter than a normal human press would be, so I eliminated them by ignoring short press times. See if it helps you. It is this, as described in the Advanced User's document: Regards Pete

I assume that the joystick/Button number in their boxes top centre are also flickering or changing? The only way anything on that page changes is when another button press is seen. If that is occurring all of the time, without you touching anything, then certainly something in or attached to your system is doing it. If you cannot tell the joystick & button number from that display, enable Button logging and check the log -- show it to me if you aren't sure what you are looking at. Regards Pete

You are trickling information as if you don't want to provide any. You are wasting a lot of time withholding information all the time! :-( Now we know what program it is, what is the EXACT error message (it cannot be what you said as that one doesn't exist). And why won't you show me the Install log as I asked? Pete

If this is with version 3.96 or 4.57, please try the update available in the Updates announcement above. Pete

Sounds like your joystick drivers are still polling the joysticks and timing out. Why are you disconnecting them? That isn't a good thing to do in any case. Leave them connected. If you do that sort of thing with FS assignments it tends to reassign default settings each time, thinking they are new devices. Incidentally, FSUIPC 3.93 is not longer supported. The current main release is 3.96, and there's an update (3.962) already available in the Updates announcement above. Regards Pete

This is for FSX? You are looking in the FSX.CFG in the correct settings folder for your log-on user name? Here's my [CONTROLS] section for FSX, with joysticks disabled: [CONTROLS] Controls_Default=Standard Controls_Current=Standard KBDAIL=64 KBDELEV=64 KBDRUD=64 JOYSTICKS=0 Regards Pete

Which install? Seems like some context is needed here. Have you any information you are holding back? Like what program are you trying to install? I'm afraid I can neither read your mind nor see your computer from here. If you are talking about the FSUIPC4 installer, show me the Install log which you will find in the FSX modules folder. Also, if you are talking about the FSUIPC4 installer, there is no message saying "can't find the DLL.XML". It doesn't care at all if there's no DLL.XML, as it creates one for you if there's not one there! I think you are reporting the wrong error and looking for the wrong file! Please be a little more forthcoming and accurate. Regards Pete

Okay. So, if there's no DLL.XML and no EXE.XML then that means you have not installed any DLL or EXE applications for SimConnect to load, at least for the current user (the "AppData" folder under Vista and Windows 7 is specific to the logged-on user). What are you expecting to find? Why are you looking for it? Pete

Where did you find the FSX.CFG file? The one in the main FSX folder isn't the one in use. If you've installed FSUIPC4, look in the FSUIPC4 install log, in the FSX Modules folder. It tells you where it found FSX.CFG, and that's where it updates the DLL.XML file. If you've never installed any DLLs there probably won't be a DLL.XML file in any case. Maybe installing the FSX SDK places a dummy one there, but I'm not sure. Regards Pete

Search for "Joysticks=". I think that is a 0 or 1 value. Pete

Right -- that's what I would have thought. Regards Pete

Hmm. Very strange. So far everyone else seems to find 20 mSecs works fine. I changed the default to that in the updates. I wasn't advising you to use that -- I was thinking that it might have been the cause of the slow poll time. That you are not using it only increases the puzzle. Try installing the update available above, in the "Updates and other goodies" announcement. I am re-thinking the way FSUIPC performs this checking now. I am planning to change it as follows: 1. Reset the "black mark" against a joystick each time the Axes or Buttons tabs are entered, or when the settings are Reloaded in either of those places. This gives everything a "fresh stab" at working properly, in case the previous failure was a fluke. 2. Only apply the currently set timeout (default kept at 20 mSecs) if the eventual return from the poll was an Error - i.e. not a correct response. This should quickly weed out the bad driver problems which were causing the hangs for which I added the facility in the first place. 3. For all other cases apply a timeout of 4 x the currently set timeout, with a minimum of 60. I'll make these changes today. Look out for updates later. Regards Pete

If you've not changed anything, or installed anything, then the only possibility I can think of is that you are assigning the axes in FSUIPC but haven't successfully disabled them in FS. For example, If you disconnect a joystick and then reconnect it, FS will sometimes treat it as a new connection and make automatic assignments. If you have dual assignments to any axis, they will be competing with each other. So, check FS assignments. Regards Pete

50? That limits poll rates to 20 fps with nothing else going on! Mad! Is that with the CH control Manager running? The timeout check does NOT operate in flight modes! Once you've assigned and calibrated, that's it. The timeout ONLY applies in the options dialogues. In the latest interim updates they don't even apply to the calibrations dialogue. Well, I should think by setting a timeout at the max, 5000 (5 seconds), there's an extremely good chance it will never operate. Have you ever had to wait 5 seconds for a joystick or button to operate? But as I say, i think you are worried about nothing at all. If it cannot operate in flight modes, what's the problem? The whole point of it was to eliminate rogue joystick signals when trying to find good ones, not do anything at all for ones you are actually using! Whilst you were assigning? Or calibrating? The code does not operate in flight modes, as I say, only in the options. 50 mSecs is a hell of a long time. I'd really like to know what caused that! Please tell me what you have running. Pete

Ah, I see. I didn't know that. Regards Pete

Good. but it is indicative of some clash with TCP/IP -- probably one of the ports being used by SimConnect is causing it to receive the initial data from WideClient, when it tries to connect, and it crashes/hangs FSX trying to figure it out. I don't think SimConnect's protocols are particularly resilient, unlike WideFS's. (I come from an engineering test programming background, 1963-1979, and always assume there will be errors in data and faults in hardware! ;-) ). Regards Pete

What "fuel cut-off" do you mean? Normally, with any prop aircraft, you cut the engine by reducing the mixture control to full lean. The fuel tank selection valve is turned to "off" after the engine quits. This is a safety precaution -- if you do it the other way, whilst the engine might suck some of the fuel out of the pipe line after the valve is off, it cannot take it all out, and that leaves a dangerous situation where the engine could start up just if the prop is moved. Regards Pete

Okay. Hopefully, for FSX, the PM code uses the "global" weather mode in FSX for best control. I implemented that feature specifically for Instructor implementations. I assume you have subscribed to WideFS, enabled it in the FSX PC, and you are running WideClient in the Networked PC? I'm sure the PM documentation does tell you all about setting up WideFS, along with pretty pictures if I remember correctly? Regards Pete

66FD is the byte BEFORE 66FE. A byte is 8 bits only and cannot contain a number as big as 256. The value 256 in a 16 bit word is a 1 in its high byte. Therefore is looks like the program you are using refers to WORDS (16 bit values, 2 Bytes long) not BYTES, whilst you are using a BYTE size FSUIPC control. Ah, I see you figured it out. Pete

That could mean one of three things: 1. FSUIPC isn't running at all. Determine this from the current log -- if there's only the previous log (go by date/time), and its menu entry is missing, it isn't running. 2. It is running but hasn't intialised correctly, usually because of a SimConnect problem. Determine this when there is a current log, probably with errors listed, but there is no "FSUIPC" entry in the Add-Ons menu, or maybe even no "Add-Ons" menu anyway. 3. FSUIPC is running happily but something is stopping WideServer. Check this is both the FSUIPC and WideServer logs. What are those words? They might provide a clue, don't you think? What is in the Add-Ons menu you can see? If FSUIPC then FSUIPC is running. Regards Pete

Yes, those are the ones which are accessed via FSUIPC offsets so that third party applications can "tune" the operation for different aircraft. Okay. I was probably hoping someone would experiment with different values, and maybe come back with different defaults which would work much better out of the box? Not that the speed control ever worked well for me even in FS9. I'm not sure. I assume you've not, therefore, tried increasing it via the relevant offset(s)? Or are you saying that, notwithstanding the offset value adjustments you can make, there's some limit I'm applying which you can't change? If so, then it seems like I'll need to search the thread to see what you are talking about. Sorry, I thought you'd found it so could quote it or point me to it. Regards Pete

Does it work from the keyboard? (G normally). Enable Button and Event logging in FSUIPC, operate the button, see what the Log shows. See if it is different from what happens with the "G" key. If the GEAR TOGGLE control is being sent but FS is not obeying it, you have some sort of corruption in your FS installation. Regards Pete

Yes, it was most clear. And the answer is clear too. If the switch toggles the gear it is most certainly assigned to do so, whether in its own driver (CH control manager maybe?), or in FS or in FSUIPC. You appear to have eliminated FSUIPC (by trying without), so it is elsewhere. Enable Event logging in FSUIPC and check the log. In that case the control is obviously assigned in FS to that switch on the yoke. There's no other answer, really. The controls.dll does not contain any key or button assignments. It's main function is to translate control numbers into calls to specific routines in SIM1, PANELS and so forth. It also contains the table from which FSUIPC gets the names for the FS controls. All of your FS assignments are either defaulted, by definitions in the "devices" CFG files, or, more usually, assigned in the FS9.CFG file. If you genuinely cannot find where you have the assignment I suggest you remove the FS9.CFG file and let FS generate a new one. Regards Pete

Does the A2A Piper Club use the default FS carb heat simulation? If so it'll be one of the FS controls for engine anti-ice. There are several: Anti ice on, Anti ice off, Anti ice toggle, and separate ones for each engine (Anti ice toggle engN where N = 1 to 4). If the panel uses the standard FS controls you can find out which by enabling Event logging in FSUIPC, operating the switch on the panel, and looking in the log. Regards Pete

Sorry, I really don't understand that as there's been no changes in anything related to processing buttons and axes. The timeout added only applies when making assignments. All the other changes between 3.93 and 3.96 have been incremental over the last 4 or 5 months and have had plenty of users. you can see the total list of changes in the History document. You will note that almost all of them have been bug fixes and extra facilities, no "in-line" changes in any controls and so forth. Okay. Maybe you can be more specific about what you think is going on? Maybe some button/axis/event logging, comparing 3.93 with 3.96 would help? Okay, but I cannot support 3.93 now. There's no way back for me. Regards Pete