Pete Dowson

Best really to show the complete Install log, which even if FSUIPC4 doesn't install can be saved via the menu provided. There may well be more useful information in the log -- after all, that is the whole reason it is produced. However, this message undoubtedly means your FSX installation is incorrect. Please refer to the FSX Help announcement above for hints on how to repair the base version of SimConnect, which is what you are missing. Regards Pete

Certainly if you actually disable the complete joystick (not necessary then to go through all the assignments), they should not come back. If you don't do this, then they can come back if you unplug them and plug them in again, or, I think, even if they go into "power-saving mode" and later wake up. Best to switch that off in the Device manager for all USB ports. Note also that FS only ever saves its options when you close it down normally. It may be that you aren't getting a normal shut-down. Check for this by looking in the Windows task manager after you think it is completely closed -- CTRL_ALT_DEL, look through the Processes list for FS9.EXE. If it is still there, it hasn't terminated fully. Regards Pete

First, assuming it's a USB device, try connecting to a different USB port -- not one next to the current one, as that will be on the same controller. You need to eliminate the possibility that it is a motherboard USB problem. Unlikely, but best to be sure. Regards Pete

That's very much out of date now, and unsupported. You should be using Version 3.80. Well, not according to the first Log. didn't you see this: I know the FSUIPC log says you have a key, as for FSUIPC, but since that log was incomplete (you did not close FS before using it), I cannot tell even if your FSUIPC key is valid. Please never supply logs until everything is closed down. There is always important information in the final closing lines. Something is wrong, if not with the Key(s) then instead maybe with your system's date. WideServer reports it as 05/12/07. Is that when you ran FS for these logs? If not, why is the system date set so? Have you perhaps had a crash or had your motherboard battery changed recently? If the data in your PC precedes the date you registered either FSUIPC or WideFS, then the related key won't be valid. The second WideServer log shows things okay, though yet again it is incomplete, so it isn't much use. Could that log be after you actually entered your registration? Why supply two WideServer logs and yet no WideClient log, when the latter is probably more relevant? Please check these things. Update your FSUIPC, and try again. And check the WideClient log, as the answer is there -- there's nothing shown wrong with the Server end, assuming you have a correct Registration and system date. Above all please always close down FS and Wideclient before showing logs. Regards Pete

Short for "potentiometer" - a variable resistance device. They'll be standard components, but best to contact CH in the first instance in any case. They are pretty good at offering reapirs and parts, cheap or even free. Regards Pete

No risk. It only does something when the option is enabled AND you are using the A/T in mach mode. And then all it does is occasionally (once every 15 frames or so) re-write the current AP Mach setting. But that won't help non-Ellie users -- after all it affects the default FSX gauges too. It's done. It wasn't hard ;-). Try it: http://fsuipc.simflight.com/beta/FSUIPC4263.zip The option is on the Miscellaneous tab. Regards Pete

Yes, but Moshe is doing the same by ticking the REV option in FSUIPC. He's not assigning through FS, otherwise he'd be reversing them twice by doing that. Regards Pete

Results of experiments here: First off, the IAS/Mach C/O button in the FS gauges do NOT change anything detectable inside FS itself unless the A/T is active. It is merely a local display option. There's no way FSUIPC or anything can detect that you are displaying Mach rather than IAS, and I could not risk updating the IAS from the Mach without knowing you are displaying Mach in case it should be the other way around. So, whatever fix is adopted will only work when a speed control mode is active. Is that what you wanted? I have no idea how the "Ellie" gauges you are using handle the display change or what it displays, but it seems to me that if this is to be completely fixed, the local display operation would need modifying too. Second, I've found that all that is needed is for me to rewrite the Mach value as it is -- it doesn't need to be a different value. That makes it simpler to implement -- I don't have to run the risk of making two changes with the possibility of ruining a user change in between. There could still be a danger of a user mach change getting temporarily nullified by one of the automatic re-writes. I'll experiment further and if okay send you a version to test. Regards Pete

Version 4.1 is defunct, dead, unsupported. There is nothing working in 4.1 that shouldn't also be working in the current release, 4.26. If there is I need to know about it so it can be fixed, but there has been no such reports, and 4.2x versions have been current since last September at least. Version 3.8x is for FS2004 and before. You need to know which version of FS you are using! Pete

