Skip to content
This repository has been archived by the owner on Aug 11, 2024. It is now read-only.

For controls that use a single axis, they are creating their config asset incorrectly #345

Closed
SimonDarksideJ opened this issue Sep 18, 2019 · 5 comments
Assignees
Labels
Bug Something isn't working Resolved Resolved, no further action

Comments

@SimonDarksideJ
Copy link
Contributor

XRTK - Mixed Reality Toolkit Bug Report

Describe the bug

Post the native Oculus update, when a new config asset is created that has single axis configuration, it is incorrectly being identified as "custom" data (as used by Oculus today)

To Reproduce

  1. Create new OpenVR Controller profile
  2. Examine asset to find "InputName" populated instead of "AxisX" for single axis config

Expected behavior

Single Axis configuration should be recorded in the AxisX field

Actual behavior

Single Axis configuration is being recorded in the custom "InputName" field

Your Setup (please complete the following information)

  • Unity Version 2019.1.14
  • XRTK Version 0.1.19

Target Platform (please complete the following information)

  • WMR immersive
  • OpenVR

Additional context

Simply requires single axis configuration to provide an empty second axis

@SimonDarksideJ SimonDarksideJ added the Bug Something isn't working label Sep 18, 2019
@SimonDarksideJ SimonDarksideJ self-assigned this Sep 18, 2019
SimonDarksideJ added a commit that referenced this issue Sep 18, 2019
Also adds extra debugging information for Unity Axis failures
@StephenHodgson
Copy link
Contributor

So the constructor is malformed?

@SimonDarksideJ
Copy link
Contributor Author

No, the constructor is fine. However with the requirement to have custom data for Oculus inputs, this overrides the "defaulted" approach for Axis data. So inputs requiring axis data need to provide two axis.

I support I could also update the Axis based constructor to make the second argument not optional.

@StephenHodgson
Copy link
Contributor

The constructor is definitely incorrect. Let's fix it.

@StephenHodgson
Copy link
Contributor

Goes back to #237 where we introduced the inputName constructors.

The constructors are ambiguous to the existing ones that have default parameters, so it's getting confused with axisCodeX instead of inputName

@StephenHodgson
Copy link
Contributor

StephenHodgson commented Sep 18, 2019

We need to update the new constructors by swapping the inputName with the deviceInputType this will help ensure we don't have ambiguity.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Bug Something isn't working Resolved Resolved, no further action
Projects
None yet
Development

No branches or pull requests

2 participants