Pete Dowson

You can only program a button which you can operate. Press a button and it will show its joystick and number at the top. then decide whether to assign a control or keypress. You cant decide till you have a button to program. The User Guide explains it. Pete

No, it uses a different braking method, one originally used in FS98/FS2000. What is your fascination with slopes, and why on brakes? Really they were only ever designed for aileron, elevator and rudder sensitivity adjustment for different aircraft types. You don't need that with brakes. You want brakes to be proportional. Anyway, surely you should actually try things out before fiddling around. Seems rather odd to decide in advance that you need to tweak something without any basis for thinking that. Pete

Sorry, you have now lost me completely. What "request"? What is all this about, and how does it relate to all the preceding interactions? Are you testing with 4.859t_Test3? Why have you not even supplied the log file requested in my original reply to you. But not with anything earlier than the Test3 version as mentioned. You seem to be ignoring what has occurred and where the problem appears to lie -- with the VRS it seems. I am merely trying to find a work around. Pete

Okay. My error. There was one other place where a KEYUP could be sent which also needed the flag cleared. Sorry about that. Try FSUIPC4859t_Test3.zip Regards Pete

The list is computer-generated from the actual tables. I suspect therefore that these are simply different names for the same actions. I think the 'carry' ones were the names from FS98 or FS2000 days, the other names are later. Note that there's also "ADF FRACT DEC CARRY" and "ADF FRACT INC CARRY" (66461 and 66462) which might be the corrected positions for the older names. Probably best to stick to the newer names. I'll eliminate the older ones in the next update. Regards Pete

