GVR Pointer Input Manager, and Standalone Input Manager conflicting in build.

I'm back with another problem!!
I've built a cockpit, and I have some monitors in the corners of the cockpit that are magnified when looking at them. In the editor this looks great, however when I build to android, none of the UI navigation works.

I've done 10000 x 10^3 googling on the subject, and seems that no one has come across this exact issue. I swapped the Input module order in the Inspector, moving Gvr to the bottom, and standalone to the top. This reversed the problem. My Menus now work... but the zoom option isn't recognised!

I'm now re-building again, with a separate Event System on another gameobject, to see if separating the two will help... however I'm not confident... pics to follow!

Exhibit 1, Standalone input seperate from Gvr input. Gvr input event system navigation disabled. Pointer event never occurs. In this situation using the controller to move the menu options works but as you can see... the screen is TINY!

Exhibit 2, Standalone module underneath the Gvr Pointer. Zoom now plays, however menu is completely dead.

And finally, the Inspector as it sits in the second image.

 

Update** Through some heavy trial and error, I've had to end up basically writing my own navigation script.

Turns out an event system can't properly sort between two input modules in this case, it just priorities the Gvr Input module, or the Standalone, without even recognising the other input module.

As it stands, each button selection basically looks like this...

Code (csharp):

1.  
2.         if (EventSystem.current.currentSelectedGameObject == cargoButton.gameObject && leftRight > 0) {
3.             selected = landingButton.gameObject;
4.             EventSystem.current.SetSelectedGameObject (landingButton.gameObject);
5.         }  
6.  

And then to effect the OnClick function I'm using this;

Code (csharp):

1.  
2.         if (Input.GetButtonDown("Submit")){
3.             selected.GetComponent<Button>().onClick.Invoke();
4.             }
5.  

Its going to need some fine turning but it **should** eventually replace the navigation system that relies on the Standalone Input Module.

 

You could build your own input module, but if your not looking to do that couldn't you just enable only 1 of the input modules and disable the other at runtime depending whether you are in vr mode or not?

 

At the moment, The game is solely VR,(I do plan on being able to switch, but one step at a time!! Thats another big bridge(for me) to cross!) I did actually try this as well, unfortunately the same problem happened. As you say, currently building my own menu Input module. Just need to work the navigation system in there and it will save me a metric ton of work.

**Edit, to be clear, I still intend on having the player look at the screen, VR or not, just the non-VR version will use a free-look method when a button is held!

 

This may be a bit late, but I had this problem. The GvrInputSystem doesn't seem to accept touch input and I needed touch input in non-vr mode, so I simply turn off googleVr's input and turn on Unities native input. What I did is have two game objects, one of them named UnityEventSystem and its components were EventSystem, StandaloneInputModule, and BaseInput. The second GameObject was named GvrInputModule, attached is EventSystem, GvrPointerInputModule, and BaseInput. In my startup script which manages the entire game as a singleton, I ensure the GvrInputModule is the only game object active for one frame(I used a coroutine to deactivate it and activate the unity game object only after one frame has passed) then choose to either keep it on or turn it off and turn on the UnityEventSystem (depending on what vr mode we start in).

I know its a bit of a workaround, but its a bit time consuming to make your own input module, and for my purposes, I didn't need google vr's input while not in vr mode. If googleVr's input module isn't activated first, it will never activate, if Unity input module starts first (or any other for that matter).