Jump to content
The simFlight Network Forums

Recommended Posts

Posted

I'm trying out the FSUIPC7 beta and a question came up: I'm working with a situation where I'm using some virtual controllers in addition to actual physical controllers. In some cases I'd like to map buttons from a virtual controller via FSUIPC. However, in these cases the physical controller is still present and hitting buttons on that physical controller translates to a button press on both the physical controller and the virtual one. This can make it difficult when FSUIPC is detecting button presses. So I'm wondering if there is a way to tell FSUIPC to just completely ignore certain controllers?

Posted

Hi,

no. As this would only be a problem when your virtual controller is actually the same controller FSUIPC would detect, the software that creates the outputs for the virtual controller uses the same hardware. Is that the case/ problem?

Thomas

Posted (edited)

 

The software that creates the outputs for the virtual controller is taking inputs from a physical controller (among other possible sources), "doing stuff", then creating outputs to a virtual controller.

FSUIPC detects two different controllers, one virtual and one physical. However when I hit a button on the physical controller that is mapped to the virtual controller, FSUPIC is seeing both of these and it's unpredictable which one it's going to pick. For this reason, it would be helpful if I could just tell FSUIPC to simply ignore the physical controller.

As an example - I might have my physical controller mapped so that when I hold down a combination of two buttons on the physical controller, a single specific button gets pressed on the virtual controller. What I want to map with FSUIPC is the virtual controller, but it's also seeing the two button presses on the physical controller and it's unpredictable.

Edited by Matthew Twomey
clarify
Posted

 Have you tried using the IgnoreThese ini parameter?  From the Advanced User Manual:
 

Quote

IgnoreThese: This can be used to list a number of buttons which are to be ignored by FSUIPC in the Buttons &
Switches tab. This is to deal with faulty button signals which are repeating without control and thus preventing the
others from being registered on the screen ready to program. The parameter takes this form:

        IgnoreThese= j.b, j.b, ...
listing the joystick number (j) and button number (b) of each button to be ignored. To make it easy, you can edit the INI
file whilst in the Button assignments dialogue and simply press “reload all buttons” to activate the changes.
Note that the action of ignoring buttons only applies to those numbered 0–31 on each possible joystick (not any “POV”
hats), and they are only ignored in the dialogue—if they are already assigned the assignment will still be effective.
This parameter can also be used in the [Axes] section of the FSUIPC6.INI, using the axes letter instead of the button
number (see later)

 

Posted
14 hours ago, Matthew Twomey said:

FSUIPC detects two different controllers, one virtual and one physical. However when I hit a button on the physical controller that is mapped to the virtual controller, FSUPIC is seeing both of these and it's unpredictable which one it's going to pick. For this reason, it would be helpful if I could just tell FSUIPC to simply ignore the physical controller.

As well as John's suggestion, if they are looking distinct, with distinct assignments in FSUIPC, why not use Profiles and only assign to one or the other?

Pete

 

Posted
Quote

As well as John's suggestion, if they are looking distinct, with distinct assignments in FSUIPC, why not use Profiles and only assign to one or the other?

The main issue I was having is in the "detection" done by fsuipc. In the case of a physical controller mapping to a virtual controller, both inputs are coming in at (roughly) the same time. So there's basically a race condition on which FSUIPC is "locking on" to. Essentially I am never working with the physical controller in FSUIPC, so it's just getting in the way.

The IgnoreThese suggestion works though as a workaround for what I'm trying to do. Basically I can ignore most of the controller with these lines:

[Axes]
IgnoreThese=A.Y,A.X

[Buttons]
IgnoreThese=A.0, A.1, A.2, A.3, A.4, A.5, A.6, A.7, A.8, A.9, A.10, A.11, A.12, A.13, A.14, A.15, A.16, A.17, A.18, A.19, A.20, A.21, A.22, A.23, A.24, A.25, A.26, A.27, A.28, A.29, A.30, A.31

So that gets me where I need to be on my end :-) It would be nice to just be able to ignore a designated controller wholesale (feature request) - however, I do understand this may be more of an edge case.

Thanks all for the help and input!

-Matt

Posted
14 hours ago, Matthew Twomey said:

In the case of a physical controller mapping to a virtual controller, both inputs are coming in at (roughly) the same time. So there's basically a race condition on which FSUIPC is "locking on" to.

But if they both arrive only the one which is assigned will have any effect. FSUIPC doesn't act on un-assigned button presses (except during assignment). Using Profile-related assignments would be your solution, surely? You are not constantly re-assigning actions are you?

Pete

 

Posted
7 hours ago, Pete Dowson said:

But if they both arrive only the one which is assigned will have any effect. FSUIPC doesn't act on un-assigned button presses (except during assignment). Using Profile-related assignments would be your solution, surely? You are not constantly re-assigning actions are you?

Pete

 

What I mean here, is the issue is during the setup / assignment process in FSUIPC. When I'm setting up the assignments, FSUIPC latches on to either the physical or the virtual inputs, it's semi-random which one it's going to take. So for example, I want to assign virtual controller button #8 in FSUIPC. That button (on the virtual controller) gets pushed when I hold down a combination of buttons #6 + button #5 on the physical controller. So when I'm trying to assign button #8 on the virtual controller (in FSUIPC), it's difficult because the "detection" in FSUIPC might "capture" button #6 or button #5 on the physical controller - instead of button #8 on the virtual controller.

Once the assignment is correct in FSUIPC, everything works fine - it's just the process of assigning that is difficult. So it's just the assignment process - which I was suggesting would be made easier if I could tell FSUIPC to just ignore the physical controller, or ignore a controller with a given UUID.

Posted

@Matthew Twomey Yes, I understand your issue. What I will do as a "quick fix" will be to allow you to specify a wild card for the IngoreThese ini parameter, e.g.

[Buttons]
IgnoreThese=A.*

However, when this is read and later the ini file re-written, it will expand to reference buttons 0-31 (as you now have it).

I will also add an 'Ignore Button' button to the buttons & switches assignments dialog that will function in a similar way to the 'Ignore Axis' button in the axis assignments dialog, which will ignore specific buttons as long as the assignments dialog remains open. I'll add this to my 'todo' list, so will take longer to implement as this is quite minor as there is already a work-around (and my 'todo' list is already pretty large!).

 

Posted
1 hour ago, Matthew Twomey said:

What I mean here, is the issue is during the setup / assignment process in FSUIPC

Okay, understood now ... John evidently understood it was this you were having problems with, and informed me privately.  I was thinking more in terms of the use of the device(s) with assigned buttons.

Pete

 

 

Posted
8 hours ago, John Dowson said:

@Matthew Twomey Yes, I understand your issue. What I will do as a "quick fix" will be to allow you to specify a wild card for the IngoreThese ini parameter, e.g.


[Buttons]
IgnoreThese=A.*

However, when this is read and later the ini file re-written, it will expand to reference buttons 0-31 (as you now have it).

I will also add an 'Ignore Button' button to the buttons & switches assignments dialog that will function in a similar way to the 'Ignore Axis' button in the axis assignments dialog, which will ignore specific buttons as long as the assignments dialog remains open. I'll add this to my 'todo' list, so will take longer to implement as this is quite minor as there is already a work-around (and my 'todo' list is already pretty large!).

 

Thank folks. No worries on this, the workaround is working. However if you do plan to implement something for completeness / convenience and you'll be digging into this area code-wise, I'll also point out that the ignore doesn't appear to work for buttons that are detected as >31. For example see the button in this screenshot, which should be ignored from this line:

[Buttons]
IgnoreThese=B.32, B.33, B.34, B.35, B.36, B.37, B.38, B.39, B.0, B.1, B.2, B.3, B.4, B.5, B.6, B.7, B.8, B.9, B.10, B.11, B.12, B.13, B.14, B.15, B.16, B.17, B.18, B.19, B.20, B.21, B.22, B.23, B.24, B.25, B.26, B.27, B.28, B.29, B.30, B.31
PollInterval=25
ButtonRepeat=20,10

 Button 34 screenshot

Posted
9 hours ago, Matthew Twomey said:

I'll also point out that the ignore doesn't appear to work for buttons that are detected as >31

Buttons 31-39 are the POV compass points, and can be treated as axis or as a set of buttons. They should be ignored as buttons when specified though, so I'll look into this.

Posted (edited)

@Matthew Twomey Could you try this build. This will accept the wild card '*' for the button number of the IgnoreThese parameter, and should also ignore the POV buttons 31-39 when specified. Its has also been rebuilt against the latest SimConnect version (0.6.0.0) released yesterday:  

FSUIPC7.exe

 

Edited by John Dowson
Replaced attachment - original was a debug build
Posted

Thanks John! I gave this a whirl. The X.* format in the buttons ini section did work as expected, once I launched FSUIPC, it was converted to individual X.0, X.1, X.2... Those buttons were blocked as well. The total range of buttons it converted to was 0 - 31. It still wasn't able to block 32 - 39 though. I manually added 32 - 39 into the ini file, but still no block there.

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.