[Tweak] Secondary override should not override movement

[3x1t-5tyl3]

--Making this issue for DAWKY & QueenHidi ( @StarfishHidari )--

Every controller except Index if 2 tools are equipped negates all movement (all analog input on that hand). AFAIK no controller uses a joystick for input on a [ToolTip here]. As such restricts movement for no reason and hinders workflow.

It should only override jump (For example click in on joystick on CV1)

@StarfishHidari (QueenHidi#1111 on the Discord) for CV1 @dawky (dawky#0001 on discord) for Rift S

Personally own an Index.

[shadowpanther]

Agreed. Oculus Touch (Rift S) thumbstick is completely disabled on tool equip, which changes control scheme to one-handed with one tool and disables movement with both. I don't remember ever using thumbstick axes for anything except movement, so this control scheme change shouldn't be occurring in my opinion.

[shiftyscales]

This is unlikely to be considered or added, sorry. I know it can be frustrating, but there is good reason why this behavior is the way that it is.

Currently in Neos, the 'secondary' input (joystick, touchpad, whatever it happens to be) can only be assigned to one function at a time, whether that's exclusively locomotion, or exclusively tool. This is the only way to ensure the most consistent user experience, and is the cleanest design technically as well.

While not every tool that has a secondary that uses the axis, some can, and in the future there are plans to extend the functionalities of many of the tooltips such that they do utilize more of the inputs available to them via the secondary axis.

For user tools, you can ensure that the tool will allow use of the secondary axis for locomotion by unchecking the 'use secondary' property on the raw data tooltip.

[StarfishHidari]

can an additional option be added to block secondary, but not block joystick movement? currently if we check "use secondary" it blocks joystick movement even if we aren't using the joystick movement at all

[shiftyscales]

That wouldn't be added for the reasons discussed above, @StarfishHidari. As noted, secondary is addressed as one module, e.g. an entire touchpad including its click/axis, an entire joystick including its click/axis, etc.

[Zyzyl]

I recently got a new headset and ran into this with the new controllers (Reverb G2, issue wasn't present on my 1st gen WMR controllers) and I don't find this to be good UX - the sudden change in locomotion control is jarring and frustrating. I appreciate the UseSecondary property can be used to free up joystick options if they aren't required by the tool. However that also just leads to a inconsistent experience because users have to mentally remap their locomotion controls in a tool-by-tool manner. Dual wielding tools which use secondary results in a user being unable to move unless they dequip a tip which feels very clunky.

I hope the button remapping mentioned here https://github.com/Frooxius/NeosPublic/issues/1314 will help users to resolve this for themselves, but I personally would encourage openness to making design concessions to UX regarding the default mapping.

[Frooxius]

There's just not really a good alternative to this. Either you'll lose ability to use locomotion on the controller or you won't be able to use some functionalities of the tool. The later one is much worse, because it would make some tools unusable and inconsistent.

Originally both controllers would behave the same, with both having turning, but no strafing, to avoid this. However the demand for turn + strafing was so high that we had to settle on this compromise.

With more UI rework I want to look into making more tools only need the trigger and not rely on the secondary, which would eliminate cases like this, but if the tool needs the joystick/touchpad, then it simply can't be used for locomotion.

[Stellanora64]

I formally request for this issue to be re-opened. This being due to already exiting solutions being available, other alternatives are possible, and after thorough testing I have yet to find any major edge cases with the existing solutions implementation. (The solution in question being a mod which can be found here: https://github.com/furrz/NoTankControls )

I also understand that grabbing an object would need to lock locomotion on non-index controllers. I have only made this comment in regards to secondary actions with a tooltip equipped.

However, if the previously mentioned solution does not meet your standards after review then I offer you the following alternatives:

Swap the secondary and dash buttons around on non-index controllers by default:

• This is the simplest solution I can think of in this moment in time. If this were to be implemented then tooltips that use secondary would no longer require the joystick to be pressed down, while still retaining full locomotion as there is no longer any reliance on the joystick.
• This in theory should also reduce the amount of wear on joysticks as the joystick would not be pressed down as often (At least for people who regularly use tools).
• Possible downsides:
• The only possible downsides to this solution I can think of is accidental miss clicks for some users that apply pressure to joysticks while locomoting. However, I believe that accidental secondary presses could possibly be more harmful to others (stray gizmos, custom tool functionality, etc) in a given session then accidently opening the dash. This may not be an issue for people who do not build often in Neos but until #1314 is implemented this would be the better alternative for the vast majority of Neos users.
• Some tools may require the joystick axes to function. However, for the default tool set that are not custom (dev-tip, logix-tip, etc) the functionally could be altered to not override locomotion, as in testing they do not require the joystick axes to function.

Give people the option to disable locomotion override in the settings menu, even if it may hinder some tools functionality:

• This would require the settings UI rework, but would give users the most freedom in choice for the user's desired preference no matter the skill level. This can be disabled by default, with a warning of possible hindered functionality, but at the very least giving people the option to change this functionally at all is still better then the current situation.
• Possible downsides:
• If people do disable the locomotion override some tools that require the joystick axis for functionality may be affected.

Add an option to override locomotion in the raw data tool tip component (and other tool tips that are applicable) and disable it by default on all current tools that do not require this functionality:

• This would allow creators to decide whether their tools requires the joystick to work in the absence of a touch pad that is used on index controllers. This can, kind of, already be done by disabling secondary, but this then disables the secondary functionality all together which isn't a viable solution in some instances.
• Possible downsides:
• I honestly don't see any major downsides to this solution then some tools not functioning the same way as users may typically expect. (although this already happens with users expecting the same locomotion they are used to on index when they swap to any other headset that is not compatible with index controllers).
• There may also be a lack of documentation for users that are unaware of this option and thus may get stumped when trying to find a solution. ( Although this already happens when users try to find a solution to disable tank controls in the first place.)

Final thoughts:

• Hopefully this is enough to show that there are other viable alternatives (and many more that I can list but this comment is long enough as is), and that this issue should at the very least be reconsidered. I understand that this issue won't be solved for quite some time due to the current circumstances but after this issue being posted 2 years ago and no one else has attempted to suggest / find other possible solutions in the past year, that have not been dismissed, ( apart from #1969 but that solution still feels like a compromise for those who simply cannot afford index hardware) I thought at the very least I could share my 2 cents on this matter.
• Until then I, and many others, will most likely be using community made solutions.

[shadowpanther]

I agree that this issue needs to be considered again. Personally, I'm in favour of separating "use secondary" and "use joystick axes" into two separate options. That might require to update some older user-made tools, but also that new property might be made to copy the old behavior on older schema load, and the default tools updated to not require axes specifically.

[Lexevolution]

To add my two cents to this, I believe that the control scheme that is used most of the time, should not be overriden unless explicitly stated. Some of the current default tools, do not state anywhere that their secondary axis (which isn't even in use for them) overrides the default joystick axis action. I think it is okay that it does override it, but I think it should become a habit for creators of tools and for the default tools to notify the user when default functionality changes.

Also if creators need to use it, to only enable it when needed.

The best way would be to have separate secondary options for click and axes, like @shadowpanther states. Another idea I had would be to combine menu and context buttons, like the vive wands, to free a button on the controller, and have some secondary functionality there, and only when needed, the joystick sencodary functionality would turn on and override the default functionality.