FSUIPC Buttons menu locks up

[Murphy]

Hi,

I have a problem where I cannot edit controller buttons using the FSUIPC dialog box.

When I open the FSUIPC settings box, I can play around with all the options, such as Axis controls etc. But when I go to the Buttons tab, FSX, and the dialogue box locks up. All of the options are greyed out. If I click a button on a controller the appropriate action shows up in the dialogue box, however in all other respects the system is non responsive. I cannot select/deselect check boxes, drop downs etc. I cannot select a different tab in FSUIPC settings, nor can I close it. Effectively once I open the buttons tab, thats it for FSX. Using Task Manager to kill FSX tells me that "FSX is awaiting a response from you." or words to that effect.

I thought there might be a corrupt FSUIPC4.ini file, so I renamed it and re-ran FSX, and it automatically recreated it, but the same problem re-occured.

I cannot think of what I have changed recently that would affect FSX or FSUIPC.

I am running FSX SP1 with FSUIPC 4l, with CH Yoke, Pedals and Throttle and several GoFlight modules.

Any pointers?

Regards

Craig

[Pete Dowson]

When I open the FSUIPC settings box, I can play around with all the options, such as Axis controls etc. But when I go to the Buttons tab, FSX, and the dialogue box locks up. All of the options are greyed out. If I click a button on a controller the appropriate action shows up in the dialogue box, however in all other respects the system is non responsive. I cannot select/deselect check boxes, drop downs etc. I cannot select a different tab in FSUIPC settings, nor can I close it. Effectively once I open the buttons tab, thats it for FSX. Using Task Manager to kill FSX tells me that "FSX is awaiting a response from you." or words to that effect.

This sounds very much as if you have a driver installed for a device which isn't present, and the button scanning is causing that to hang. In FSUIPC4 the buttons tab scans using an older Windows API whilst the axis assignments uses DirectInput. (In FSUIPC3 both use the older API).

Check in Windows Game Controllers, see if there's an old unwanted driver still installed.

Regards

Pete

[Pete Dowson]

Oh, one thing which may help identify the problem is the attached small program, "Joyview", originally from Thrustmaster I think. This uses the same scanning system as FSUIPC and may give you more information, such as the driver name and so on, if it doesn't cause it to hang too.

Regards

Pete

joyview.zip

[Murphy]

Hi Peter,

Thanks for the quick response.

I've checked Game Controllers, and it only showed my three CH components (Yoke, Pedals, Throttle), and my Saitek X52. I have unplugged the Saitek controller for the moment.

The Joyview program you attached doesn't show any controllers. When I run it, it shows 16 input devices, all called 'None'

None of them shows any inputs when when I move any of my controllers.

I was running my Ch products in 'Mapped' mode, but tried just direct mode, which worked, although for some reason the view pans up uncontrollably, and I can't seem to find out why, all other controls work as desired, so I'm not sure what is issuing the pan up command. It may be a red herring, or it may be something acting as a button causing an uncontrolled pan up?

Regards

Craig

[Pete Dowson]

The Joyview program you attached doesn't show any controllers. When I run it, it shows 16 input devices, all called 'None'

Same here. Nevertheless, when I open them, and check the "joyGetDevCaps()" entry, several of them show values, including a "product name" -- for example "Microsoft PC-joystick driver". Not sure why "None" is shown in the main folder-type section -- probably something different in XP. The program is really a Win95/98 one.

Open each in turn, see what you can find.

None of them shows any inputs when when I move any of my controllers.

You need to open them and select "joyGetPosEx()" to see values being read, including buttons.

I was running my Ch products in 'Mapped' mode, but tried just direct mode, which worked, although for some reason the view pans up uncontrollably, and I can't seem to find out why, all other controls work as desired, so I'm not sure what is issuing the pan up command. It may be a red herring, or it may be something acting as a button causing an uncontrolled pan up?

If a button or hat (whether real or not) is constantly triggering (i.e. going on and off) it will certainly keep FSUIPC's scanning in a tight loop, as it is designed to react to the last such change -- when there's always another change it will re-display it, even if it is the same as before.

See what you can find. I could probably code around a continually repeating button/hat input, to avoid hanging FS, but I can't think how I would be able to get to other buttons for programming then if that keeps taking precedence. It would need some thought -- it certainly should not be happening (and in fact I've not had such a case in the 8 years of FSUIPC's button scanning). It must be a fault someplace, assuming it isn't a rogue driver.

Regards

Pete

[Murphy]

Hi Pete,

Thank you for your response,

I don't know what I did, but the 'Button Tab' is no longer hanging, but I still now have the uncontrolled pan up setting.

I have gone to the button tab, and clicked every button on the controllers, to make sure that one hasn't been remapped some how to pan up with a repeat etc, but everything seems to be mapped where I want it to be.

I can hit eyepoint reset, but as soon as it resets the eyepoint, the scan up starts all over again.

