Pete Dowson

I understand, but it is not something I've contemplated doing. No, it is not possible. Sorry. There are ways of sending FS controls at any point on an axis, but not to make a control (botton or key) change completely the range and calibration of an axis. Quite honestly, it would be quite a horrendous task to add such a feature to FSUIPC. There are plenty of good options for reverse engagement as it is. Don't forget even those aircraft with a really strong reverse would only need a very short range of travel - 20% at most of the overall axis range, and in reality much less as the speed control in reverse is rather, er, missing. In general, when using ony the one axis it is better to calibrate with that small reverse range, and perhaps make a detente position on your throttle lever slot to provide a positive idle position, one you can feel. That is easily done with a small piece of plastic or rubber, just to narrow the channel in which the lever moves very slightly. Regards Pete

Not silly, that's great news! Pete

That means PM is not writing it to FS. So it probably thinks it isn't in Heading Sel mode at all -- exactly as when LNAV is selected. I think you need to check all the things i mentioned. And sort it out with PM. It doesn't sound like anything to do with the CPFlight hardware, more likely incorrect modes in PM. You could test PM without the CPFlight hardware, just bring the PM MCP graphic on screen and test with that. And check those Annunciators! They tell you what is going on! Pete

Well, it would be easy if I could find out what CFG file FS is using. That's a problem, as it doesn't appear to be using the standard Private Profile calls any more. I've no easy way of even finding the routine it is using, not without a lot of hacking -- and it is a lot, because I've no idea either even which FSX module I'd need to look into. There looks to be another way, though. Instead of adding the [FSUIPC] section to the FSX.CFG file, you can make copies of FSX.EXE with different names, in your main FSX folder. When you run a renamed FSX it looks for aCFG file with the same name. For instance if you run "FSX_for_Props.exe" it will read (or generate) a file "FSX_for_Props.cfg" in the usual Documents & Settings folder. I think I can make FSUIPC4 determine the 'new name' for FSX and do something with that. e.g. strip "FSX" off if it is at the beginning and append the rest to the FSUIPC4 names, so in this example you'd get FSUIPC4_for_Props.ini FSUIPC4_for_Props.log and of course your Keys and personsal details in FSUIPC4_for_Props.key How does that sound? Regards Pete

The heading bug on the PM PFD, you mean? I think that simply matches the one on the PM MCP, the internal PM value. I assume you are in Heading Lock or Heading Sel mode, not LNAV? If the LNAV button is pressed, or PM thinks you are in LNAV, the heading on its MCP will not necessaily be the one written to FS. PM only writes the heading to FS is it actually is using it to control the heading. Assuming you aren't merely confused over these functions (please do double check the PFD annunciators to be sure), you still haven't stated the version of FSUIPC4, but if you aren't using 4.30 change to that first. Earlier versions are not supported. Then go to the FSUIPC4 logging page, and on the right-hand side enter these values to Monitor the FSX A/Ps heading: Offset 07CC, type UA16 (from the drop-down). In the checkboxes below, check "Normal Log" (you can also check "FS window" if you'd like to see it changing, or not, on screen). This will monitor changes sent to FSX for its A/Ps Heading value, which controls both its heading bug AND MCP heading display. It still sounds like confusion over what does what, but even if it isn't it is a matter for PM and/or CPFlight to resolve. There are a lot of CPFlight PM users -- just ask around in the PM Forums, and I've never seen anyone with a similar problem. Pete

If you are using Project Magenta you don't want or need the FSX MCP -- check the heading on the PM MCP or its PFD/ND displays, not in FSX. You shouldn't have PM's autopilot (MCP) and FSX's autopilot running together, but if you do you an FSX panel with an MCP, disreard it and only view PM's version. I thought you said you were using PM? This is rather confused. And if the FSX heading bug is changing, that, in FS, is exactly the same as its MCP heading display -- there's only one variable setting both. Sorry, I don't understand that part. A setting? A setting to do what, exactly? I think you need to explain in more detail, because I don't understand why you are bothering with an FSX panel if you are using Project Magenta. Are you simply getting confused between two separate autopilots? If they think there's a problem, maybe they can explain what it is a bit clearer? I have no such checker. Sorry, you are a little confused here. The list of correct versions for MY software is supplied in the Announcement for this purpose at the top of this Forum. you can easily find version numbers for my software, in logs, in documentation, on screen, or simply by right-clicking them and selecting Properties-Version. If you come back here please quote the versions number, but I suspect you should be asking your PM questions over in the PM forums. Regards Pete

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