Whether you view the incoming values through FSUIPC (the "IN" values), or with something like Joyview (attached), the smoothness and range of the values you get should be a sure indication of whether you have a hardware problem. Sounds like dirty pots or a sticking wiper. FSUIPC cannot influence the "IN" values it displays -- they are what is being read, direct from Windows if you use FSUIPC's assignments. Are you using CH's Control Manager? Is it interfering? You shouldn't need to use any non-linear slopes with brakes. Best to reset that to 0 (straight). The word "sensitivity" is completely ambiguous and really can't be used. Does "too sensitive" mean a little touch makes it go too far, or does it mean that you can make very fine, sensitive, adjustments? I avoid the term just for this reason -- it can be interpreted in two completely opposite ways. FS's "sensitivity" basically divides the range of calibration. A low sensitivity merely stops you reaching the extremes, which is totally wrong in my opinion. The "sensitivity" adjustment in FSUIPC is the slope -- finer settings near centre, but faster near the extremes so you can reach maximum deflection. But this doesn't need apply to brakes -- unless maybe you've got an aircraft which easily flips tail over nose. No, neither. If the INput values are going haywire you probably need new pots. Check with CH, I think they are quite good at providing spare parts. Regards Pete joyview.zip

Rather than use equations wouldn't simply making a quick small change to the Mach setting, and back, work, if you've found that twiddling the knob re-computes the IAS target? At least that way the result would be correct according to FSX's equations (and approximations) rather than someone else's? I'll take a look. If I add this as a "Miscellaneous" fix it would only apply to Registered users. Is that what you would expect? These days, with SimConnect gradually taking over most of the application interface duties, I have to add as many benefits as possible for Registered users. Regards Pete

Good. However, it does mean, I think, that every call to scan for button presses is taking close to or more than 5 milliseconds when that driver is in use. Don't you notice any reduction in FS frame rates or smoothness when using the CH Manager? Regards Pete

Sounds like wind variance. Check the METAR report -- variable direction and the range is indicated in there. Or use WeatherSet and see the Variance column. Suppress it if you don't like it (in FSUIPC's Winds tab). I've not had much feedback on whether it is realistic or not, because it appears to be pretty infrequent except when the winds are very light (1-10 knots). What were yours? With the wind smoothing disabled, FSUIPC cannot simulate the three different wind effects, so you are left with FS's feeble efforts. Regards Pete

Please try this version of FSUIPC4.DLL: http://fsuipc.simflight.com/beta/FSUIPC4262.zip Looking at my code, the only real difference between the normal, operational, button scanning and the one in the Buttons & Switches TAB is that the former operates at a default of 20 millisecond intervals whilst the latter at 5 millisecond intervals. The reason for the faster scan rate is simply to give a better response when setting options -- I can't let it do that when you are actually flying as it would impinge on FS frame rates, but when in the Options Menu there's precious little else going on, so why not give a good response? So, I'm thinking that with the Control manager interfering with the "joyGetPosEx" pathways, that actual call is taking nearly or more than 5 milliseconds. So, as soon as it gets back from one call, it calls againresult: an apparent hang. Nothing else gets in because this is a high priority loop. In this version, 4.262, I keep the default at 5 mSecs, but if I don't see a regular Windows "Tick" message (which I should receive every 55 mSecs) within 100 mSecs I increase the time by 5 msecs. I keep doing this till I see a proper Timer Tick. I've tested this under simulation, but I'm afraid I've no way of testing it for real, so please let me know. Regards Pete

Okay. That gives some hope that I might be able to fix it, then. Pete

Unfortunately, just having the control manager loaded with a Map doesn't cause the problem -- the "Test/Calibrate" button in CHM just declares "there are no active devices" (of course, as I have none), so I guess that is the reason -- the Manager is not interfering with the standard Windows API calls made by my Button scanning dialogue. So, all I can do is try a few relatively minor changes, like trying to detect a fast repeating button and/or change the timing. None of this will work, though, if it is actually hanging inside the CH Manager -- I can only deal with it if it is a loop through my code. Meanwhile, can you both please use that Joyview program I supplied and see how that behaves -- it uses joyGetPosEx, like FSUIPC. It may say "None" for all the devices, but open them until you find those which respond to your CH devices. For example: Select the "joyGetPosEx() line and if there's a recognised device you'll get values in the "Value" column. They should change according to the axes, buttons etc on the device. Press buttons and the "Buttons" and "ButtonNumber" lines should change. Please let me know. Regards Pete