Could you test without that DLL please? Sorry, you are confusing things now. You are saying it all worked before i changed it? So why did I bother? Please explain. Okay. That's useful information. Thanks. The log shows the new mod in operation: The CTRL+RGHT worked okay, as before: 49047 [buttons.Flight Test Aircraft E1] 40=P0,16,K39,10 49047 SendKeyToFS(00020027=[ctl+Right], KEYDOWN) ctr=0 49047 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=2 49063 Sending WM_KEYDOWN, Key=39 (Scan code 77), Ctr=1 49094 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=2 49094 .. Key not programmed -- passed on to FS 49094 KEYDOWN: VK=39, Waiting=0, Repeat=N, Shifts=2 49094 .. Key not programmed -- passed on to FS 49156 SendKeyToFS(00020027=[ctl+Right], KEYUP) ctr=0 49156 Sending WM_KEYUP, Key=39 (Scan code 77), Ctr=2 49172 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=1 49203 KEYUP: VK=39, Waiting=0 49203 KEYUP: VK=17, Waiting=0 49250 Button changed: bRef=0, Joy=0, Btn=16, Released The SHIFT+CTRL+1 looks wrong though. 54414 [buttons.Flight Test Aircraft E1] 48=CP(+0,23)0,36,K49,11 54414 .... Condition (+0,23) = TRUE 54414 SendKeyToFS(00060031=[ctl+shft+1], KEYDOWN) ctr=0 54414 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=3 54414 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=3 54429 Sending WM_KEYDOWN, Key=49 (Scan code 2), Ctr=1 54460 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 54460 .. Key not programmed -- passed on to FS 54460 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=3 54460 .. Key not programmed -- passed on to FS 54460 KEYDOWN: VK=49, Waiting=0, Repeat=N, Shifts=3 54460 .. Key not programmed -- passed on to FS 54460 LUA.0: beginning "C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\panning.lua" 54460 LUA.0: ended "C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\panning.lua" 54523 SendKeyToFS(00060031=[ctl+shft+1], KEYUP) ctr=0 54523 LUA.0: beginning "C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\panning.lua" 54523 LUA.0: ended "C:\Program Files (x86)\Microsoft Games\Microsoft Flight Simulator X\Modules\panning.lua" 54523 Sending WM_KEYUP, Key=49 (Scan code 2), Ctr=3 54538 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=2 54538 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=2 54570 KEYUP: VK=49, Waiting=0 54570 KEYUP: VK=17, Waiting=0 54570 KEYUP: VK=16, Waiting=0, Spurious so ignored! That should NOT have been ignored ... it was one sent by FSUIPC. Strange, ctrl+Shift+1 works fine here. I'll investigate this now. Here's the Shift+Delete showing the CORRECT spurious KEYUP being ignored: 63352 [buttons.Flight Test Aircraft E1] 55=P0,0,K46,9 63352 SendKeyToFS(0004002E=[shft+Del], KEYDOWN) ctr=0 63368 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=2 63384 Sending WM_KEYDOWN, Key=46 (Scan code 83), Ctr=1 63415 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 63415 .. Key not programmed -- passed on to FS 63415 KEYUP: VK=16, Waiting=0, Spurious so ignored! 63415 KEYDOWN: VK=46, Waiting=0, Repeat=N, Shifts=0 63415 .. Key not programmed -- passed on to FS 63462 SendKeyToFS(0004002E=[shft+Del], KEYUP) ctr=0 63462 Sending WM_KEYUP, Key=46 (Scan code 83), Ctr=2 63477 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=1 63508 KEYUP: VK=46, Waiting=0 So that should have worked okay. Did it not? Oddly though it was folowed by a very short press of the Shift key before the process ended. I'm wondering if that's due to the outstanding KEYUP from the red marked ignoring action above. 63508 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 63508 .. Key not programmed -- passed on to FS 63508 KEYUP: VK=16, Waiting=0, Spurious so ignored! and this KEYUP was also ignored. The Shift key is now stuck down, so the remaining non-shifted keys will not give the desired results. I assume this resulted in you holding it down, here, in order to clear it? 69483 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 69483 .. Key not programmed -- passed on to FS 69982 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1 69982 .. Key not programmed -- passed on to FS 70029 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1 70029 .. Key not programmed -- passed on to FS 70092 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1 70092 .. Key not programmed -- passed on to FS 70138 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1 70138 .. Key not programmed -- passed on to FS 70185 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1 70185 .. Key not programmed -- passed on to FS 70232 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1 70232 .. Key not programmed -- passed on to FS 70279 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1 70279 .. Key not programmed -- passed on to FS 70341 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1 70341 .. Key not programmed -- passed on to FS 70388 KEYDOWN: VK=16, Waiting=0, Repeat=Y, Shifts=1 70388 .. Key not programmed -- passed on to FS 70388 KEYDOWN: VK=46, Waiting=0, Repeat=N, Shifts=1 70388 .. Key not programmed -- passed on to FS 70887 KEYDOWN: VK=46, Waiting=0, Repeat=Y, Shifts=1 70887 .. Key not programmed -- passed on to FS 70934 KEYDOWN: VK=46, Waiting=0, Repeat=Y, Shifts=1 70934 .. Key not programmed -- passed on to FS 70996 KEYDOWN: VK=46, Waiting=0, Repeat=Y, Shifts=1 70996 .. Key not programmed -- passed on to FS 71043 KEYDOWN: VK=46, Waiting=0, Repeat=Y, Shifts=1 71043 .. Key not programmed -- passed on to FS 71090 KEYDOWN: VK=46, Waiting=0, Repeat=Y, Shifts=1 71090 .. Key not programmed -- passed on to FS 71090 KEYUP: VK=46, Waiting=0 71449 KEYUP: VK=16, Waiting=0, Spurious so ignored! But yet again it was ignored. Somehow the flag telling the routine to ignore the Shift KEYUP is stuck "on". i'll check. Let me know how you get on with VRS support. Regards Pete

You shouldn't need a slope on the brake axis for PFC pedals. Proper calibration with a small dead zone at either end is good. PFCFSX applies the brakes in a different way to the standard brake axes used for FSUIPC assignments. But if you wish to use FSUIPC facilities instead, yes, you can inhibit the exis in the PFC driver and assign in FSUIPC instead. Your choice. the same applies to any PFC axis, but you do need to inhibit them in the PFC part if you are doing that. Button assignment is different, the FSUIPC assignment can override the PFC one. Pete

So, you have two loading fine. Are you actually expecting any of the others to have entries in the Add-Ons menu? Maybe they don't? I'm sorry, but I don't know those products so I don't know what you are expecting. IO think you need to talk to their support, or at least check their documentation. No, I only meant that the three SDK tools are not only installed, but enabled. If you aren't using them it would be best to disable them -- change the <Disabled>False</Disabled> line to <Disabled>True</Disabled> in each of the three relevant sections. Regards Pete

