after updating to the latest Unity patch 2017.2.0p2, I sometimes encounter the following assertion errors after closing an editor game session in play mode:
Assertion failed: Transform has SetIsDispatchInterested present when destroying the hierarchy. Systems must deregister themselves in Deactivate.
Follow-up messages
I turned on XR settings. (Oculus, Daydream)
When I load another scene using SceneManager, the below error occur.
Assertion failed: Transform has SetIsDispatchInterested present when destroying the hierarchy. Systems must deregister themselves in Deactivate.
Assertion failed: Transform has SetIsHierarchyDispatchInterested present when destroying the hierarchy. Systems must deregister themselves in Deactivate.
Do any of you have reproducible steps without using Vuforia? I can certainly reproduce this using the Vuforia steps, but as most of you are seeing this without Vuforia present, I want to run through some known cases to make sure the same fix works across the board.
Same here. Not using VUFORIA. I have an object that that starts in the scene. I delete that one in the game, and spawn a new one. When I delete the spawned one, I get this error, but not when I delete the original one.
@gudouan@Tyrathect Could either of you create a project that reproduces the issue and file a bug report with the repro steps? It sounds like Tyrathect you have one that is easy for you to reproduce.
If you can, please post the bug number on this forum and include this forum post in the bug report description.
I think chances are that this assertion issue might be somehow related to a previous assertion issue . I have some rough indicators for this guess. First, the previous assertion issue has been fixed in 2017.2.0p2. With this very same version, the new issue described in this thread started to appear. Second, based on my test results, I think that both assertion issues are related to scene complexity so that a higher scene complexity increases chances that the issue appears. Also, they both seem to be somehow related to the scene hierarchy.
So, in order to find the root cause of this assertion, maybe it is also helpful to look into the repro-cases and solution of the previous issue.
Can confirm that Steedy seems to have figured out the issue - this is confirmed on my project, whenever i end play mode in the editor with deactivated gameobjects with colliders on them i get a bunch of the errors. This happens in 2017.3.0f3
I had this problem today, using 2017.3.0f3 . I was reactivating a bunch of stuff in onDisable, which caused this error. Moving my code to onEnable solved this problem. Its weird since my code worked fine in older builds.
Was about to report same issue (2017.3.0f3).
Seems like a lot of assertions and errors appeared in 2017.3 or 2017.x which should never appear.
Earlier versions of Unity were much cleaner is this sense and quietly dealt with issues if there even were any
i get issue as well and i am getting it from my bullet pooling system.
i get the error when i use gameObject.SetActive(false); on a Instantiate gameobject at runtime
which my gameobject has 4 components a rigidbody, trail render,box collider, and a cs script
The way i got rid of the errors was not to call gameObject.SetActive(false);
the work around as of right not just store my bullet in a dark corner lol
Workaround for those who are using Vuforia.
Do not use default traking script. Default script iterate all colliders, mesh renderes and canvases to enable/siable them, while it is good for performance reasons (in case you have many game objects) it couse our errors. Change script (or better make new one, that just disable/enable game objects and not components. Ideally, make reference to all augmentation objects and make them enable/disable on tracking find and lost events.