Pete Dowson

You'd be best off going ot the PMDG support forum. I expect there's lots of NGX users there. Most of the folks who've visited here seem to use Saitek throttle quadrants which feature a button on the pull-back position and they program that to send "throttleN decr" commands repeatedly whilst held. I don't know if any are successfully using a reverse throttle range, which is what SHOULD work with any FS reversers, but, PMDG being PMDG, maybe they block such? Assign a button (eg your A/T switch) to also send the Throttles Off and Throttles On controls which are listed in the assignments list. Did you not look? To add extra controls to an already-assigned button you would need to edit the INI file and add the assignments there. If this is beyond you, consider using another otherwise unused button. Pete

Great! Thanks for the fast turn-round. I'm set to do the documentation updates and get 4.86 full release out for Sunday or Monday now. Regards Pete

I think I've fixed it. It looks to be related to the "extended" flag, which I stupidly omitted to set for those keys which can be input from the NumPad and on the "extended keyboard" with their own dedicated keys. I've no idea whay this omission causes the odd thing to happen with the Shift key, but I suspect it's a quirk (rather than a design feature) of the way MS programmed their Key Input programming API. Whether it was always so, back to Win98 and so on, I don't know, but there have been no versions of FSUIPC ever which has attended to this flag, and it was never seen before as a problem (or at least not reported). So, I will also need to make the change to FSUIPC3 once it is verified by ypur tests. It does look okay here from the Logging, at least. Okay, thanks. Please download and install FSUIPC4859t_Test4.zip Regards Pete

Not sure why you'd need that. If the lever is calibrated correctly, with an adequate idle zone, the zero value for throttle being sent will set the thrttles to idle anyway. You shouldn't be thinking of key presses in any case for regular FS controls. F1 merely sends "Throttle_cut" for ALL throttles, which is surely not required in any case unless you are only using one throttle for all engines. You should be thinking in terms of the FS controls, and there are ones for each engine -- Throttle1 cut for engine 1, and so on. The only way to program an FS control to an axis is via the right-hand side of the Axis assignments tab. You can define a range of inputs which send a control depending on which way that range is entered. These input values are pre-calibration, so can encompass the idle zone which is all also calibrated for idle input. It was never so in any case. It is not relevant whether they are assigned in FS or in FSUIPC, the only thing relevant is HOW they are assigned. For AutoThrottle handling in the NGX without interference from the levers you either need to assign to the regular Axis_Throttle... controls, or use the special FSUIPC-added controls to disconnect your throttles in A/T modes and reconnect when disarming the A/T.. Also, I think (from other postings -- I am not an NGX user myself) that if you are using separate reversers then you set "No Reverse Zone" mode (NRZ) in the calibration tab, and "UseAxisControlsForNRZ=Yes" in the relevant JoystickCalibration section in the FSUIPC4.INI. All this is to do with how the NGX (specifically) works. All the regular ways FSUIPC has used for over 10 years seem to be deteated by their programming, without these various fiddles. Fully closed is done by proper idle calibration. Regards Pete

Actually, that is not the case. What is happening is exactly as depicted in the helpful logs provided by "georgefitz". His information along with your explanation about NUM LOCK has enabled me to reproduce it simply. If only someone had bothered to show me a log extract with the test version I made (4.859t_test3) then things would have been clearer sooner! I don't know why it is so difficult to get folks who have problems to run test versions and submit data. Here's what I get for a button programmed to send "Shift+Up" when NUM LOCK is on: 288337 [Buttons] 522=P175,0,K38,9 288337 SendKeyToFS(00040026=[shft+Up], KEYDOWN) ctr=0 288337 JoystickValues PCnum=0, dwCount=1, data[2]={000000af 00000001} 288337 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=2 288352 Sending WM_KEYDOWN, Key=38 (Scan code 72), Ctr=1 288383 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 288383 .. Key not programmed -- passed on to FS 288399 KEYUP: VK=16, Waiting=0, Spurious so ignored! 288399 KEYDOWN: VK=38, Waiting=0, Repeat=N, Shifts=0 288399 .. Key not programmed -- passed on to FS 288399 *** EVENT: Cntrl= 65608 (0x00010048), Param= 0 (0x00000000) ELEV_DOWN 288461 SendKeyToFS(00040026=[shft+Up], KEYUP) ctr=0 288461 Sending WM_KEYUP, Key=38 (Scan code 72), Ctr=2 288477 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=1 288493 KEYUP: VK=38, Waiting=0 [/CODE] You'll see the unwanted KEYUP arriving before the second KEYDOWN (the one for the Up key. With the Test3 version I supplied, this is detected as Spurious (as logged) and therefore not passed on. However, one thing I failed to recognise, until now I could reproduce it and get my own log, is that the "Shifts" flag is then not set on the KEYDOWN for the "Up" keycode. I don't know i it will help if I make my code add in the correct Shifts flag on this message. It looks like it depends on how the intended recipient detects the "Shift+Up" combination. FSUIPC does it by noting arrivals of KEYDOWNs for the shifts it supports (not only Shift, Ctrl, Alt, but also Tab, Windows and Menu). But if the recipient ignored the KEYDOWN for the Shift and only takes note of the flag setting, I can see why the above sequence is still a problem. The keycodes you are using are the ones produced by the separate cursor keys AND also the cursor keys on the NUMPAD when NumLock is off. I've no idea what in Windows is doing this strange thing with the Shift. I can see no purpose in it, no rhyme nor reason. I'll see if I can deal with the Shifts flag, and if so I'll post a Test4 version here. It'll need testing with a recipient add-on which needs these keys programmed. I don't think I have anything to test the results with here -- all my programs process the KEYDOWNs not the Shift flags. If i post a test version I'll need feedback and log extracts pretty quickly, please. i am planning on releasing 486 Sunday or Monday and I am going away on holiday later in the week. [ADDED LATER] Ouch. Looking at my logging code I realise the "Shifts" flag logged by FSUIPC is my owe interpretation of the Key States in any case, not part of the message itself. Seems I may need to did deeper ... probably need to experiment a little. Regards Pete

It is very gratifying to have satisfied users! Thank you! Pete

Never calibrate in PFCFSX with an add-on aircraft. It should be fine wth most, but it is designed for aircraft which abide by normal FS controls and methods, which the NGX does not. You should have mentioned that you were not using a normal FSX aircraft. PFCFSX has no flexibility, it is designed for easy and standard FS methods of control. The NGX is non-standard in many ways. FSUIPC has many options and can be configured to suit almost any aircraft configuration, most of which had not been dreamed of when the serial port PFC gear was designed and my PFC drivers were developed. Pete

If you calibrate an axis, you have a range of numbers, coming from the hardware, mapped to the range of numbers needed by the specific FS control being assigned. That's all there really is to it. If you end up with restricted range or no range at all, then either the calibration was not done correctly, or the input itself is faulty -- i.e. either not varying, or varying inconsistently. So, if you do believe you've calibrated correctly yet still have a problem, then I think you need to contact the hardware supplier with a suspect unit. There's really no more advice I can give you. I'f you'd like to actually quote some real numbers I'd be glad to compare those with the numbers for the different PFC throttle control systems I have here.so we can see how wacky yours really are. The max range for each of the 6 possible axes is 0 to 127, but most seem to give something more like 10 to 115. And then you should always leave a dead zone at eaither end, so 15 to 110 probably min to max. Regards Pete

"Defaut calibration"? What's that? You MUST calibrate!!! The point of calibration is to make the actual input from an axis match the desired output. If you don't calibrate you suffer whatever vagaries individula hardware is subject to! Please try reading the user guide and follwing the details there. Pete

But you only needed to extract the parts from where you initiated the action which goes wrong, and where it finished. And I am still completely unclear on what your problem is, because you never really explained it. I thought the problem was the same as the second poster, "georgefitz", but if so I was only waiting for your confirmation that the work-around I included in 4.859t_Test3 worked for you too. In what way can a Key interfere with FSUIPC? I don't know what you think is wrong. FSUIPC is just working with what Microsoft calls "Virtual Keycodes". The keycodes used are listed in the Advanced Users manual, and the list is a direct copy of MS's dcumentation for these. What other ways do you feel there are of sendng keypresses other than by the keycodes? Those are the parameters used in the WM_KEYDOWN and WM_KEYUP messages. There are no altrernatives. You'll need to explain still, I'm afraid. Regards Pete

It sounds like you have it configured to address a port which has a bad or corrupt dribver. You don't say anything about any details of how you are configuring it. GPSout, unless configured to send the data over a Network via WideFS, simply sends data to the Windows Serial API, designed for COM devices. What then happens is completely dependent on the driver for that device. GPSout doesn't care about that side of things, it only shoves data out the door. Pete

If a joydstick doesn't work in FS it is not very likely that FSUIPC can perform any magic to make it work. It may just be that you still had assignments to the previous joystick and its driver was somehow still active. All of FSUIPC's settings are contained in only one file, the FSUIPC.INI file -- configuration settings. In the same Mondules folder. You could simply edit it and delete the unwanted assignments, or delete the whole file if you want to make a fresh start. Pete