I'vw moved this Thread to the Support Forum, where it belongs! Pete

Good. Thank you for getting back to confirm so quickly. I am awaiting news of another 'fix' I included in that version, and if that's okay too I will upload version 4.859t as the 'current release'. After that I must get busy updating the documentation so I can release 4.86 with its Installer. Regards Pete

The OP also said "I use FSX with VRS Tacpack", so that's a distinct posibility. What is it, an aircraft? If so, does it have a DLL or EXE running? Let me know what happens with the test version of FSUIPC please. Pete

Okay. I found one possible weakness in my code, one which might allow the actions of another add-on to cause Mouse Look to be enabled incorrectly. This looks like quite an unlikely circumstance, but as it is a possibility I've fixed it. I've also added logging in case this fix doesn't work. So: Please try FSUIPC4859t_Test2.zip and let me know. If it still doesn't work correctly, please do this: Before running FSX, edit the FSUIPC4.INI adding this to the [General] section: Debug=Please LogExtras=129 Run FSX and get the problem. Close FSX, and paste the resulting FSUIPC4.LOG file contents into a message here. Thank you, Pete

Okay. Whilst i cannot reproduce it, I think I can stop it happening by deliberately "swallowing" the excess Shift KEYUP messages. I'd still like to know where those come from (it definitely is not FSUIPC), so please do provide the extra info I asked for. but meanwhile please try this test version of FSUIPC4 and let me know: FSUIPC4859t_Test2.zip Thanks. I'd like to see the log 9with the same options as above) whether it works or not. Regards Pete

No, I cannot reproduce this behaviour. I'm sure it must be something else on your system which is cancelling the Shift with a Shift Keyup message, but I've no idea what that could be nor why it would do it. Since there are two of you reporting this (though so far no confirming log has been supplied by the original poster), I hope that if you both list your addons we might find something in common between them which could help to explain it. Regards Pete

Hmm. Interesting. Here is a place where you pressed a button which invoked Shift+something 407225 Button changed: bRef=0, Joy=0, Btn=0, Pressed 407225 [buttons.Flight Test Aircraft E1] 55=P0,0,K46,9 407225 SendKeyToFS(0004002E=[shft+Del], KEYDOWN) ctr=0 407225 Sending WM_KEYDOWN, Key=16 (Shift) (Scan code 42), Ctr=2 407241 Sending WM_KEYDOWN, Key=46 (Scan code 83), Ctr=1 407288 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 407288 .. Key not programmed -- passed on to FS 407288 KEYUP: VK=16, Waiting=0 407288 KEYDOWN: VK=46, Waiting=0, Repeat=N, Shifts=0 407288 .. Key not programmed -- passed on to FS 407335 SendKeyToFS(0004002E=[shft+Del], KEYUP) ctr=0 407335 Sending WM_KEYUP, Key=46 (Scan code 83), Ctr=2 407350 Sending WM_KEYUP, Key=16 (Shift) (Scan code 42), Ctr=1 407381 KEYUP: VK=46, Waiting=0 407381 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=1 407381 .. Key not programmed -- passed on to FS 407381 KEYUP: VK=16, Waiting=0 407428 Button changed: bRef=0, Joy=0, Btn=0, Released The blue parts are where FSUIPC is sending the eyacyions. You will see that they are precisely what was called for. The red parts are just FSUIPC logging the arrival of the Keyboard events into FS. Now you see that somehow additional KEYUP events are occurring for the Shift key. It is this which is ruining the outcome! A different example, with Ctrl+something looks different (correct): 415821 Button changed: bRef=0, Joy=0, Btn=16, Pressed 415821 [buttons.Flight Test Aircraft E1] 40=P0,16,K39,10 415821 SendKeyToFS(00020027=[ctl+Right], KEYDOWN) ctr=0 415821 Sending WM_KEYDOWN, Key=17 (Control) (Scan code 29), Ctr=2 415837 Sending WM_KEYDOWN, Key=39 (Scan code 77), Ctr=1 415868 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=2 415868 .. Key not programmed -- passed on to FS 415868 KEYDOWN: VK=39, Waiting=0, Repeat=N, Shifts=2 415868 .. Key not programmed -- passed on to FS 415962 SendKeyToFS(00020027=[ctl+Right], KEYUP) ctr=0 415962 Button changed: bRef=0, Joy=0, Btn=16, Released 415962 [buttons.Flight Test Aircraft E1] 40=P0,16,K39,10 415977 Sending WM_KEYUP, Key=39 (Scan code 77), Ctr=2 415993 Sending WM_KEYUP, Key=17 (Control) (Scan code 29), Ctr=1 416024 KEYUP: VK=39, Waiting=0 416024 KEYUP: VK=17, Waiting=0 I don't understand how this is occurring, I've not seen such before. I'll see if I can reproduce it here, but please, also, tell me what other things you have running inside FS, what other add-ons. Regards Pete

