Had to lookup view that wasn't in dict warnings

After updating PUN to the latest version “Had to lookup view that wasn't in dict: …” warning begun to fire every time I’m using PhotonNetwork.Destroy(gameObject).
Could somebody please help me find a way to avoid such warnings?

Comments

  • What is the timing between Instantiate and Destroy?
    PhotonViews add themselves to the "lookup" dictionary when they Awake. If they never do, this might be the problem.
  • Tobias wrote:
    What is the timing between Instantiate and Destroy?
    It's about ~1 min and more.
  • Hm. Maybe this is a problem if the PV is not active. Do you ever activate said Game Object and it's PVs?
  • Do you ever activate said Game Object and it's PVs?
    Yeas, they are active all the time. Or, more correctly, I don’t use script de-\activation at all in my project right now.

    I have to say, that I’m using “PhotonNetwork.InstantiateSceneObject()” method to instantiate those objects and also giving them instantiation data argument. It looks like this (in the script Awake() func, that starts with the scene):

    [code2=csharp]GameObject actor = PhotonNetwork.InstantiateSceneObject("prefab_name", Vector3.zero, Quaternion.identity, 0, new object[] {1});[/code2]
  • Can you build a reproduction project? Something small enough to share and look at?
    If the PVs are all active (no matter if by script or by Checkbox in inspector), they should be listed after awaking.
  • Please excuse me, I worked this problem out and it was my own fault for being inattentive: I was trying to use RPC on PV of the object, that I destroyed a moment ago and warnings were firing because of that. Though it’s still confusing me why the PVs of the destroyed objects were still accessible…
  • Destroy() is delayed until the end of the frame. You can use GOs and PVs in the same frame that also destroys them. PhotonNetwork.Destroy calls the regular Destroy at some point, too. Maybe that's it?

    I will think about if we could add another log entry for that special case.
  • Yes, that makes sense, as in my case referencing to PV and destroying it were definitely executed faster, than any possible framerate. Thanks for the clarification.