Fixed the ambiguous interaction mapping constructors

[StephenHodgson]

XRTK - Mixed Reality Toolkit Change Request

Overview

Fixed the ambiguous interaction mapping constructors.

Target of the change:

Is this enhancement for:

• Core (core framework, interfaces and definitions)

Changes:

Brief list of the targeted features that are being changed.

• Fixes: For controls that use a single axis, they are creating their config asset incorrectly #345
• Fixes: Error Input Axis is not setup. #336
• Supersedes: Resolves issue where Single Axis data is incorrectly assigned in new profiles #346

Breaking Changes:

• Update the MixedRealityInteractonMapping constructors but afaik the Oculus package is the only one taking advantage of it atm.

[SimonDarksideJ]

This addresses only the changes for oculus, however, it also breaks all existing mappings for all other controllers. This needs to be based off this fix branch.
Also, it will need the default assets updating with this fix. Let's close this PR and I'll incorporate your changes in my branch.

[StephenHodgson]

however, it also breaks all existing mappings for all other controllers. This needs to be based off this fix branch.

I don't understand. This shouldn't break any existing mappings.

Let's close this PR and I'll incorporate your changes in my branch.

I don't think that's a good idea.

[StephenHodgson]

/azp run

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

[StephenHodgson]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[SimonDarksideJ]

Not a fan of mixing up the order of parameters like this, but it works.

[StephenHodgson]

Not a fan of mixing up the order of parameters like this, but it works.

Any suggestions on how this could be better?

Mainly the issue is that the wrong Constructor is being called because of the order of the parameters.
One possible fix is to make the type different, but I'm not sure what would be an appropreate change.

The only other possibility is removing the inputName altogether and using the established inputAxisX and inputAxisY values that essentially function for the same purpose.

[SimonDarksideJ]

The only other possibility is removing the inputName altogether and using the established inputAxisX and inputAxisY values that essentially function for the same purpose.

No, they are defined concepts and should not be reused.

It's an acceptable fix