As Ian says, you need to update to at least 3.999y5. There's a pinned Notice at the top of the Forum about this -- also in the Announcements subforum. Regards Pete

Unfortunately I cannot see anything else it could be. There's something very very strange in your system. The FSUIPC mouse look facility has been used by many folks and has been working well ever since it's release many months ago. The only recent change was to make it work in certain other circumstances too, such as when using the FSUIPC Loader. I have all those too. No problems. No, sorry. I am at a loss. I'll think about what can be done to find out what is going on in your system. I might have to put in lots of extra logging to see what is happening. But I can't do this in a hurry. I'll think more tomorrow. Pete

Hmm. So it is something else installed into FSX which is causing the problem. The only way to get the results you described would be for that Middle Mouse Button to appear to be pressed all the time. What else do you have running? Try running with just FSUIPC4 installed to start with, then add others one at a time. I'd like to know which prodct is so incompatible. I have prepared a version of FSUIPC for you which has an option to ignore the middle mouse button altogether. With that option you'd have to assign the controls, or use the FS one (not recommended). FSUIPC4859t_Test.zip Install that in the modules folder, then, before running FSX, add NoMiddleMouseButton=Yes to the [General] section of the FSUIPC4.INI file FSUIPC is merely the DLL in the Modules folder. Installing an update is merely copying a DLL into that folder. Uninstalling is merely deleting the DLL from that folder. Replacing the DLL with another identical DLL does nothing. Regards Pete

Well, it's possible I suppose. I don't have access to any version before SP3 I'm afraid so I can't tell. Maybe some of the improvements i've put into FSUIPC in the last year have made use of things which weren't in even XP before SP3. I've not done so deliberately, and if I could identify what it might be I'd try and make it optional somehow, but I'm not able to find out without knowing what your Windows obviously knows but isn't telling! I think it would be a good idea for you to update Windows in any case. Regards Pete

No, but ALL of your symptoms suggest that the middle mouse button is appearing stuck on. With it like that the mouse look mode is permanently engaged irrespective of the other controls you attempt. Try unplugging the mouse and rebooting the system without it. Does that stop the strange symptoms? Or do you have some sort of mouse mode enabled on another device, like a little hat or something on a joystick? If you can't find out what is going on I can only suggest that I provide a version of FSUIPC4 with an option to ignore the middle mouse button. Then you can only handle the mouse look via the controls. Pete

I cannot support versions earlier than 4.853. The latest is 4.859s, from the Download Links subforum. How do you tell? Why not use the button/keyl ogging as requested earlier in this thread -- or did you not read the thread before posting? I can't help you without information. Sorry. Pete

I understand that, and this is exactly why I implemented mouse look in FSUIPC! That's what you said, but i've never had anything like that reported before, and the mouse look facility has been in FSUIPC since version 4.84, back in July 2012. As I said, it doesn't do anything unless engaged, either by using the FSUIPC-added "mouse look" controls, or the original FSX mouse look toggle, or by pressng the middle mouse button. In that case, either you have engaged mouse look mode, either using the FS control (assigned to SPACE bar), or using one of the added FSUIPC controls "Mouselook On" or "Mouselook toggle", or your middle mouse button is appearing pressed all the time. By default the facility works already with the middle mouse button. I've told you this already. To switch the mode on or off, separately, it would be best either to assign the SPACE bar to "mouselook toggle", so it directly controls the FSUIPC facility, or, at least, to de-assign the SPACE bar in FS so it's own control isn't being sent, then assign Mouselook On, mouselook off, or mouselook toggle to keys or buttons as you wish. Pete

