Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hi, I while back I posted about an issue I was having with FSX not recognising controller inputs apart from when I opened a game controller properties dialogue box (eg for calibration) in windows.

It was some time ago and I think I solved the problem honestly can't remember as I have been away from FSX for some time - funny how lockdown brings us back to certain things... anyway, the problem is back - at least to some extent.

Previous posts for reference:

https://forum.simflight.com/topic/87518-fsuipc-throttle-axis-control/?tab=comments#comment-531701

 

https://forum.simflight.com/topic/87519-controller-inputs-not-detected/?tab=comments#comment-531654

 

So the problem is that I have no button input from my yoke (incl quad), I have an additional quadrant and that works fine (it is plugged in to the yoke USB hub).  Also curiously all axis are recognised.  As before the only way I can get FSX to recognise the button inputs is to open the controller dialogue box.

I checked the power management box in device manager (connection view) and switched it off for the USB hub controller.

I also have a HOTAS stick & throttle, these work fine.

The connection is via a powered USB hub, which is connected to a USB 3.1 gen 1 port on the PC back panel.  The HOTAS and yoke (hub) and rudder pedals are connected to this hub.

There is a power supply to the yoke hub and it has the yoke quad, additional quad and two Saitek panels connected.  There is never an issue in detecting control from the Saitek panels.

 

I have connected rudder and pedals via extension USB leads, to make connecting and disconnecting a bit easier.  This doesn't make any difference though.

I've tried it as per original (ie into hub with HOTAS), via extension leads, or direct into PC USB ports.  Same result each time.

Switching off power management did help as I couldn't see these game controllers in the device window (but they were present when invoking properties/calibration via click on HOTAS stick or throttle).  Since adjusting the power management settings for the hub they are shown along with the other devices.

 

The buttons are programmed via the FSUIPC config file and include compound assignments (ie use of mode 1-2-3 and 'shift' operators).

The joysticks are assigned letters, although they are usually plugged in to same port (I don't think the device ID's change anyways).

When I checked the FSUIPC log file/console window it looks like it detects button input but returns FALSE status when assessing the compound functions so hence no command output.

 

I'm stuck and have tried everything I can think of.

The only other thing to note was when I programmed the HOTAS via FSUIPC.  I think it worked fine before then but it was some time ago.  maybe this was when it all started.  But I'd like to have the HOTAS for combat jets and the yoke for pretty much everything else.

 

The other sub question is the POV, the POV function is not as smooth using the yoke hat switch as it is with the HOTAS stick POV/hat.  Appreciate one is an axis but can this be changed?

 

Anyways dutifully attached log & config files, I'm not sure where to find the other file that is sometimes asked for?

I can also provide an excel 'map' of my assignments if needed.

 

Also whilst typing I thought to try with the HOTAS disconnected and to reboot windows! 

That may help, but obviously I typed all this now so....FSUIPC4.ini

FSUIPC4.log

Posted
3 minutes ago, gmcraib said:

Anyways dutifully attached log & config files,

You only attached a log file, not INI file so i can't check your settings. Looking at that:

1. I see you are using a very old long-unsupported version of FSUIPC (4.939k). Please update so you can get proper support!

2. The log is very long (over 5,000 lines), and from sampling it I see lots of Button responses, all resulting in controls being sent, so it shows nothing wrong that I can see. If you have only some things not working, not all of them, then you need to narrow it down, At least say which joystick buttons.

All of those I sampled in the Log which were shown to be working were on Repeated button C 7 which was continually sending "THROTTLE4 DECR SMALL". So I really have no idea what you were doing other that that.

Maybe that button is stuck? If so it could make it difficult to do much else. Best to change it to not repeating.

Pete

 

 

 

Posted

Yeah I looked at the log file after attaching them!

The throttle was slightly in reverse on that axis.  So I have made a new log file showing the events with the controller plugged in directly to PC then (after the pauses just before 319568) and opening the game controller dialogue box with the button presses and commands executed.  You'll see the quad functions work in the first set.

Also to make it easier the mode settings 1-2-3 reflect the command line eg 102, 202, 302 for that same button.

Not sure why the config file didn't attach, it embedded instead?

Anyways should be it now.

FSUIPC4.ini FSUIPC4.log

Posted

Just noticed the bit about FSUIPC date being out of date. Ok will look into that.

 