I played around with joyview again, and managed to id my 3 controllers (in Joy view. numbered from 2,3 & 4 respectively. Device #1 has no driver information, and returns no values under JoyGetPosEx(), not sure if that is significant.

I have enabled logging for buttons and axis controls, and below is what I get which shows a continuos pan up button, but I'm not sure how to ID which button is being pushed.

Regards

Craig

********* FSUIPC4, Version 4.152 by Pete Dowson *********

User Name="Craig Turner"

User Addr="craig@craigturner.id.au"

FSUIPC4 Key is provided

WideFS7 Key is provided

[Continuation log requested by user]

Running inside FSX (SimConnect SP1 May07)

Module base=61000000

2118031 System time = 13:47:52, FSX time = 13:37:20 (12:37Z)

2118047 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

2118938 SendKeyToFS(00000053=, KEYUP) ctr=0

2118938 Sending WM_KEYUP, Key=83 (Scan code 31), Ctr=1

2119860 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N

2119891 [buttons] 13=R1,32,C65734,0

2119891 FS Control Sent: Ctrl=65734, Param=0

2119891 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

2119922 [buttons] 13=R1,32,C65734,0

2119953 [buttons] 13=R1,32,C65734,0

2119953 FS Control Sent: Ctrl=65734, Param=0

2119953 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

2119985 [buttons] 13=R1,32,C65734,0

2120000 [buttons] 13=R1,32,C65734,0

2120031 [buttons] 13=R1,32,C65734,0

2120031 FS Control Sent: Ctrl=65734, Param=0

2120031 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

2120063 [buttons] 13=R1,32,C65734,0

2120094 [buttons] 13=R1,32,C65734,0

2120094 FS Control Sent: Ctrl=65734, Param=0

2120094 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

2120125 [buttons] 13=R1,32,C65734,0

2120156 [buttons] 13=R1,32,C65734,0

2120156 FS Control Sent: Ctrl=65734, Param=0

2120156 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

2120188 [buttons] 13=R1,32,C65734,0

2120219 [buttons] 13=R1,32,C65734,0

2120219 FS Control Sent: Ctrl=65734, Param=0

2120219 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

2120235 [buttons] 13=R1,32,C65734,0

2120266 [buttons] 13=R1,32,C65734,0

2120297 [buttons] 13=R1,32,C65734,0

2120297 FS Control Sent: Ctrl=65734, Param=0

2120297 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

2120328 [buttons] 13=R1,32,C65734,0

2120360 [buttons] 13=R1,32,C65734,0

2120360 FS Control Sent: Ctrl=65734, Param=0

2120360 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

2120391 [buttons] 13=R1,32,C65734,0

2120422 [buttons] 13=R1,32,C65734,0

2120422 FS Control Sent: Ctrl=65734, Param=0

2120422 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

2120453 [buttons] 13=R1,32,C65734,0

2120485 [buttons] 13=R1,32,C65734,0

[Murphy]

Well, I have solved the problem, sort of.

First, I had been running my CH controls in 'Mapped' mode. In Mapped mode, I experienced locks using the buttons menu, but did not have the 'panning up' problem. Setting the CH controls to 'direct mode' and rebooting (rebooting was important!) freed up the 'Buttons Menu' for normal use, but introduced the 'panning' problem mentioned above.

After examining the log above, I went into FSUIPC4.INI and deleted button 13.

I then ran FSX, reset some of the assignments that had been changed, and it all works. I still don't know what Button 13 was doing, what was triggering it etc, but all works fine.

Thanks for the assistance,

Regards

Craig

[Pete Dowson]

After examining the log above, I went into FSUIPC4.INI and deleted button 13.

I then ran FSX, reset some of the assignments that had been changed, and it all works. I still don't know what Button 13 was doing, what was triggering it etc, but all works fine.

The log explains the Button on line 13:

2119891 [buttons] 13=R1,32,C65734,0

2119891 FS Control Sent: Ctrl=65734, Param=0

2119891 *** EVENT: Cntrl= 65734 (0x000100c6), Param= 0 (0x00000000) PAN_UP

It was button "32" on joystick #1 (that's the second one down in Joyview). FSUIPC follows FS2000's (and before) convention for numbering Hat positions from 32 (Forward, or North) clockwise through 45 degree steps to 39 for Forward Left, or North West.

You had the North/Forward position of the Hat programmed to send C65734 (PAN_UP) and to repeat whilst held.

The problem appears to be that this hat position is permanently held. That is wrong. When released a Hat should return a "released" or "null" value (actually 65535, as would be shown in Joyview, for instance).

I think this would explain the problem in CH's "mapped" mode too -- I suspect it does the Repetition of the Hat Forward indication itself in that mode, so providing a constant repetitive "button pressed then released" indication, effectively hanging FSUIPC's test loop.

Basically, you have a faulty Hat which appears to be stuck in the "pressed forward" state. Maybe there's some gunk in it causing a short, or it's spring or whatever is bent? Worth checking to see if it is easy to repair. Use that "Joyview" program to see what it is doing. Normal values are:

Btn Direction Value

32 FWD 0

33 FR 4500

34 R 9000

35 BR 13500

36 BCK 18000

37 BL 22500

38 L 27000

39 FL 31500

OFF 65535

The fact that FWD is a value of 0 does strongly suggest a short circuit, so it may actually be in the wiring someplace rather than the hat itself.

Regards

Pete

[Murphy]

Thanks Peter, you are a champion.

I will check the hat switch, although at the moment everything seems to be working perfectly, even though I've deleted Button 13 from the ini file, and every switch on the joystick is working as it should, so its a bit strange, but you've given me enough to go on.

No need to reply Peter, as I see we users keep you quite busy, but thank you for taking the time.

Regards

Craig