Hi,
Alright, we continue to sort through Addressables implementation. I’ve two main things here, one of which feels like it’s probably a dead horse that continues to be beaten, but unfortunately, it is not apparent whether or not it’s actually ‘dead’ and so the beatings shall continue! 
1) Merge conflict w/ ‘Default Local Group.asset’, taking “–theirs” (upstream) == nullref storm.
See screenshots linked below. This is probably a bug, but maybe not. I’m also getting tired of reporting bugs via the “official” reporting process (see tangentially-related #3). I’ve run into this same issue after a merge conflict now 3X, each of the 3X I’ve dealt with it I’ve had to take the same steps. Details are under each image in the link below.
DETAILS – See these 3 Images w/ Respective Descriptions for each:
2) The documentation is awful.
Some of the prior documentation versions were actually better than the current version’s documentation, and that’s honestly bewildering.
- 2A) Googling for documentation nearly always gets you to outdated documentation.
It’s great you’ve added a “latest version” link at the top, though that nearly always takes you to the ‘top-level’ docs (also a problem throughout ALL Unity docs pages), which makes it damn near useless since the search sucks. You’re essentially traversing the namespace/class hierarchy, else you’re back to Google to search again.
I’d suggest either:
-
Setup ‘Canonical URL’ or HTTP headers to tell Google that the “canonical” (ie latest) version of the documentation for a given method and/or class IS the canonical version – basically this would make sure that Googling for “loadassetsasync label unity” will take you to the latest docs page version.
-
Entirely “NOINDEX”-ing the out-of-date docs so that Google doesn’t index them
-
Potentially using Schema.org markup to denote versioning on them, or likely some similar approach to let Google know that it’s the “same page, just out of date”; I’m out of web/SEO for a while now, but I’m confident it’s a trivially & perma-solvable problem with <=1 day of effort.
-
To illustrate this issue & make it really clear:
Literally, please try: open a private/incognito window and search for “loadassetsasync label unity”, and then click that first result. Oh, awesome you think – except then you notice you’re on the outdated docs. Ah, there’s a “View Latest Version” link – you click that, yay! Except now you’re back on the Addressable docs home page. Well, that’s right back where you probably f@#$'ing started – so that’s not helpful. Grrrr. -
2B) Examples People Need / Want Are Almost NON-EXISTENT [in latest docs]!!!
-
As a quick & very obvious experiment, try this and see how quickly you can find example code that works (compiles & works at runtime w/out errors) to “LoadAll” / get back an T[ ] or IList under these two circumstances (test w/ private/incognito for the full effect):
-
a) Using Resources LoadAll() – suggested search terms include “LoadAll Unity”, “Resources.LoadAll”, and similar. Essentially all results are great & have working examples – even if perhaps not the ‘ideal’ syntax, they’re functional!
-
b) Using Addressables/Async Load All; suggested terms:
“Addressables.LoadAssetsAsync” – Outdated. No functional code/example.
Basically any derivative of it, it “LoadAssetsAsync” or “Unity Addressables load label”, etc… -
You’re going to almost always:*
-
End up on an outdated page / old docs version.
-
Clicking “Latest Docs” is great – but super rage-inducing, always goes to index(!!!)
-
If lucky enough to find it on the latest, it’s almost surely going to be auto-generated documentation – you’ll be lucky to have the call signature documented. Code examples (and I’m talking 2-liners here) are nearly non-existent. Compare to the “Resources” loading documentation, where code examples exist & are functional.
-
The majority of the actual use-case & code examples that you will find via (google) search results are going to be on the Unity forums – click on a few of those, and take a look at them; they’re generally a bit concerning. Most will be talking about having issues/bugs, in some cases with a Unity rep noting “might be a bug”, and most of them are dated late 2019-ish and have no follow-up.
-
Seriously, just try finding a working example: how to load all assets that have a specific label – which one of these is right / what are the differences, and try answering these questions solely from the docs (it’s not possible btw – you will have to basically trial & error or get really lucky and stumble on a working code example from a forum post [likely a bug report] that may or may not still be relevant with today’s API – hell a semi-recent post suggests you may need to use brackets around your in-code label string):
-
Which of these is right, or what is different about them:
-
LoadAssetsAsync<List>(“label”);
-
LoadAssetsAsync<IList>(“label”);
-
LoadAssetsAsync(“label”);
-
LoadAssetsAsync({ “label”}, null);
-
What’s the difference between these two (is big difference):
-
LoadAssetsAsync<TMyType>("label", myCompletedAction); -
x.Completed += myCompletedAction;```
- Now, Google for how to load >1 assets using Resources.LoadAll – ie from a single folder) or similar. I bet you can have a functional code example on-screen in <30 seconds. The disparity here should be pretty obvious, and it’s not a small disparity, it’s one of Grand Canyon-like proportions!
FWIW – I ended up getting it working after an hour or two; I don’t know if the issue was related to my syntactical issues (ie the variations above), or if it was because my label had a “-” (dash) in it, or what. It’d be nice to find out, but it’d be even nicer to just have docs that explain precisely how to use this core stuff – so we can just get on with gameplay code! I won’t even start on “folder” loading; it suffices to say, it should have been a day-1 requirement / almost surely is the most common workflow.
3) I’m sick of reporting bugs via the “official” bug reporting tool.
Well, since I’m already ranting a bit here… The bug reporting process feels broken. Actually, I’m pretty sure it IS broken. Maybe not beyond repair, but there are problems here for sure.
-
When Unity devs are asking for the ticket/reference # in the forums, it’s a problem – likely it’s taking too long to go from “QA => developer” & so developers seek it out so they can do their job effectively and help people (because they care & want to do a good job). It may have other causes/underlying reasons too, such as QA struggling to understand/interpret/repro bugs, or similar. I’m quite acutely aware that this is a hard problem – and exists in all major software projects – but I know from experience that pretending that the system isn’t a problem (or worse, that it “works well enough” / status quo) means you are quite likely to find yourself buried in technical debt “suddenly” (and by “you”, I generally mean “leadership” – because the devs almost always already know, or suspect it to be the case at the very least).
-
Most of us that are using Unity in even a semi-professional way have games that are shipped or that are going to be shipping pretty soon. This poses several major issues with bug reporting:
-
We’re asked for repro projects but they’re often going to be massive.
-
Project “stripping” doesn’t really work because assets are almost always required.
-
I get that “big & slow projects” are no fun to debug – we ask our players to send us “minimal repro saves” whenever they report bugs, too. But when a bug happens on a massive save, we can’t & don’t ignore it. We even go to extremes to provide them a place to upload it, regardless of size. And then we have to wade through it, even if it’s miserably slow to load & runs at 3FPS in the editor – then that’s what we have to do!!
If the Unity editor (or a save file, in context of gameplay bugs) runs really slow on repro cases – that’s basically a bug in itself!! Bandwidth & storage is reasonably affordable & abundant these days, and IMO isn’t a “valid” reason here. -
The “lag time” between submission, to QA review, to Unity developer is massive and extremely high-variance. It’s even worse if you’re already-shipping your game & on an even-slightly older Unity version. And then you factor in when/where the fix will appear (ie the release management side) – you can be talking 3-6 months or more in many of the “typical” cases.
-
It’s extremely time-consuming to report a bug and to do so well. It’s then rage-inducing when you go to those great lengths (taking time out of your project) to write up a good-to-great bug report & then it sits there for weeks+ before even being looked at – and then receive mediocre response (ie in one recent case, ‘cannot reproduce’, despite including links to the GH issue in upstream Mono repo, the upstream commit that fixes the issue, and link to Unity Mono showing the fix isn’t there).
-
My experience is that relaying a bug/case # on the forum is the only way the process “works” well / gets relatively quick & technically very-sound responsiveness (ie by the dev who’s actually working on the codebase in question); in almost all other cases it’s like tossing it into a black hole. During 2019.3x first few patch releases, for instance, lots of macOS issues – wasn’t even worth reporting them; you couldn’t navigate a project for more than 10 minutes without a crash. I spent 45 minutes writing it up, uploaded a multi-GB project, it got to 100% then said “connection lost”/it failed out. Rage.
-
This is NOT globally applicable, but I’ve come across it a few times specifically in this forum/related to Addressables – asking for repro projects that either have already been submitted or that shouldn’t be needed. In some cases the submitted case was ‘closed’, maybe was fixed & is a regression, or was just overlooked – but for whatever reason is failing and the repro was sent in. Other times, I’ve seen acknowledgement of a bug/problem in forum posts with no follow-up and/or with a request for a repro on something that’s actually acknowledged as problematic; I get repro is challenging & time-consuming, but there is a point at which actively working with the tool/code yourself (read: dogfooding) does differ from “blindly” seeking out bugs. I get it, no one wants to “blindly” seek out bugs, but it also shouldn’t be a matter of “don’t move until a repro gets through the queue, QA verifies, and case opens on FogBugz” – surely devs are able/allowed to open cases on FB direct…
Finally – apologies in advance to the Addressables team, hah --you’re getting the brunt of it from me this week because it’s the area I’m working on right now. A few weeks back, some of the Graphics guys heard similar rants, though they are/were extremely helpful despite my occasional ranting related to frustration with some graphics/lighting pipeline & architectural/API decisions. I appreciate you guys, too! And apologies in advance if any of this comes off as personal – I know/feel as though those of you “in the trenches” generally care quite a bit; if anything I feel like there may be some leadership/direction challenges, but I’m not sure and am not going to claim to have all the arm-chair-QB answers. That said, all I can do is give examples and provide feedback/experiences!
Anyways: Ty for your patience/putting up with me; there’s nothing personal, and despite any frustrations voiced here, I know many/most of you at Unity sincerely care very much and I respect & appreciate that. 