Since rudders and brakes are button-less and are only 3 axes to set up, I would say it would be best to just start afresh. If you have keypresses and other options set up just as you like them, just edit the FSUIPC4.INI file, deleting the [buttons ...], [Axes...] and [JoystickCalibration ...] sections only. If you don't really have any serious assignments or settings you need to keep, just delete the entire INI file before running FSX, and let FSUIPC build a new one. You don't need to reinstall anything. The INI is produced when FSUIPC is next run. Regards Pete

And what IS "the latest version", please? Always state the number. Is it 4.859t_Test3, or 3.999y5, or something older? You don't even say which Flight Simulator you are using. No, but I don't know any easy way you could "mess things up" in order to achieve such a delay. Have you actually checked to see if the FS-depicted throttles move in concert with your hardware ones? They should do. If you've not checked, do so now. The only ways you can get them to operate separately is by either assigning them to, say, a plug-in which processes them separately, or an offset processed by some third party program, or possibly by having them disconnected by the special FSUIPC axis disconnection facilities and then processed by such a third party program. None of this is achievable without you specifically programming it or running an add-on which is doing it . If you have filtering enabled, disable that. It can cause a small delay (a fraction of a second, though, normally. Certainly never 10-15 seconds! I know nothing which will do that if not deliberately programmed! Pete

No. Just tun the installer. It merely replaces the DLL itself with a new one, and replaces the contents of your "FSUIPC Documents" folder with updated documents and accessories. It doesn't touch your settings, and you don't need to re-register, just Cancel when the Installer gets to the Registration page. Pete

Actually, checking into this further, I found that this really isn't a problem. The only differences arise when the Windowed mode window is a lot different in size, position (not centralised) or shape to the full screen. Then, when you first switch from one to the other, the initial position found for "mouse look" is wrong as the mouse position is relatively changed. If you are only using mouse look in either Windowed or full screen mode they both act properly and as expected, and identically to FSX's own version of the facility. When switching between modes there's a temporary dislocation which i do not think warrants attention. Regards Pete

Depending on the specific virtual cockpit, the "eyepoint reset" position may not be in the same place in full screen and Windowed modes. However, it must still move as you drag the mouse holding the middle button down. Merely pressing and releasing the middle mouse button does NOT engage mouse look mode -- if something is happening when you do that then it is some other action taken by something else. Mouse look needs the button held. I will look to see if I can make the initial "centre" position more consistent with Wndowed mode, but I am not sure this is possible. However, there's no way to change the way it then operates. I think you must be misunderstanding the facility itself. Regards Pete

Have you tried using the "spoofing" facility for offsets using the special facilities provided for use in a Lua plug-in? Please check out offset 0024 for writing. If you look in your FSUIPC Documents folder you will find an example Lua plug-in called "Liar.lua" which is actually much more advanced than your needs, but which will certainly give you the idea. Regards Pete

Sorry, but you've still lost me with this. I don't understand any of what you say. All I really need to know is what IS the problem? In the log you provide I've no idea wehat is supposed to be happening and what is wrong because i don't see any Buttons assigned to send ketystrokes. If you are sending them from a Lua plug-in I need to see what you are actually doing there at each stage in your log. The sequences which include Shift seem to be fine. For instance, here you have Shift pressed whilst 'Z' is pressed and released twice giving two Shift+Z's. 988485 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 988485 .. Key not programmed -- passed on to FS 988735 KEYDOWN: VK=90, Waiting=0, Repeat=N, Shifts=1 988735 .. Key not programmed -- passed on to FS 988829 KEYUP: VK=90, Waiting=0 988922 KEYDOWN: VK=90, Waiting=0, Repeat=N, Shifts=1 988922 .. Key not programmed -- passed on to FS 989079 KEYUP: VK=90, Waiting=0 989079 KEYUP: VK=16, Waiting=0 Here's a case of an actual button pressed, programmed to send Ctrl+Shift+3: 1034938 Button changed: bRef=0, Joy=3 ©, Btn=12, Pressed 1034938 [buttons] 6=PC,12,K51,11 1034938 SendKeyToFS(00060033=[ctl+shft+3], KEYDOWN) ctr=0 1034938 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 1034938 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 1034954 Sending WM_KEYDOWN, Key=51 (Scan code 4), Ctr=1 1034985 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 1034985 .. Key not programmed -- passed on to FS 1034985 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 1034985 .. Key not programmed -- passed on to FS 1034985 KEYDOWN: VK=51, Waiting=0, Repeat=N, Shifts=3 1034985 .. Key not programmed -- passed on to FS 1035047 SendKeyToFS(00060033=[ctl+shft+3], KEYUP) ctr=0 1035047 Sending WM_KEYUP, Key=51 (Scan code 4), Ctr=3 1035063 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 1035063 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 1035094 KEYUP: VK=51, Waiting=0 1035094 KEYUP: VK=17, Waiting=0 1035094 KEYUP: VK=16, Waiting=0 1035141 Button changed: bRef=0, Joy=3 ©, Btn=12, Released and that all went perfectly too. Everything looks as if it worked exactly correctly, so I am at a loss to know what your problem really is. Can you explain at all? Regards Pete