Sounds like Mouse Look isn't compatible with your other add-ons? However, it certainly doesn't do anything without the middle button being pressed, so you have something else going on. Sorry, but what was wrong, what did you change? There's nothing to "make it work correctly". It will either work, or it won't. There are no options. The menu bar is nothing to do with any of this. Just hold the ALT key down to see the menu bar! The default mouse look option in FSUIPC only operates when you hold the middle mouse button down. You don't need to disable it UNLESS you want to use the middle button for something else. There's no option for that. What else are you using the middle mouse button for? Pete

Sorry, typo. Sorry, I've no way of proceeding on this, unless you can find details of why Windows won't let FS load it. Did you look for messages in the Windows error logs? I have a PC here running Windows XP SP3, like you (at least that's what FSUIPC thinks you are running), and it is fine with 3.999y5. I can't add code to FSUIPC to find out why it won't load because if it isn't loading any code i add can't run. Windows error logs are accessed via: right-click on My Computer, select 'Manage', then Event viewer, then Application. see if you can find reports referring to FS9 or FSUIPC. Pete

Do you know that they ought to have entries there? Not all SimConnect-started applications use the Menu system, and some that do have their own entries not in Add-Ons. That's a question for Squawkbox I'm afraid. I don't use it. Well, i'll have a quick look. The SimConnect.cfg file isn't needed, and shouldn't really be there, unless you are trying to use SimConnect over a Network. <Launch.Addon> <Name>Audio Environment Module</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>C:\Program Files (x86)\Flight One Software\Audio Environment\AEMODULE.dll</Path> <DllStartName>module_init</DllStartName> <DllStopName>module_deinit</DllStopName> </Launch.Addon> [/CODE] That entry looks okay. Is that DLL loading? Is it in the folder it says? [CODE] <Launch.Addon> <Name>FeelThere PIC737X v2 Helper</Name> <Disabled>False</Disabled> <Path>FeelThere\B737 v2\PIC737XH.dll</Path> </Launch.Addon>[/CODE] Same with that one. [CODE]<Launch.Addon> <Name>FsPassengersX</Name> <Disabled>False</Disabled> <Path>FsPassengers\bin\fspassengersx.dll</Path> </Launch.Addon>[/CODE] And that one. [CODE]<Launch.Addon> <Name>FSUIPC 4</Name> <Disabled>False</Disabled> <Path>Modules\FSUIPC4.dll</Path> </Launch.Addon>[/CODE] That's FSUIPC4, and you see that, so the DLL.XML file is fine to here, at least. [CODE]<Launch.Addon> <Name>Object Placement Tool</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>..\Microsoft Flight Simulator X SDK\SDK\Mission Creation Kit\object_placement.dll</Path> </Launch.Addon>[/CODE] That one needs checking. It's part of the FSX SDK. Did you enable it? [CODE] <Launch.Addon> <Name>SquawkBox AI Control</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>C:\Program Files (x86)\SquawkBox\sbaicontrol10.dll</Path> </Launch.Addon> <Launch.Addon> <Name>SquawkBox Internal Version</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>C:\Program Files (x86)\SquawkBox\sbmod10.dll</Path> </Launch.Addon> <Launch.Addon> <Name>SquawkBox Transponder</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>C:\Program Files (x86)\SquawkBox\sbtrans10.dll</Path> </Launch.Addon> [/CODE] Those three are all to do with Squawkbox, and look ok. check the folders etc. [CODE]<Launch.Addon> <Name>Traffic Toolbox</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>..\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Traffic Toolbox SDK\traffictoolbox.dll</Path> </Launch.Addon> <Launch.Addon> <Name>Visual Effects Tool</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>..\Microsoft Flight Simulator X SDK\SDK\Environment Kit\Special Effects SDK\visualfxtool.dll</Path> </Launch.Addon>[/CODE] And those are also parts of the FSX SDK. Delete the SimConnect.xml file and SimConnect.cfg file. Without networking you dn't need them and you could be causing problems by having them there, incomplete as they are. Pete