Driving `/input/Voice` with `pythonosc` Unexpectedly Changes Controls

[rrazgriz]

Describe the bug

When driving the endpoint /input/Voice with the pythonosc library, input properties change unexpectedly. The same does not happen when using Hexler TouchOSC.

On Desktop, the Mute/Unmute keybind stops working, and the "Bindings" menu shows Vive controls instead of Keyboard/Mouse controls.

On VR, the controllers appear to stop tracking in-game. Menus appear in front of the HMD as though controllers are disconnected. Buttons and joysticks on the controllers still work.

To Reproduce

Steps to reproduce the behavior:

1. Send either an int (values 0/1) or a bool to the endpoint /input/Voice using the pythonosc library with "Toggle Voice" in any state.
2. Observe problem described above.

Expected behavior

Driving this endpoint should not cause input properties to change.

Screenshots

Desktop "Bindings" screen before/after driving /input/Voice:

Video of issue occurring:

https://user-images.githubusercontent.com/47901762/157234999-86998b92-0868-4d7a-909a-0e99ba0bb7c3.mp4

Info (please complete the following information):

• VRChat 1170 2022.1.1p1-3a3af3e29b (Desktop)
• VRChat 1181 2022.1.2-ce57a0e100 (VR)

Additional context

Issue was observed on two separate machines, both using pythonOSC with Python 3. TouchOSC was noted to not have the issue on the Desktop/1170 machine.

The problem is reminescent of #107, with strangeness in input, but the two may be entirely unrelated.

H/T to @CatGirlEddie for helping narrow this down, and testing on beta 💯

Minimal example python code:

from pythonosc import udp_client
from time import sleep

osc_client = udp_client.SimpleUDPClient('127.0.0.1', 9000)

osc_client.send_message("/input/Voice", int(0)) # or True instead of int(0)
sleep(0.01)
osc_client.send_message("/input/Voice", int(1)) # or False instead of int(1)

[CatGirlEddie]

Tested and repeatable on my system with Python 3 using PythonOSC & pyOSC3, as well as Lua using OscCore using /input/Voice and /input/MoveForward, same symptoms appear.

[ZenithVal]

If done while the user is in VR, it forces the arms into desktop animations.

Reproducible with axes (/input/Horizontal, /input/Vertical, and /input/LookHorizontal)

[rrazgriz]

Confirming that this still causes issues, at least on desktop - the Mute/Unmute keybind stops working, although the menu no longer switches to the vive controls. Have not tested on VR.

[ZenithVal]

Still causes a force of desktop animations in VR.

[ZenithVal]

McArdellje on the canny pointed out some more information on this along with a workaround. https://feedback.vrchat.com/feature-requests/p/osc-locks-arms

"This specifically only occurs when using any /input/ OSC parameters and, while still a bug, can be worked around by setting the parameter's value to 0 at least once per second."

[Raphiiko]

Can confirm I'm running into the same issue here. I cannot use /input/Voice without the Index controllers losing tracking.

[ZenithVal]

This issue appears to be resolved on VRChat's most recent Open Beta. (Build 1340)