For most functions in FS you shouldn't need to use any "offsets". There are decent controls for nearly everything. SB3's use of offsets is private to that product, and not something I would know, not being an SB3 user, so help with such would have to come from the SB3 documentation or support. Byte is size 1, or 8 bits, SByte is the same but signed (i.e. can be negative) Word is size 2 ir 16 bits Dword is size 4 or 32 bits The parameter is the value -- the number to write to that offset or change bits in it. There's no general way of saying where it "comes from". That's a matter of you understanding what you want to do. If you don't understand any of this it is best not to mess with it. There are no functions of FS where you need to mess with offsets unless you are a programmer, and then you need the FSUIPC SDK. For PM you should refer to PM documentation or Support (or use the PM forums). For other programs, use theirs. I cannot support other follks programs, and support for FS is already achieved through proper controls. Why do that when you can use the built in FS control? "Fuel selector all"? Please do se the drop-down lists of assignable FS controls before trying to make life so complicated for yourself. You should not be messing with offsets is almost any case concerned with standard FS functions, which are all pretty well supported. I have no idea why you are going down this route. Leave that to the programmers for whom it is designed. Regards Pete

Ok, thanks. I'll try this today. Pete

Well, best if I could replicate it here. Do I need CH gear to run CH Manager? Can I download it anywhere and try it with an anonymous joystick do you know? If it is hanging inside CH Manager then there might not be a lot I can do to fix it, but I am willing to try. If I can't run it here I may ask you or Martin to test assorted changes for me. [LATER] I found the CH Control Manager on the CH website, downloaded and installed it, but it isn't giving me the same problem. This might simply be because I've got no CH devices -- though Martin did say he still got the problem when he unplugged all of his. The version I downloaded is 4.2. Is that the one you are using? I noticed other software on the CH download site too. Should I have any of that installed as well? Regards Pete

Well, that's really odd. In both cases you are getting a button press seen BEFORE the screen has even been properly updated. I assume you didn't press something? This is always indicative of a "stuck button", but in this case the button numbers are different -- joystick #1, button 19, then the same joystick, but button 32, which is actually the forward position on a Hat (a "point of view", POV). Which joystick is #1? You should be able to identify it either via the Axis Assignments dialogue, or using that Joyview program I provided. It looks as if it might be a good idea to identify that joystick, then uninstall it (from the Windows - Settings - System - Device Manager dialogue), driver as well, then re-install (after a re-boot). Just unplugging it didn't help, did it? Maybe that's a good test too -- unplug everything and run FSX again, see which "button" the log says then. I'll do some experiments here tomorrow. There haven't been many cases of "stuck buttons" -- continuous signals which effectively stop FSUIPC -- but enough to worry me. I'll see if I can detect such a condition and avoid hanging (e.g. after N repetitions of the same button, reduce the scan frequency or automatically mark it to be ignored). Regards Pete

It is based on the altimeter reading (not the true altitude) and the MCP altitude setting. It isn't a flag or a function of FS internals as such, but something operated by the gauge -- in this case the A/P or MCP (or of course PM for its external A/P). You have to compute it comparing the altimeter reading (offset 3324) with the AP altitude (offset 07D4, or, easier, the 16-bit integer value in the high part, 07D6. Note that 3324 gives feet or metres -- you'd need to check and covert appropriately. 07D6 (16-bit) gives metres. Regards Pete

Hmmm. That is sounding as if it is more related to some problem with Windows graphics libraries than it is to joystick drivers. What has changed on your system recently? You said this started when you updated to 4.26, but how long before that did you last go into the Buttons tab, and what was your previous version of FSUIPC? In the past there have been two otherwise apparently unrelated pieces of software which have done strange things like this -- one was Windows Blinds, and the other, strangely, a Kensington Mouse driver. Whatever, the problem in both was fixed by disabling that driver / service in Windows Management. Oddly this had no other effect, that the user's noticed at least. Also, if you are doing this in FSX full screen mode, try Windowed mode -- or vice versa. If there's a difference it is related to the video drivers. Okay. Thanks. Pete

Most all FSUIPC offsets provide or manipulate DATA, not FUNCTIONS. Functions are actions performed by software, such as gauges, PM, whatever. Tell me what DATA it is you are concerned about. If it is the AAMSL or AGL or Pressure Altitude, then all those are available of course. Pete

as it is looking as if it is not a simple matter of a rogue game driver (which is what it has been in the only earlier cases I know of), can I have more information now, please? Originally you said: By "as soon as" is this when you've pressed the Buttons TAB and before it actually draws the Buttons option dialogue, or after? If after, is there a joystick and button number shown on that screen, or is it blank? Please edit the FSUIPC4.INI file. Add these lines to the [General] section (this is before running FSX): Debug=Please LogExtras=2 LogButtonsKeys=Yes then run FSX and go to the Buttons option page. When it hangs, terminate FSX as you usually do, then show me the FSUIPC4.LOG file. Regards Pete

Uninstall is by deleting FSUIPC4.DLL, and putting it back reinstalls it. There's no registry involvement excepting an encoded Key check for your registration. FSUIPC has never expanded itself all over the place like other programs. Pete