Pete Dowson

Okay. I think the main difference is in how the axes directly assigned are sent to FS (by passing SimConnect now). Look out for an update later in the week - I'll see about making the POV axis assignment auto-repeat. Regards Pete

No. In fact you are expected to update your copy every time a new version comes out, as old ones 9and 3.70 is very very old) are not supported at all. The current version is 3.82. Just download it and install it as usual. And watch out for new versions now and then. Make sure you are using the latest WideFS too (6.75). FSUIPC4 is a separate product, but that is for FSX. Pete

Hmm. The WideServer support for KeySend was left in for existing users, but all KeySend support was moved to FSUIPC's buttons and key assignments facilities long ago, it being more useful (and user-friendly) there. That is unfortunately quite meaningless. "Last" meaning the "last one I downloaded", or what? Please, always quote version numbers. They aren't hard to find. All that does it tell FSUIPC to send FS that Keystroke when you press that button. How did you think it could ever reach a Client PC? Why not look this up in the documentation? The WideFS document does explain it. You assign your button (or a keypress if you like) to a "KeySend" control. In you case, the KeySend control with a parameter of 1 to invoke KeySend1, and 2 to invoke KeySend2. Surely that isn't really so difficult to understand now, is it? Leave your WideClient exactly as it was. Only the Server end is changing. nothing is different on a Wide client PC! Evidently. What about this part of the WideFS Technical Guide? Or this, in both the Keys and Buttons sections of the FSUIPC User Guide: Pete

Yes, without any repeats that's what I would expect. The Delta of 1 is okay, but it doesn't help with no repeats, and in any case POVs increase in 45 (6-way) or 90 (4-way) steps, usually. At least I've never heard of a 360 step one. Yes, nothing in that facility would be useful. I wouldn't expect it to be. Ah, that might explain the difference you see, somewhat. I think the FSUIPC repeat rate is more like 18. Before we do anything else, could you please move on to the currently supported version, 4.30. There are changes in that which may well affect all of this! Pete