Have downloaded v4.975 do you want me to install it and start again or work with the info provided so far as a first step?

Posted
26 minutes ago, gmcraib said:

You'll see the quad functions work in the first set.

So your problem is actually with specific conditional programming issues? Not this as you said before:

2 hours ago, gmcraib said:

So the problem is that I have no button input from my yoke (incl quad)

All your buttons are seen and respond but you have somethnig you don't understand in some conditionals? Is that right?

I really don't see any point in me looking at any of your data until you make it clear what your problem really is.  I see that even this log is over 2000 lines. What am I supposed to look at? What is is you think is wrong?

29 minutes ago, gmcraib said:

Have downloaded v4.975 do you want me to install it and start again or work with the info provided so far as a first step?

Yes, do the update. No, don't 'start again'. just do a short session where you demonstrate exactly what you want help with. Just cut the relevant part out of the log if that makes it clearer -- you can paste it into a message (best to use the <> brackets above for that).

Pete

 

 

Posted

Ok, I am only doing a few button presses each time.  But as they are compound each button has at least 3 functions and the length means they don't fit into a single text line.

Will also try to avoid the repeating functions like pan view etc.  That doesn't help.

32 minutes ago, Pete Dowson said:

So your problem is actually with specific conditional programming issues? Not this as you said before:

All your buttons are seen and respond but you have somethnig you don't understand in some conditionals? Is that right?

I don't know the problem, exhausted my trouble shooting steps.  But both things I said earlier are true.  There are two quads, one that comes with the yoke eg yoke (incl quad) and a separate one eg quad.  Both are plugged into the yoke, ie one via S-cable and one via USB, the additional one plugged in via USB seems to be working ok, as is the HOTAS.

Its just the yoke buttons and the non-USB quad.

 

 

 

Posted
8 minutes ago, gmcraib said:

Its just the yoke buttons and the non-USB quad.

So, are you saying it is all the yoke buttons and all the attached quad buttons not working?  You get no response in Bttons 7 Switched optionsi FSUIPC when they are pressed? But the Yoke axes and Quadrant levers do show in the Axis Assignments options tab?

Sorry to press on with this, but your reports have been very muddled.

As further clarification, are those buttons seen in FSX? Are they even seen in Windows?

The point is that DirectInput, used by FSUIPC, supplies all buttons and axes at the same time. There's no way FSUIPC can read one set of values and not the other, they are all one.

BTW, I've looked at your recent (still out of date FSUIPC) settings and it seems there's only one quadrant seen as connected there.

However, the Log would show a lot more about connections, but your version of FSUIPC is far too old. Most of the information and analysis we do nowadays is missing. That''s probably why you can't find the JoyScan csv file now poduced.

Pete

 

Posted

Hi, I haven't installed updated FSUIPC yet since we spoke last.  Will hopefully do today or later this evening.

Sorry if things are not clear but not sure how I can explain any clearer.  The issue is that the button inputs on the yoke (and its quad) are not doing anything in FSX.  Other controllers (eg HOTAS, additional quad and switch panels) are working fine.  The axis movements work ok.

If I remember correctly the button inputs were detected in FSUIPC but I will have to check everything again after installing updated FSUIPC.

Everything works fine if the controller properties dialogue box is open in windows.

The quad that isn't working is essentially part of the yoke and recognised as same joystick in FSUIPC, eg joystick B.  So all issues appear to lie with joystick B.

 

But if we start from clean slate should be clearer and I'll post up results later.

Posted

Have updated FSUIPC and tried again.

Checked axis and button inputs in:

Windows/control panel (game controllers properties) - OK

FSUIPC - OK (note compound settings so mapped to mode 3, eg 3XX series but detected button presses)

FSX - not OK (works with game controllers properties dialogue box open).

 

So issue still there.  Have attached config, log & joyscan files.  Also please see below for specific log entries.

Pressing button 0:

   736855 [Buttons] 102=CP(+B,8)(-B,11)B,1,C66483,0
   736855 .... Condition (+B,8) = FALSE
   736855 [Buttons] 103=CP(+B,8)(+B,11)B,1,C66483,0
   736855 .... Condition (+B,8) = FALSE
   736855 [Buttons] 202=CP(+B,9)B,1,C65580,0
   736855 .... Condition (+B,9) = FALSE
   736855 [Buttons] 302=CP(+B,10)(-B,11)B,1,C65567,0
   736855 .... Condition (+B,10) = FALSE
   736855 [Buttons] 303=CP(+B,10)(+B,11)B,1,C66153,0
   736855 .... Condition (+B,10) = FALSE
   737057 Button changed: bRef=0, Joy=1 (B), Btn=1, Released

