Game objects appearing/disappearing after scene change. Problem with remember visibility?
I have a set of nested objects that needs to be shown/hidden during various actions the player takes. All these objects have a sprite renderer component, a remember visibility and a constant id.
The actions in the AL turn on/off these objects just fine. The problem is that when I leave and re-enter the scene, some of the objects that should be hidden are showing. And sometimes it's not even the same ones!
I made a small video where I show how after saving/loading (but the same happens if I leave and re-enter the room) a second rope (that should stay hidden) appears behind the first one. After a couple of tries even a mask on the rope segment on the left appears (this is inconsistent as sometimes happens immediately, sometimes after 2/3 tries, sometimes when the mask appears the additional rope disappears).
All of these (the left rope, right rope, the other rope behind, the mask, and both the macro objects that contain all of this) have all the components stated above
Some of them have an animator, but none of the animations affect objects visibility. I also tried to disable the animator component and the result is the same
This is the hierarchy of the objects, and these are the properties of each during gameplay and how they change just before/after scene switch.
In the action lists I usually turn on/off the containers (ropeAscending/descending) with "affect children" and then fine-tune each sub-object visibility individually as needed. Not sure if this is a good practice, but again, until the room switch everything works fine so I suppose the problem isn't in how the AL are structured.
The action lists that manipulate all of this are a several and some are pretty complex, so I'm not really looking forward to re-do all of the work just to potentially end up with the same problem. not sure what to do at this point.
I'd really would love to understand the problem at the root of this behavior so I can not only fix this rope thing, but avoid a similar situation in the future.
Any advice is welcome.
thanks!
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
Of course a minute after making this post and seeing it written down in an orderly way, I got a suspicion: "remember visibility" doesn't care about object hierarchy. So after the switch, all objects get switched on/off according to their last status, **including ** the containers, all simultaneously. This means that if the containers get processed a microsecond **after **the sub-objects, their status (that include "affect children") will of course again turn on the visibility on the sub-objects, despite their previous status. This also explains the inconsistency of the behavior, because it depends on the "race" between (I suspect) asynchronous processes.
With this hunch I disabled "affect children" on the containers and adjusted few things in the AL to accomodate this (basically managing visibility of each sub-object individually every time), an the tests seem in fact to confirm this theory.
I would love official confirmation if this might be the actual reason. And maybe a suggestion about how to handle situations like these: where we might have a macro container with conditional visibility (something that might enter the game at a late stage) containing lots of children, all of which have their own logic to appear/disappear. In the present case it's not that difficult (it's just few children to handle), but it might be useful to know how to deal with potentially more complex cases
thanks!
Sounds about right.
Indeed, the order in which save components are loaded will affect the outcome if you have the same property affected by more than one component. I suspect this order may even vary, but that's getting into the inner workings of Unity.
"Affect children?" should only be checked if all children should be set to the same state as its parent. If it's anything else, uncheck it and rely on separate Remember components for each.
For more complex situations, I'd recommend the use of an Animator to control the visibility of an object and its children. You can then rely on a single Remember Animator component on the root.