[quote name="JamesChams" I use a TM HOTAS Cougar (USB) in Windows Vista Ultimate 64-bit with FSX Acceleration with the latest drivers. I updated the FSUIPC module yesterday from v4.28 to v4.30 and the module began giving me problems in FSX with the #2 engine of all my FSX aircraft when using this throttle. It caused a decline in the N1/RPM of what ever aircraft (Jet/Prop) in the #2 Engine when a full throttle setting is applied. The #1 Engine would ofcourse go to max NI/RPM. I've tried re-calabrating and adjusting the settings in Windows Game Controller' date=' FSX's Joystick settings, and FSUIPC's Joystick Calibration but with no success. So, I reverted back to version v4.28 to try and resolve this but I believed it corrupted the original setup.[/quote] "Corrupted"? FSUIPC will only ever save whatever changes you make. It doesn't make changes by itself. I think you must be misinterpreting something there. Sorry, I don't really understand what you mean, there. If they are all simultaneously assigned and active, to the same sets of controls, then yes, of course they will conflict with each other. This is why I added aircaft-specific axis assignment facilities to FSUIPC. Yes, of course, if you use FSUIPC for all assignments and disable joysticks in FS. That was the main reason axis assignments were provided in FSUIPC. Regards Pete

Does it work at all properly with PAN VIEW as an axis? It shouldn't, at present, because FSUIPC doesn't repeat values, it only sends changes -- from the lggoing it is obvious that FS makes use of the repeats. A keyboard repeat rate it normaly less than the Button repeat rate I use, so I don't understand that. Well I wonder too, but I don't understand how you got PAN VIEW working as an axis without it, in that case? If it is only the repeat rate which makes the difference I can probably speed that up, but I'd rather not. I currently operate repeats at about the same as the keyboard repeat rate, so it should be identical. I wonder if it is bunching up due to SimConnect latencies. If so a faster repeat rate wouldn't help, it might actually make it worse.. There's a point. What version of FSUIPC4 are you trying this on? Recent changes should make axis controls independent of SimConnect, but not normal button ones. I'm also a bit confused as to what other users, before you, have said it is smooth? Maybe something else in the system has a bearing on it? Pete

On FSX, yes. Offsets 1124 - 1138, as listed in the FSX Offsets Status document. Regards Pete

I don't fulloy understand what you mean by "giving it keys". The Zapper is an added FSUIPC control, assignable to keypress combinations or joystick buttons. If you are assigning key combinations which are already taken by higher-priority applications, (like, for instance, the Hot Keys in the hot keys tab in FSUIPC, or by other applications ahead in the keyboard queue), then although they may well be seen in the dialogue mode (because Windows directs them differently when in a modal dialogue window), they will be trapped into doing whatever action they are previously assigned for. If you don't think this could be the case, perhaps you could tell me what keypress combinations, exactly, you tried which didn't work? Possibly they included the ALT key? Unfortunately that usually invokes the menu so doesn't get passed correctly. I do warn of this in the documentation. Invoking the menu can be useful so it isn't prohibited. The FSUIPC controls provided aren't aware of how they are invoked, so the Zapper is completely and utterly independent of what keypress or button you assigned for it. If you were using keys with prior claims or other reasons for not working then this would apply to anything you assigned to them, not just the Zapper. Regards Pete

et cetera. These are exactly what FSUIPC could send if you programmed it to. i.e. instead of: 1=R0,32,C65734,0 ; PAN_UP 2=U0,32,C66416,-1 ; PAN_VIEW -1 3=R0,33,C65856,0 ; PAN_RIGHT_UP 4=U0,33,C66416,-1 ; PAN_VIEW -1 5=R0,34,C65672,0 ; PAN_RIGHT 6=U0,34,C66416,-1 ; PAN_VIEW -1 7=R0,35,C65857,0 ; PAN_RIGHT_DOWN 8=U0,35,C66416,-1 ; PAN_VIEW -1 9=R0,36,C65735,0 ; PAN_DOWN 10=U0,36,C66416,-1 ; PAN_VIEW -1 11=R0,37,C65855,0 ; PAN_LEFT_DOWN 12=U0,37,C66416,-1 ; PAN_VIEW -1 13=R0,38,C65671,0 ; PAN_LEFT 14=U0,38,C66416,-1 ; PAN_VIEW -1 15=R0,39,C65854,0 ; PAN_LEFT_UP 16=U0,39,C66416,-1 ; PAN_VIEW -1 replace the "C65734,0 ; PAN_UP" with "C66416,0 ; PAN)VIEW 0 and so on -- i.e. use PAN_VIEW commands (66416) throughout but with the different Degree numbers -- 0, 45, 90, 135, 180, 225, 270 and 315 for the 8 directions. You'll have to figure it out for yourself. I'm afraid I've nothing here that FSX properly recognises as a "hat" so I cannot do this for you. Let me know exactly what yo arrive at which works the way you want, and I'll update the examples. Did you try the axis assignment methjod I suggested? i.e. Mind you, this probably won't work as FS seems to rely on the axis repeating all the time, and FSUIPC cuts out repetitive values: possibly I should not do that for POV inputs. In fact I'll look at that next week. Maybe that will solve it in a tidier fashion. On this point: Well, you certainly have a throttle axis enabled somewhere -- and it is jittering between two values! But it doesn't have anytrhing to do with the present subject, you are right. Regards Pete

It sounds exactly like FS is assigning actions to your buttons too. Those are typical actiions for default assignments. If you want to assign via FSUIPC you have to unassign in FS. There's no way FSUIPC can prevent FS also reading the joysticks -- in fact any number of programs can read them simultaneously. Regards Pete

Erlet's not get too mixed up here please. When you say "key" do you really mean that word, or are you referring to your joystick button as a "Key"? If you want to program a Key press, on a Keyboard, to do the job you need to go to the FSUIPC tab for programming keypresses, not buttons and switches. One reads keyboards the other reads joysticks and the like. Maybe, if you are confused by all this, you should first peruse the FSUIPC User Guide? Please clarify. If, indeed, you do really mean "button" not "key" then we need to find out why your joystick isn't working. Regards Pete

I think FS treats it as an axis-type control rather than a set of buttons, and that is the difference. Try assigning it in FSUIPC's Axis Assignments instead of the Buttons section. If it is a proper DirectInput "POV" control" it should certainly be recognised. Assign it to the FS "PAN VIEW" control there. This is only applicable to FSUIPC4 at present. FSUIPC3 doesn't see POVs as Axes at all. [LATER] I have one idea which might help answer this. Do the assignment in FSX and enable both Axis Event and normal Event logging in FSUIPC4. Operate the view hat, see it working, then look at the log -- or show it to me. Maybe we can see what it is doing and emulate it. There are other axis controls for panning, ones for each direction, and these can be assigned in FSUIPC and calibrated. However, these would require a normal axis lever, one for each direction (well, at least left/right, up/down). But they are certainly smooth. Pete

It will only be greyed out till you press the button you want to program. You cannot program a "nothing". If FSUIPC doesn't see any button to program you cannot select an action for it, can you? Isn't that rather logical? You are in the wrong place for support for products other than my own. For FSUIPC instructions please refer to the FSUIPC User Guide. I cannot be responsible for instructions in other producer's documentation. If you do contact the correct support you might want to suggest to them that they provide an FSUIPC macro file, which will provide named controls specifically for their product. I have suggested this directly to the author, but I think he's been too busy. Pete

Are you by any chance trying it out on the Ground? Don't -- the lever will pass through the "ARM" position, and then FS, seeing that you have "landed" (!) will deploy them as spoilers, to 100%. I'm sure all this is in the documentation. The "centre" is the "ARM" position, so you can arm the spoiler for automatic deployment on the ground. Look at the Boeing quadrant in FS some time, you'll see in fact that there are two detentes -- the "Arm" and the "Flight" positions. I only provide a means of calibrating the arm position. You should of course limit the deployment in the air (i.e. as a speed brake) to the appropriate max value for the aircraft in any case -- e.g. about 65% for a 737 I think. Sorry, I never use view panning so I've no idea what looks smooth and what doesn't, but have you actually used the method suggested and recommended by other users? They say it is smooth. It is detailed at length in the latest documentation. Regards Pete

ASX uses SimConnect. If you give the Port which WideFS is using to SimConnect, it gets it first (because it runs before FSUIPC, of course). So when WideClinet sends to that port, SimConnect receives what is to it a complete load of rubbish, and sensibly closes WideClient's connection. There's no shortage of ports. ASX suggest 500 to be well clear of others in common use! Regards Pete

What version of FS and FSUIPC are you using? What has changed on your system since it worked? The facility uses exactly the same entry into FS as the Microsoft TrafficToolBox add-on uses if you elect to delete aircraft that way, so you could check if that is still working. Possibly your FS installation is corruptedbut without knowing what you've changed since it worked it is really impossible to hazard a guess. Regards Pete

So, what has changed? The software itself won't have changed. Are you sure you aren't trying to Zap static aircraft? That won't work -- they are really part of the scenery. Nor, in FS9, will it work on MP aircraft. Regards Pete

Yes, except that it isn't FS9 or FSUIPC doing the recognising, but Windows. Each key has a fixed keycode, and it is the keycodes which are sent as messages by Windows (WM_KEYDOWN and WM_KEYUP messages). If it sent different keycodes for different keyboards they'd look like different keys -- but that might not work either because there's a fixed list of Key Codes and programs generally wouldn't recognise one not listed as standard. As it is there's only room for 255 keycodes in any case, and that has to include NUM LOCK differences. Why not simple glue the shift key down on it, then, making all the keys shifted by default? Shift doesn't change the keycode, it only indicates the shift key is down too. Same with Ctrl, Alt, Alt Gr and the three Windows effects keys. It is possible to distinguish between left and right control and shift keys too, but not many programs do as it is usually too unwieldy for users. Not impossible maybe, taking over the keyboard completely as an input device with DirectInput, but it is very far from easy and would involve a huge amount of work,to make FSUIPC's keyboard input work like FS's joystick input. Check this: http://blogs.msdn.com/michkap/archive/292328.aspx . It does mention something about "raw input", but whilst that applies to joysticks and so on, I've never found anything of the sort for keyboards, and this: http://forums.microsoft.com/MSDN/ShowPo4&SiteID=1 argues how difficult it is. Even if it was done in FSUIPC, the keys would first be seen by FS in their normal state, just as joystick buttons and axes aren't exclusively ownable unless you get down to driver replacement. Regards Pete

I've had problems like this, with and without FSUIPC, though with my latest video card and 64-bit drivers they seem to be fully fixed. It is a problem between FSX and your video driver. It is nothing at all to do with FSUIPC, and any differences you do see with different versions of FSUIPC are merely down to slightly different timings or memory arrangements which that would cause. FSUIPC has nothing whatsoever to do with video modes or video displays and cannot interfere for good or bad. You've just been lucky before. I can only suggest you look for later (or possibly earlier) video drivers, or try changing some of the video settings. Sometimes just small differences like in the filtering will fix it. And when it does happen, getting FSX to reset the video data does usually work, too -- i.e. go into the video settings (Options -Settings - Display) and making one change someplace, like to filtering or Anti-Aliassing, will often bring everything back on exit. Regards Pete

Sorry, what is the question you are asking me? I'm not clear what you mean by "would I have stumbled over something here?" so I have no idea how to answer this, the only question I see. If it is just that you are confused over version numbers, all version 3.xx FSUIPC's are for FS9 and before. For FSX you must install FSUIPC4. I have no idea what that "FSFlyingSchool" folder is for, but if it talks about or includes FSUIPC version 3.70 it is pretty old -- 3.70 was released in July 2006 and was superseded by 3.71 in November 2006. All products which include a copy of FSUIPC are supposed to either provide the full package, including documentation, or at minimum a reference to where to get updates and the full package including documentation -- i.e. to http://www.schiratti.com/dowson Regards Pete

Why do you want to "open" anything? Don't! Refer to the FSX Help announcement, above. Follow the instructions provided there for repairing SimConnect. Pete

Erhow on Earth are you checking them before the PFC driver is running? The PFC menu appears when the PFC driver is loaded by FSUIPC4, and it has read the INI and initialised itself. None of that happens till a while after FSX is "ready to fly" as FSUIPC4 doesn't get sufficient data from Simconnect until then! FSUIPC4 is loaded by SimConnect when FSX is loading, but it has to wait until everything is ready before loading any other ancillary drivers. The same applies to WideFS initialisation, and subsidiary activities such as GPSout and AutoSave. This is simply because all of them are dependent upon the FSUIPC interface to SimConnect and that isn't fully viable until FSX is fully initialised and running with regular data exchanges. There's no difference in PFCFSX.DLL to the original PFC.DLL as far as INI settings and their operation are concerned. Only the interface to FS was changed, and rather than have multiple clients to SimConnect (very inefficient when they are all using the same data), PFCFSX is a wholly-owned FSUIPC client application, just as many external programs are. It is more efficient that it would be as an external program as it can access FSUIPC directly, but it still cannot do this until it is loaded and FSUIPC will not load things prematurely. I think you should re-enable the PFC connection checks, via the main PFC options screen. Leave them enabled so you can see when the PFC driver is loaded -- when that finishes its checks (or you force it to continue into FS via the button), it is all established. Having already waited 3 minutes for FSX to load, another few seconds should seem like no time at all! ;-) Regards Pete

"[Axes.Boeing]" is fine as long as all the aircraft titles have "Boeing" in them, and you have changed the "ShortAircraftNameOK" parameter from "No" to "Substring", as clearly documented. If all of the titles start with "Boeing" then you can have "ShortAircraftNameOK=Yes" instead -- but then it won't find it if the word Boeing is not at the start. Please do refer to the User Guide, and the new Appendix included in the latest releases. Regards Pete

I'll look at the multiple INI thing for FSUIPC4 next week. Certainly, if it isn't too complex I'll add it fairly quickly. Regards Pete

Yes. SimMarket will sort it out for you if you raise a problem ticket, or alternatively you can send both sets of details to me (full sets please) and say which one you would like changed. Send to petedowson@btconnect.com. Regards Pete