Commands 102, 202, 302 depend on mode setting 1-2-3 (eg button 8-9-10).  103, 303 fire in respective mode setting with a shift operator.

Ignoring 103 & 303 (as shift operator not used) one of 102, 202 or 302 should result in TRUE as it can only be in one of those modes.

 

Trying again with the controller properties box open in windows:

 773562 Button changed: bRef=0, Joy=1 (B), Btn=1, Pressed
   773562 [Buttons] 102=CP(+B,8)(-B,11)B,1,C66483,0
   773562 .... Condition (+B,8) = FALSE
   773562 [Buttons] 103=CP(+B,8)(+B,11)B,1,C66483,0
   773562 .... Condition (+B,8) = FALSE
   773562 [Buttons] 202=CP(+B,9)B,1,C65580,0
   773562 .... Condition (+B,9) = TRUE
   773562 FS Control Sent: Ctrl=65580, Param=0
   773562 [Buttons] 302=CP(+B,10)(-B,11)B,1,C65567,0
   773562 .... Condition (+B,10) = FALSE
   773562 [Buttons] 303=CP(+B,10)(+B,11)B,1,C66153,0
   773562 .... Condition (+B,10) = FALSE
   773562 *** EVENT: Cntrl= 65580 (0x0001002c), Param= 0 (0x00000000) AP_MASTER

It has fired command 202 as the joystick is in mode 2 (button 9).

Again 103 & 303 FALSE as shift operator not used (and was in mode 2 anyway).

 

It was the same with a few other button presses but only listed with button 0 for sake of brevity.

 

FSUIPC4.ini FSUIPC4.JoyScan.csv FSUIPC4.log

Posted

Also for the yoke quad and additional quads, same as previous.

Log entries for button 14 (yoke quad)

 115160 Button changed: bRef=0, Joy=1 (B), Btn=14, Pressed
   115160 [Buttons] 114=CP(+B,8)B,14,C66718,0
   115160 .... Condition (+B,8) = FALSE
   115160 [Buttons] 313=CP(+B,10)(+B,11)B,14,C65826,0
   115160 .... Condition (+B,10) = FALSE
   115160 [Buttons] 314=CP(+B,10)(-B,11)B,14,C65825,0
   115160 .... Condition (+B,10) = FALSE
   115301 Button changed: bRef=0, Joy=1 (B), Btn=14, Released

and for additional quad (plugged in USB via yoke):

129310 Button changed: bRef=0, Joy=2 (C), Btn=4, Pressed
   129310 [Buttons] 22=PC,4,C65595,0
   129310 FS Control Sent: Ctrl=65595, Param=0
   129310 *** EVENT: Cntrl= 65595 (0x0001003b), Param= 0 (0x00000000) FLAPS_UP
   129528 Button changed: bRef=0, Joy=2 (C), Btn=4, Released

 

Then with game controller properties box open;

For button 15 (yoke quad):

194970 Button changed: bRef=0, Joy=1 (B), Btn=15, Pressed
   194970 [Buttons] 115=CP(+B,8)B,15,C66719,0
   194970 .... Condition (+B,8) = FALSE
   194970 [Buttons] 215=CP(+B,9)B,15,C65853,0
   194970 .... Condition (+B,9) = TRUE
   194970 FS Control Sent: Ctrl=65853, Param=0
   194970 [Buttons] 315=CP(+B,10)B,15,C65824,0
   194970 .... Condition (+B,10) = FALSE
   194970 *** EVENT: Cntrl= 65853 (0x0001013d), Param= 0 (0x00000000) SPOILERS_ARM_TOGGLE

It shows function for 202 as in mode 2.

 

So I'm not sure whats happening, the only difference seems to be opening the game controllers dialogue box in windows.  I already disabled the USB power saving as discussed previously.

The additional quadrant (joy 2) and switch panels are plugged into the yoke USB inputs and they all work fine.  It is the yoke buttons and the yoke quad that have the problem (ie joy 1).

 

