GuidReference cannot be resolved if GuidComponent is disabled in its scene

[bschug]

Scene A:
--> Object AA:
-------> Disabled in the scene
-------> Has a GuidComponent

Scene B:
--> Object BB:
------> Has a GuidReference pointing to AA
------> Has a MonoBehaviour CC that will run guidReference.gameObject.SetActive(true);

Load scene A first, then load scene B and try to run CC.
This will fail because AA will not have registered with the GuidManager.

Expected Behaviour: If scene A is loaded, GuidReferences to any objects in that scene can be dereferenced.

[alijaya]

Yes I encounter this too... Any update on this?

[usernameHed]

up

[terrehbyte]

It looks like the GuidReferences register themselves with the GuidManager during Awake():

guid-based-reference/Assets/CrossSceneReference/Runtime/GuidComponent.cs

Lines 139 to 142 in b56fef0

	void Awake()
	{
	CreateGuid();
	}

It obviously doesn't run if the object is disabled, so a workaround is needed. A few options come to mind off the top of my head:

Don't refer to disabled objects

Unity seems to have a implicit design that treats disabled objects as functionally non-existent, most of the time. This is great when you want that behavior (e.g., disabling Colliders or AudioSources to turn them off), but not so much when you don't.

This same design extends to Component.GetComponentInChildren, which by default, does not search for inactive components.

Given this, you could give it a "locator" parent GameObject whose role is to stay active and guarantee access to its child, the actual object you want.

External "activator"

If you can call CreateGuid() somehow (making it public or using reflection), then you could allow an external component (on an object that won't get disabled) to run during scene startup that iterates through a list of GuidReference instances and tells each one to register itself.

You'd also need to flag it internally on the reference to prevent it from adding itself twice, if it does eventually get activated.

It is a bit of a monolithic approach, but we're working with a monolithic system anyway, so it doesn't seem like a reach. 😋

...

I personally went with the "activator" approach for a save/load/addressable system that needed to expose things by ID, which worked well for my purposes.