On some cases - when teleporting using the oculus quest controllers, the teleportation state gets "stuck" even thou the finger is off the trigger.
This is hard to reproduce, and, according to initial investigation, actually happens because the "touched" state is not updated correctly.
Need to make sure that :
1) touched/pressed state is correctly updated (i.e. - is it a driver/browser problem, or a problem with our implementation)
2) is there a way to make sure that it works correctly, even when touched is not correctly set. For example - if the thumbstick is exactly at 0,0, we can assume that the user has let go the thumbstick (even if touched is 0). This is not foolproof, but a way to make sure it does work correctly.
3) other controllers are working correctly. In personal tests - i couldn't recreate that using the MS MX controllers, but i am not using the MX controllers on a daily base
After a quick investigation - it seems like the touch controller is not always detecting touch events (even when it is clear that the component was touched). In case anyone wants, I have a video showing the issue.
When touching or pushing the edges of the button the thumbstick doesn't register the touch, but does have its values change.
Recommendation here would be to find a different method to detect when a teleport started and when the teleport ended.
The best candidate is still the touch event. When the user touches the component and moves it forward - a teleport started. In this case it is possible to detect when the teleportation started even without the touch event - if the axes moved forward, teleportation started.
Regarding teleportation ended - the issue here is that the rotation of the future position is based on the current axes position. We could say that when the axes are at 0,0 (i.e. The user released it) the teleportation is done, but there are two problems:
1) The final rotation might be wrong
2) The user can still move the axes to the middle during a rotation.
What will (probably) be developed is this:
1) Rotation of the future teleportation position will be calculated based on a previous position of the axes (a few frames back, will have to investigate what the number will be). This will lead to a short delay in visually changing the rotation, but if we are talking about 5-10 frames it will be unnoticeable / acceptable.
2) When axes stay 0,0 for a few frames (less than the number of frames in (1) - it will be considered a teleportation-ended event. In this case we could also inspect a change in delta for a short period of time, but this can be problematic when releasing the thumbstick close to the middle.
Both will be integrated WITH the touch event. We need to ignore touch events during a single teleportation if the even started using the axes instead of touch.
I independently discovered that tapping the thumbstick confirms as a touch and moves the view properly. It makes it tough to use the axis turning feature before teleporting and if attempting to use I face the wrong direction often. I can produce it every time I use an Oculus Quest on the Oculus Browser. Happy to pull any logs if needed/desired since I can get it to do this every time.
This is the same finding I have. If pushed from above, teleportation works, but if pushed from the side, the touched parameter is not set correctly, so teleportation never ends. Will be fixed :-)
Most helpful comment
After a quick investigation - it seems like the touch controller is not always detecting touch events (even when it is clear that the component was touched). In case anyone wants, I have a video showing the issue.
When touching or pushing the edges of the button the thumbstick doesn't register the touch, but does have its values change.
Recommendation here would be to find a different method to detect when a teleport started and when the teleport ended.
The best candidate is still the touch event. When the user touches the component and moves it forward - a teleport started. In this case it is possible to detect when the teleportation started even without the touch event - if the axes moved forward, teleportation started.
Regarding teleportation ended - the issue here is that the rotation of the future position is based on the current axes position. We could say that when the axes are at 0,0 (i.e. The user released it) the teleportation is done, but there are two problems:
1) The final rotation might be wrong
2) The user can still move the axes to the middle during a rotation.
What will (probably) be developed is this:
1) Rotation of the future teleportation position will be calculated based on a previous position of the axes (a few frames back, will have to investigate what the number will be). This will lead to a short delay in visually changing the rotation, but if we are talking about 5-10 frames it will be unnoticeable / acceptable.
2) When axes stay 0,0 for a few frames (less than the number of frames in (1) - it will be considered a teleportation-ended event. In this case we could also inspect a change in delta for a short period of time, but this can be problematic when releasing the thumbstick close to the middle.
Both will be integrated WITH the touch event. We need to ignore touch events during a single teleportation if the even started using the axes instead of touch.