Many ContentCatalogDataEntries for unused types(e.g. UnityEngine.Events.PersistentCallGroup)

Unity Engine
,
1

I found a prefab which has the following components causes many ContentCatalogDataEntries in the catalog:

  • MeshRenderer
  • MeshFilter
  • SphereCollider
  • Canvas
  • Image
  • Text
  • A MonoBehaviour with a AssetReferenceGameObject field

The ‘ResourceType’ for these ContentCatalogDataEntries are:

  • UnityEnigne.GameObject

  • UnityEngine.UI.MaskableGraphic+CullStateChangedEvent

  • UnityEngine.Events.PersistentCallGroup

  • UnityEngine.UI.FontData

  • UnityEngine.AddressableAssets.AssetReferenceGameObject

I looked into source code, and found the following code:

static internal IEnumerable<Type> GatherMainAndReferencedSerializedTypes(ObjectIdentifier[] ids)
{
    if (ids.Length > 0)
    {
        Type[] typesForObjs = ContentBuildInterface.GetTypeForObjects(ids);
        HashSet<Type> typesSeen = new HashSet<Type>();
        foreach (var objType in typesForObjs)
        {
            if (typeof(Component).IsAssignableFrom(objType))
                continue;
            Type rtType = AddressableAssetUtility.MapEditorTypeToRuntimeType(objType, false);
            if (rtType != null && rtType != typeof(DefaultAsset) && !typesSeen.Contains(rtType))
            {
                yield return rtType;
                typesSeen.Add(rtType);
            }
        }
    }
}

As the code shows, it only filters the subclass type of UnityEngine.Component.

I think there should be only one ContentCatalogDataEntry(ResourceType is UnityEngine.GameObject) for this prefab.

2

Hey, thanks for the feedback! I’m just curious, is the current code breaking something in your project or is more of a performance concern? I can make a ticket for us to look into this, but it’ll help to have as much context as I can. Thanks!

3

Hi, thanks for the reply.

It dosen’t break anything in our project. I found this issue when I’m finding what causes the size of the catalog become large. I found there was 35017 ContentCatalogDataEntries in the catalog and some of them were not expected like ContentCatalogDataEntries above.

I modified the code of GatherMainAndReferencedSerializedTypes method to filter types which dosen’t inherit from UnityEngine.Object. The count of ContentCatalogDataEntry reduced to 21638, although the difference of the size of the catalog is small (reduced 0.61MB).

I submitted a bug report for this issue, IN-2627.

4

Hi,

I have the same issue , it seems. Is Alan’s suggestion just treating the symptoms or the root cause? It seems that the fix should be somewhere deeper in the ContentBuildInterface.GetTypeForObjects(..) method, right?
Anyway, is there any ETA for a patch/fix?
Modifying a package’s code is less ideal…

Can you edit with the link? I cannot find that issue number anywhere. Thanks!
Btw, can you paste your modifications exactly?

5

Unity QA has not reproduced the issue, so I don’t have a link in issuetracker.com.

My modification to the source code:

static internal IEnumerable<Type> GatherMainAndReferencedSerializedTypes(ObjectIdentifier[] ids)
{
    if (ids.Length > 0)
    {
        Type[] typesForObjs = ContentBuildInterface.GetTypeForObjects(ids);
        HashSet<Type> typesSeen = new HashSet<Type>();
        foreach (var objType in typesForObjs)
        {
            if (typeof(Component).IsAssignableFrom(objType))
                continue;

            ////----
            if (!typeof(UnityEngine.Object).IsAssignableFrom(objType))
                continue;
            ////----

            Type rtType = AddressableAssetUtility.MapEditorTypeToRuntimeType(objType, false);
            if (rtType != null && rtType != typeof(DefaultAsset) && !typesSeen.Contains(rtType))
            {
                yield return rtType;
                typesSeen.Add(rtType);
            }
        }
    }
}
1 Like
6

Thank you. Good news: I could get a repro!! Waiting for it, case IN-7105

1 Like
7

Hi all this will be fixed in the next release (1.20.2)
“Fixed issue where Serializable types of structs and class members of MonoBehaviour or ScriptableObjects would be returned as a location with GetResourceLocations but would not be loadable.”

There is an internal ticket regarding this issue that was sent to us earlier.

1 Like
8

Niiice! Any ETA?