[SOLVED] Destroying the OVRPlayer Controller/freezing issues

In case anyone hase the same issue there is a simple workaround.

Move the Player.

1. Make a script that Instanciates the player and attach it to an empty GameObject.
2. Associate your OVRPlayer Controller Prefab with this scripts prefab variable in the Inspector.

 
var prefab : Transform;
function Start(){
clone = Instanciate(prefab);
KillPlayerScript.player = clone;
}

3. Make a an empty GameObject, its position will be where the player will respawn.
4. Attach this script to what ever is deadly to the player.
5. Associate the SpawnPoint GameObject to this script in the Inspector.

var spawn : Transform;
static var player : Transform
function OnTriggerEnter(other : collider){
    //change the tag to what your player is tagged.
    if(other.collider.tag == "player"){
       //this is an example of how to count/save the remaining lifes
       if(Globals.Lifes > 1){
           Globals.Lifes -=1;
           player.position = spawn.position;
           }
       }


        if(Globals.Lifes < 1){
            Destroy(other.GameObject);
        }

}
}

Something like this will do the job but i miss the fade-in effect upon respawn.
Will have to steal that out of the Oculus Scripts :mrgreen:

I wonder if anybody else is having this problem or just me.

Can somebody please check?
Kind regards

P.S.: Typed this at work so there can be typos and syntax errors in there.

Hi Felixs,

I think I have just run into the same problem, or at least a similar one. In my case I noticed that when a new level is loaded the OVR device position is reset to whereever the player was looking at the point the new level loaded, which frequently was not central.

My thought was to turn the player gameObject into a singleton, in other words to have the player gameObject in the new level destroy itself in favour of the one that was already there which had DontDestroyOnLoad(gameObject) applied to it. Now Unity freezes when I load the new level and I can see in the inspector that there are two player objects, one with it's children and the other without. I've only just encountered this so I've not spent time trying to straighten out what is going on. I thought I'd share my experience though, since it seems to resonate with yours.

Cheers,
Mark

My first instantiation in every level does work.
So there is no need for me to use DontDestroyOnLoad.

... the OVR device position is reset to whereever the player was looking at ...

I have that issue with edges made by the Terrain tool kit.
Once i reach an edge it positions the ovr controller at the same hight where i look at.
For instance the other end of the gap.

No issue with the terrain using the standart unity 1st person controller.

I kind of worry that i will have to dig trough the scripts to find what is causing that...

have the player gameObject in the new level destroy itself in favour of the one that was already there which had DontDestroyOnLoad(gameObject) applied to it

Now Unity freezes when I load the new level

Any errors? You probably have two audio listeners in the scene and maybe other complications.
Do you activate the Gameobject that was already there once the other one is destroyed or is it active all time?

Greetings
Felix

"Felixs" wrote:

Any errors? You probably have two audio listeners in the scene and maybe other complications.
Do you activate the Gameobject that was already there once the other one is destroyed or is it active all time?

Hi Felix,

Thanks for your reply. Yes it did complain that there are two audio listeners, although if I untick the AudioListener I still get a freeze when I load the second level, and in that scenario there are no errors. It just stops responding to Rift movement.

So this is what I have:-

playerObject - with DontDestroyOnLoad() and the PlayerSingleton script below on it, it has various child objects including the OVRCameraController. When I load level 2, which contains a playerObject, that triggers the hang. At the point it hangs I can see in the inspector my original playerObject and a second one which has no children.

If I apply the same scripting to a Cube then it works properly. The original cube stays in place and the cube belonging to level 2 exits immediately.

PlayerSingleton.cs:-

using UnityEngine;
using System.Collections;
using System;

// Singleton HighScore Controller
public class PlayerSingleton : MonoBehaviour {
	
	public static PlayerSingleton _instance = null;
	public static PlayerSingleton Instance { get { return _instance; }}
	
	// Use this for initialization
	void Awake () {
		// Enforce us as a Singleton gameObject (if we were beaten to it, then destroy ourself)
		if (_instance != null) {
			Debug.Log("PS: Awake -> Destroy");
			Destroy(gameObject);
		} else {
			Debug.Log("PS: Awake -> Keep");
			_instance = this;
		}
		DontDestroyOnLoad(gameObject);
	}
}

Anyway, I hit this problem because I was trying to solve another one. I'd like to avoid an OVRDevice.OVR_ResetSensorOrientation() when a new level loads. Is that possible?

Cheers,
Mark

Ah, I see folks have already discussed the issue of orientation resets between level loads:-

how to reset the view?
Maintain Orientation from level to level in Unity?
Persistent 'forward' direction

Having read those I've now created a menu scene in which I create my playerObject and I use DontDestroyOnLoad(gameObject) on it. I've removed the player object from each scene and now I get a consistent experience if I start from the menu and load any level. I just need to position the player on each scene load.

This is fine for the final game experience. It's less convenient for testing, but during development I can simply add a playerObject into the scene I'm working on and remove it later.

Cheers,
Mark

Hey Mark,

I'm glad you found a solution to your problem.

I found out where my other issue (player moves at edges) originates.
I am going to create a seperate thread if I can't find any existing.

Since I already posted a workaround to my initial issue I changed the topic to [SOLVED].

So long
Felix ;)

Deleted my new thread.
One of my own scripts made the ovr player controller go nuts :oops: