HMD Position causes Unit Mover to move backwards

[Dustin_Fike]

I have an Oculus VR project where I have set up to move in first person VR with collisions.  I am using the thumbsticks on the touch controllers to move like an FPS (left thumb = move/strafe, right thumb = rotate).  I am getting a weird result with my movement that I can't explain.  When I test run the project, if I am sitting near the center of the play area, then the unit mover wants to move backwards continuously.  I put in a branch condition so that the "Move Mover" node only activates if the thumbstick is being manipulated.  Otherwise I was immediately shooting off backwards when I started the level.

If I am sitting, but up close to my monitor, then it works as normal.  There is a gradation in speed that if I start sitting close to my monitor with it working normally, as I roll my chair back towards the center of the play area, the speed at which my mover moves backwards increases.  However, once I pass the center point of my play area, the unit mover wants to move forward.  If I continue to push my chair back towards the back end of my play area, then it again starts to work normally.  There are some areas where the movement controls don't respond at all, but i haven't been able to nail down exactly where or when that happens.

If I am standing, it seems to work as expected no matter where I am in the play area.

I set it all up in flow, but I can't seem to be able to find where the HMD position would affect the mover.  Could someone please point me to where I have something set up wrong?  Thanks.

[__ben__]

Nothing immediately obvious jumps out at me. Debugging these sort of issues can be tricky, especially when numerical precision issues are at play. Since it works when standing and unexpected behavior occurs when near the monitor, try using Flow debug nodes (http://help.autodesk.com/view/Stingray/ENU/?guid=__flow_ref_cat_Debug_html) to print out intermediate values. Make sure they are consistent with the equations you are implementing. Repeat when errors occur and compare values looking especially for very small or very large values that could exacerbate rounding errors. But this is just a guess from which to begin debugging and I can't be certain that numerical errors are involved here.