I'd really prefer that you state your questions here if you want answers. It is almost a full time job doing this support as it is without needing to refer to other threads in other forums. If you are asking simply about assigning keystrokes to buttons then a registered copy of FSUIPC can do this very easily. Please do refer to the User Guide. If you don't want to use WideFS as you say, your buttons need to be seen as hardware buttons, because a touch screen will take focus off FS if it is on the same PC, as you seem to imply. How are you using the touchscreen in any case on the same PC? Pete

Sorry, I don't know what you really mean by "it works when I press the middle button once, but then it stays there and doesn't move". There is absolutely no difference whatsoever in the FSUIPC code for mouse move no matter what Window/Full screen mode is selected. The differences, if any, will be a property of FS itself of the specific panels. Mouse look works perfectly here in full screen mode with the default aircraft VC panels. Perhaps you should do some more checking on this? There's really no way I can change the way it works at present as there's no alternative way of doing it. I always use full screen mode and have never had any problems, I'm surprised you've only been using Windowed mode, in fact. Spollers assigned in FSUIPC, whether to FSUIPC calibration direct, or to the FS "Axis..." control, are certainly perfectly reversible. I honestly don't know how you are managing not to get this as it is exactly the same as for all other axes and has been working perfectly in all versions since it was introuduced. It is perfectly simple, it simply changes the sign: -16384 becomes +16384 and vice versa. There is nothing to go wriong! Don't forget you will need to re-calibrate after reversing. Also be aware that assignng in FS, rather than FSUIPC, could result in a double reversal, since FS also has a reverse function. If you are still convinced there are such elementary problems in FSUIPC I will need a lot more information. I've even re-checked here with no problems whatsoever. I am in the middle of preparing the next major release, 4.86, so that folks won't need to download both installer and update, and I could do without unjustified complaints. Please always provide the evidence and means of reproducing problems so I don't have to waste so much time and energy re-checking and refuting them. Thank you. Pete

Hi Chris Happy New Year to you. Hope you are well! Of course it may not actualy be related to the VRS, it may just be a coincidence that the two posting here are both running it. It is also not clear to me at present what problem the original poster is suffering from. -- the second one, the only one to provide helpful evidence so far, seems to now believe that it is something to do with sending Shift+Delete only. The odd and apparently spurious WM_KEYUP occuring for the shift is the problem. I believe the code I put into the test test version of FSUIPC4 ("4859t_Test3") should do the trick, but I've not received confirmation yet, which is why 4.859t is not yest released except here. I'm afraid I can't really help narrow down the cause since I have no means of re-creating the symptoms here. Best Regards Pete

You mean in FSUIPC, running in the FS process? I'd really rather not. Both the "wnd" and "display" activities are designed to be run in a separate process to FS. I certainly would not do it for FSUIPC3 in any case. Possibly FSUIPC4 (for FSX and beyond), but it won't be doable in the near future I'm afraid. You can run WideClient on the same PC as FS by simply changing the "ClassInstance" parameter in its INI file to a non-zero value. Applications won't connect to it at all, but you can use its ButtonScreen and Lua plug-in facilities. I realy think this would be a better solution than lumbering up FS with such extra weights. Regards Pete

You missed the Announcements and pinned threads here, at the top, telling you that you need to replace the DLL with at least 3.999y5 from the Download Links subforum if you are using a 2013 registration. I'm working on making a new main release, but in the meantime the updates here are your friends. It's always a good idea to check for updates in any case, which are always in the Download Links subforum. Pete

Both the pausing and the sound loss are evidently due to the same thing: Something you are running, somewhere in the computer, is periodically taking the Windows focus -- same as clicking on another program entirely. It is probably not even anything to do with FS. It will be a separate process. Check what you have running on your PC as well as FS. Pete