Content Update Preview bug

Unity Engine
,
1

I am using Unity 2019.4.22f1 and Addressables 1.16.19. But I guess this bug happens on every Addressables version and every Unity version.
I have a Prefab in a group, the prefab has a MonoBehaviour script attached to it. I execute the New Build option. Then I modify the script without changing the serialized properties and fields, for example, I just add a space somewhere in the script, then run Check For Content Update Restrictions. We will see that the group shows up on the Content Update Preview window. However, the prefab wasn’t modified, why is it being regarded as the bundle that will be changed after running Update A Previous Build?

2

Hi @better_walk_away thanks for reporting this issue! You’re correct, changes to serialized data should be indicative of a bundle change. The “Check For Content Update Restrictions” tool is calling AssetDatabase.GetAssetDependencyHash to determine if an addressable asset has been modified, which currently produces different hashes for MonoBehaviour whitespace changes. I was able to reproduce this on Unity 2021.3.3f1 and Addressables 1.20.3. Will create a bug ticket for this.

3

You can add a few line codes to exclude C# file detection in Packages/Addressables/Editor/Build/ContentUpdateScript.cs(e.g.:Addressables1.19.19).
I don’t 100% sure whether it will cause any bugs.

    public struct AssetState : IEquatable<AssetState>
    {
        public bool Equals(AssetState other)
        {
     
//exclude C# Start
if(guid == other.guid && hash == other.hash){
    return true;
}else{
    var assetPath = UnityEditor.AssetDatabase.GUIDToAssetPath(guid.ToString());
    if (assetPath == null) {
        UnityEngine.Debug.LogError("Can not find Path:" + guid);
        return false;
    }else if (assetPath.EndsWith(".cs")){
        UnityEngine.Debug.LogWarning("C# default is consider equal:" + assetPath);
        return true;
    }
return false;
}
//exclude C# End
            //return guid == other.guid && hash == other.hash;//You should also comment this line
        }
    }
1 Like
4

If I guess it right, all scripts are reside within the app. Prefabs only contain a GUID that map to the scripts they use. Thus, skip checking the script content should not cause problem. At least I will design it this way. Hope they fix this soon. Very annoying issue.

5

THX for giving me confidence

6

Thanks guys! I am waiting for the official fix.

7

BUMP.
This is a very important bug to fix, it basically makes content update unusable on our project when we have thousands of prefabs being flagged as changed just because we update a script.

8

Hi, can you advise when this will be fixed?

9

Hi all unfortunately this bug won’t be fixed because it would be difficult to resolve. This behavior will be added to the documentation.

10

That’s not good enough? Lol. I think I can speak for almost anyone using addressables in any real project… There is a clear separation between scripts and assets.

You can push out bug fixes and such as long as you do not break serialisation information. Your new code will be compatible with old bundles. This is very important.

It already feels like the content update pipeline is extremely brittle.

You need to build bundles on the same machine, on the same version of Unity, with the same build cache…
for perpetuity! Otherwise a bundle update will cause all bundles to be dirty and to be redownloaded again by users.

Our largest cost for our game (online features) is content distribution by far. The cost of distribution is thousands per month in contrast to the cost of hosting our game servers, database, email server all combined.

We’ve put in the hard work to make sure our updates will result in smallest download size as possible. We need unity to not drop the ball on this one and figure this out on their end.

The implication here is scary, because it means that “scripts changes dirties all prefabs” is now ‘documented’ and you are even warned about it via editor tooling…which could mean in the future Unity may lean into this and actually break support for this for real. (Where script changes dirty all prefabs for real, not just a misleading message in some editor tooling).

That would be really bad.

11

It would be nice if you could at least offer a different hashing function that excludes scripts and let us toggle it on in the preferences or something.
Content update cycle is such a mess it seems you cannot change anything in your project otherwise it flags everything as changed, so at that point you are rebuilding most bundles again anyway.

Like Prodigga said above, this ends up costing us money in hosting and distribution costs.

12

Hey y’all, let me clear a couple things up. Most importantly, your actual asset bundles should not be changing during the content update build. The issue here is that the check for content update restrictions window is using an AssetDatabase call to try and preempt what’s changed so we can make you aware prior to building. After discussion, we determined that although this is something that we’d like to improve, it’s not a ‘bug’ - which is a distinction that probably matters more to us than to users. But it matters for our team since it affects when & how we can resolve the issue. It just doesn’t have the full context that the build pipeline would after performing a content build.

We know content updates are a critical workflow for many Addressables users, and we want to improve how well we support that workflow. We have been exploring some improvements in this area recently and your feedback will help us a lot as we move forward with prototypes and development.

In our documentation about Content Update builds, you’ll see that you can turn off running the Check for Content Update Restrictions as part of the build process. Do this and it’ll remove the issue you’re seeing. Again, in no situation did this actually change your AssetBundles. If you disable this check, and your bundles are changing when you are absolutely positive they shouldn’t be, please file a bug for the build team to look at.

Because a proper resolution for this issue is non-trivial and involves dependencies on other teams’ code base, we decided that documenting the behavior was the best short-term solution that would help users understand what’s happening.

Let me say, I sincerely appreciate the community interactions on the forums. I think there are a lot of great ideas that come from this. I also think it’s good that our users can hold us accountable for bugs or issues in our tool. But please keep in mind that our developers take time out of their day to try and help you, to help users, when issues arise. We’re frustrated by these issues too, but we always try to respond with empathy and respect. I would appreciate it if we could keep responses to my developers civil as well, knowing there’s a person on the other end who’s just as frustrated as you may be.

2 Likes