Also as a side note, is it possible to stop FSUIPC writing comments to the command lines in the config file.  I already have my own comments there, although it is useful for troubleshooting.

 

Posted
2 hours ago, gmcraib said:

FSUIPC - OK (note compound settings so mapped to mode 3, eg 3XX series but detected button presses)

FSX - not OK (works with game controllers properties dialogue box open).

Sorry, again clarification needed.

This says to me that everything is okay in FSUIPC -- that the buttons and axes are seen and can be assigned / calibrated, but you aren't seeing the results you expect in FSX.

Is this correct?

2 hours ago, gmcraib said:

Pressing button 0:

   736855 [Buttons] 102=CP(+B,8)(-B,11)B,1,C66483,0
   736855 .... Condition (+B,8) = FALSE
   736855 [Buttons] 103=CP(+B,8)(+B,11)B,1,C66483,0
   736855 .... Condition (+B,8) = FALSE
   736855 [Buttons] 202=CP(+B,9)B,1,C65580,0
   736855 .... Condition (+B,9) = FALSE
   736855 [Buttons] 302=CP(+B,10)(-B,11)B,1,C65567,0
   736855 .... Condition (+B,10) = FALSE
   736855 [Buttons] 303=CP(+B,10)(+B,11)B,1,C66153,0
   736855 .... Condition (+B,10) = FALSE
   737057 Button changed: bRef=0, Joy=1 (B), Btn=1, Released

That all looks fine. What are you expecting there instead?

2 hours ago, gmcraib said:

It has fired command 202 as the joystick is in mode 2 (button 9).

Yes, so all that's good too.

I'm sorry, but you appear to be quoting these bits as if they illustrate something wrong, but they don't appear to. uit all looks good.

2 hours ago, gmcraib said:

So I'm not sure whats happening, the only difference seems to be opening the game controllers dialogue box in windows. 

What difference? Every example you illustrate looks correct. what do you think is wrong?

2 hours ago, gmcraib said:

Also as a side note, is it possible to stop FSUIPC writing comments to the command lines in the config file.  I already have my own comments there, although it is useful for troubleshooting.

FSUIPC's comments are added to the end AFTER yours. Just use the normal commenting system for your own -- i.e. ; followed by text. FSUIPC identifies its comments by its special delineations.

Pete

 

Posted

HI Pete,

 

I think FSUIPC is seeing the buttons, certainly is seeing the individual button presses but not so sure about the compound button presses at least when the gamer controller properties is not open.

I know it picks up individual button presses as it reports this in the menu, but it refers you back to the .ini file as they are compound functions.  So you can't tell from that alone if it has detected the compound presses.

 

In the 736855 event 1 of commands 102 OR 202 OR 302 must be true, but it has reported false for all 3.  So there is an issue there.  I know the buttons are functioning in windows (including the mode select) but its not clear if this is being detected in FSUIPC.

The mode select switch can only be set at 1, 2 or 3 (which is button 8, 9, 10). (button 11 is shift operator and it was = 0).

From the log file it looks like FSUIPC detects press of button 0 (as was also seen in the menu) but given the FLASE state reported for 102-202-302 it must also be detecting buttons 8-9-10 as 0 whereas one of them is always = 1 (in this case it was button 9 = 1 ie mode 2).

But this goes away when the game controller properties box is open in windows so I am completely stumped!

 

So I guess to answer your question specifically, in the example above for event 736855, command line 202 should have been TRUE as button 9 was = 1 when button 0 was pressed.

Then later in 773562 it did return TRUE with the same button operations, but the only difference was the game controller properties box open in windows.

 

So there maybe is an issue somewhere either between windows (ie hardware reporting) and FSUIPC, I don't think there is an issue between hardware and windows as windows reports the button states correctly.

 

I'm not sure what to try next, I have a couple of ideas but will await suggestion.

Posted
42 minutes ago, gmcraib said:

I know it picks up individual button presses as it reports this in the menu, but it refers you back to the .ini file as they are compound functions.  So you can't tell from that alone if it has detected the compound presses.

But the Log shows the reason for the control being sent or not sent, based on the conditions.  Everything you showed me in the log looked correct. The conditions told it whether to action the assignment, and when the conditions were correct, it did so.

45 minutes ago, gmcraib said:

