Addressables 1.11 broke all our code and the change causing it is not in the release notes...?

As I mentioned in another thread , in version 1.11 many methods crash if the Addressable does not exist, instead of returning a null asset or a download size of 0. This was a massive breaking change for our code and I’ve been trying to deal with it for hours.

However, this change doesn’t seem to be in the release notes. Is it there? Can’t find it.

(We have a system of downloadable songs using Addressables. Each song might or might not have certain files, but we don’t know before checking.)

Now we have to call LoadResourceLocationsAsync EVERYWHERE for each file and see if the returned list has at least one element (also, more memory allocations). We also have to cleanup the handle for this.

Or just edit the package to bend to your will. You will be much happier that way. :wink:

You mean the built Addressables? The best we could do would be to have another file in the addressable listing the other files. What if we had already released to the public? I just find it baffling that I can’t even be warned of such a large change in the release notes.

No, I mean pull the Addressables package into /Packages as an embedded package and patch it yourself. At the same time, submit a bug for this. It should be fixed in the package but in general the fact that the package comes with source is a great boon, you can do what you want with it.

Ah, that. I could fix temporary bugs with the source, but:

  • This probably isn’t a bug, just a breaking change that is undocumented.
  • If the library changed something permanently that breaks compatibility (i.e. not a bug) our code should conform to the changes or else we have to stay on the same out of date version forever.
  • Any changes to their source are lost with each update.
  • The sources are located in the easily discardable Library folder, in an aptly named PackageCache, so no way I’m editing that. :slight_smile:

And I realize you said to copy the package (forgot to address that), but that still gets us stuck forever on the same version, unfortunately.

Not really. We have been using customised versions of addressables since the first public release of the package. It’s easy to upgrade if you use reasonable version control.

What we do:

  • Add the package into the packages folder, removing the version from the directory name.
  • Commit to an import branch.
  • Make whatever modifications you want.
  • Merge to your dev branch.

To upgrade:

  • Update back to the revision you imported the unmodified package on.
  • Import the latest package (best done by deleting the old one and copying the new one in.
  • If using something like Mercurial, you may want to detect renames at this stage.
  • Commit.
  • Merge your changes in.

Most of the time there are either no conflicts or the conflicts are trivial.

As a bonus, it means you have a nice record of what changes the Unity team have actually made to the package.

For reference, we have custom packing modes for groups to properly handle our dependency structure.

1 Like

Thanks for explaining your process so well. This is interesting, especially the part “As a bonus, it means you have a nice record of what changes the Unity team have actually made to the package.”, which sometimes would be very useful.

Sigh. We may try this when we sort these updates out. I just wish things worked. Or that we were warned of the changes. I created 5 threads in two days, it’s infuriating. :frowning:

What makes you think that this is an undocumented, purposeful change rather than simply a bug?

Nothing concrete, really! It just seems like something they could change, and I find it weird that a bug on such a big issue wouldn’t be caught in two releases (although now I noticed that both 1.11 and 1.12 have the same release date, so there’s that…). It could be a bug.

DISCLAIMER: we had a bug with 1.10 on Android (couldn’t load a remote catalog), so we upgraded and found 2 more breaking bugs. Then I spent 4 hours fixing the problems to then find that although the bug with 1.10 was fixed there was YET another bug where downloaded addressables don’t report 0 bytes to download anymore, so it was all wasted time and my reasoning might be flawed due to frustration. :frowning:

I’m going to flag this for the team. I’ll be sure to update the thread with any insight they provide.

Thank you for flagging all of these for the team!

You bet! Team would like some more details. They attempted it and it throws an exception, but still works.

When you say crash, what exactly are you experiencing?

Sorry for the delay. Only today had I some time to look into this again.

What I meant by “crash” was the exception, yes. Do you mean that it’s only a log and causes no secondary effects? Or no? I was under the impression that the library only logs exceptions if “Log Runtime Exceptions” is enabled, and ours isn’t.

Our code was heavily changed because of these exceptions, so I can’t re-run the old code right now, but what we saw (and still see in 1.13.1) were exceptions for non existent addressables along the lines of:

Followed by our methods’ call stack (no method in the stack is from the Addressables package, so it won’t help).

This example is for an Addressables.LoadAssetAsync, but it also happens for Addressables.DownloadDependenciesAsync.

I hope this helps!

As a matter of fact, I noticed that other methods that previously didn’t log exceptions are now logging, such as LoadContentCatalogAsync. It’s as if the “Log Runtime Exceptions” method was now permanently enabled regardless of the setting.

So maybe everything we were seeing was a consequence of this…