Is this going to happen? Is the addressables team working on proper documentation on this system?
I’m really having a hard time understanding it.
Don’t point me to this
https://docs.unity3d.com/Packages/com.unity.addressables@1.6/manual/index.html
as I think it’s just rough documentation and many things weren’t explained.
I’m also aware of the sample project on github and it’s not very helpful either.
Yeah, the docs are horrible. I learned the system through videos and this forum and trial-and-error.
Pretty much all packages have terrible documentation. Shallow, vague, lacking in examples. You can’t even search within them!
Could you maybe point out some good videos? I am also struggling with working into the system since about two weeks. And the problem with videos is that you can only know afterwards whether they where helpful or not as you can not easily skim them.
These are the 2 I started with.
Hey all, just wanted to throw my 2 cents in here. To be perfectly transparent we’re aware the docs are in a rough place. It’s my understanding that the entire package documentation story is something that’s getting worked on.
Some of you mentioned the sample repo and said that didn’t help you at all. Out of curiosity, what exactly didn’t you like about it? Would you like more in depth steps to guide you through the project? Is something about the current steps incomplete or unclear? I ask because this is something I can take more immediate action on.
Hi @davidla_unity , thanks for dropping by.
I would like to ask is that possible to have our own custom naming for the asset files that built?
Right now I’m only seeing 4 options under Bundle Naming.
Default file names which using “Append Hash to Filename”
Also, I’m noticing there’s always a defaultlocalgroup_unitybuiltinshaders.bundle that got build even though I didn’t include any shaders in addressable group. When I inspect it with the Asset Bundle Browser, I don’t see any assets listed in Source Asset Paths. So, what are these built-in shaders?
bump
@cadxplore currently no, there’s no official supported way to add a naming convention to that group schema. You might be able to create your own bundled asset group schema that has more options for Bundling Naming. You’ll have to create a corresponding build script to support this as well.
Just curious, what’s your use case for a new naming convention?
That is a special bundle we build that includes all of the Editors built in shaders. That will get built by default no matter what to solve some shader dependency issues.
@davidla_unity
Because every time after I built the addressable it always created at the same location as before so I’ll have to check the modified/created time in order to be able to tell which asset bundle is the newly created one.
For example, among these bundles, I can’t really tell which one is the most recent one until I sort the files by time
Ah, interesting. Yeah I get where you’re coming from. If we did add something where you could create your own bundle naming scheme it would probably be a while before it made it to a live package. But, I’ll definitely bring it up and see if I can get something going.
Looks like this thread morphed a bit, so I’ll reply to a couple of things…
We are always working on our docs, but the docs we have are the “proper documentation”. The package doc system has a lot of limitations (search??) that also frustrate us, but that’s just the system we’re in.
Sorry this isn’t helpful. We’re always open to suggestions for new samples.
It should be fairly straightforward to make a custom build script to handle this. In BuildScriptPackedMode.cs there’s
protected virtual string ConstructAssetBundleName(). Override that method and you can do whatever you want.
That being said, if your main concern is understanding which items are from an old build and which from a new, I’d personally recommend making your build path have a variable in it that evaluates to a timestamp. But there are a few reasons why someone would need to know which data is which, and that idea may not solve your specific need.
I’ve just made a post on this forum that I believe points out a gap in the documentation. I’ll excerpt the first paragraph here.
The post has more details of my specific situation.
I think the documentation would benefit from some general discussion and pattern recommendations around loading assets by path and marrying the async API with Unity’s typically synchronous workflow. I was looking at switching from Resources.Load to Addressables in my prototype code, but from what I’ve seen in the docs, it looks like I would need to implement a whole level loading system to cover up the async loading so that I can guarantee assets are ready and available in my synchronous gameplay code. That’s an unreasonable burden at this stage of my project, and is going to push me away from using Addressables at all.
I’m hoping that this is actually manageable in some way, but the documentation doesn’t make that clear.