In the 736855 event 1 of commands 102 OR 202 OR 302 must be true, but it has reported false for all 3.  So there is an issue there.

Sorry, I don't see that.  buttons B 8 9 and 10 are all indicating off, that's why the command isn't actioned:

   736855 [Buttons] 102=CP(+B,8)(-B,11)B,1,C66483,0
   736855 .... Condition (+B,8) = FALSE
   736855 [Buttons] 202=CP(+B,9)B,1,C65580,0
   736855 .... Condition (+B,9) = FALSE
   736855 [Buttons] 302=CP(+B,10)(-B,11)B,1,C65567,0
   736855 .... Condition (+B,10) = FALSE

 

49 minutes ago, gmcraib said:

The mode select switch can only be set at 1, 2 or 3 (which is button 8, 9, 10).

Aha!  So you are saying that one of 8, 9 and 10 should always indicate as pressed? I see. But sorry, the logs didn't tell me that. That's why I was puzzled.

50 minutes ago, gmcraib said:

So there maybe is an issue somewhere either between windows (ie hardware reporting) and FSUIPC, I don't think there is an issue between hardware and windows as windows reports the button states correctly.

It does seem odd that what FSUIPC receives changes depending on whether another Windows App is also monitoring.

There is an extra logging you can enable in FSUIPC which will show exactly what is received from Windows via DirectInput. I think it is still active -- I'll check. But meanwhile you could monitor the state of the buttons via the FSUIPC Monitoring options (right-hand side of the Logging tab in FSUIPC Options). Perhaps log extracts similar to those you provided above wityh the actual button state changes shown at the same will tell us more.

I'm assuming joystick B is still device ID = 1, the Saitek Yoke:

Monitor 03C4 as U32 and check the hex checkbox. Then check 'normal log' below.

Just show one example please, as in that small extract above.

Pete

 

Posted

Please see this post: 

From that post, this may be relevant:

Quote

For reasons I don't understand, to allow FSUIPC to see the Saitek Mode switch you have to go into the folder C:\Windows\System32 (assuming the C drive is where things are at, otherwise substitute the correct letter) where you should find a Saitek file called SaiD0BAC.PRO. Rename this file to deactivate it – I simply renamed mine SaiD0BACmodeswitch.PR0 and left it in the original System32 folder.  Then restart Windows, and the next time you start FSX pull up FSUIPC and go to the Buttons + Switches section and flip the mode switch – FSUIPC should register the switch when it moves. If subsequently you suddenly find the Mode Switch is not working again, it likely is because the SaiD0BAC.PRO file reappeared in the System32 folder for some reason. I've had this happen a few times.

John

Posted

Hello chaps, well good news and bad news.....

 

After some extensive testing, I cannot recreate the issue.

So its good news (perhaps) in that the issue seems to have gone away (hopefully) but bad news in the sense of troubleshooting.

In fact, in the world of fault finding there is nothing worse than this scenario!!

Posted
On ‎6‎/‎16‎/‎2020 at 4:51 PM, John Dowson said:

Please see this post: 

From that post, this may be relevant:

John

Will also try this John, for trouble shooting but not overly keen on implementing as a permanent solution in case it causes an issue with the Saitek drivers.

 

I mean renaming this: SaiD0BAC.PRO

Posted

Tried the additional logging, this was the result:

512401 Button changed: bRef=0, Joy=1 (B), Btn=1, Pressed
   512401 [Buttons] 102=CP(+B,8)(-B,11)B,1,C66483,0
   512401 .... Condition (+B,8) = FALSE
   512401 [Buttons] 103=CP(+B,8)(+B,11)B,1,C66483,0
   512401 .... Condition (+B,8) = FALSE
   512401 [Buttons] 202=CP(+B,9)B,1,C65580,0
   512401 .... Condition (+B,9) = FALSE
   512401 [Buttons] 302=CP(+B,10)(-B,11)B,1,C65567,0
   512401 .... Condition (+B,10) = FALSE
   512401 [Buttons] 303=CP(+B,10)(+B,11)B,1,C66153,0
   512401 .... Condition (+B,10) = FALSE
   512401 Monitor IPC:03C4 (U32) = 2
   512635 Button changed: bRef=0, Joy=1 (B), Btn=1, Released
   512651 Monitor IPC:03C4 (U32) = 0

 

It was the same in all three positions of the mode switch.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.