I can’t believe how complicated these Addressable Groups make the most simple task of organizing.
I joined a project that’s using this system, we can’t change it at this point. I am not the dev who set it up, he has left the company, and no remaining devs on the project know how this system works. If it were in my power, I’d have never allowed this to happen.
We have some prefabs in a folder Neutral/Cards/Common. I would like to create a new folder Neutral/Spells and move some prefabs out of Cards/Common and into Spells without changing how they are addressed. Okay, so I open my Addressable Groups, and add the group Spells under the same category (NeutralCardAssets) as Cards/Common.
They are correctly showing up under the Spells dropdown.
I cleared cache, and rebuilt the binary bundle. I ran the Analyze tool, they are in fact inside that bundle.
But when I get in the game, it fails to find any of them and defaults to our system of just writing the prefab name on a template instead of loading the prefab. Why do they not get found in game? What am I doing wrong? Why does this complicate the most basic task of organizing? The file names get used as the lookup id, which means every time I rename a file, I have to change any location where it’s being addressed in our designer website, when all I want to do is rename a prefab, I could write an intermediary to make that easier, but isn’t that at least partially what Addressable Assets are for? And then I can’t even move them easily, why?! Shouldn’t it use a reference instead of string file path? That’s way too rigid! Can anyone provide any sort of insight?
How is that bundle group building bundles? Packed together? Separately?
I have found assigning addressable folders like you are doing is too restrictive. Normally you would be able to “simplify” the addresses of single items which would set it to the current file name but would then be an unchanging string for each one. And would only change if you explicitly changed it in the addressable window. I dont think you can do that when you include a folder like that.
I also have some automation scripts that assigns everything to the correct bundle so I dont have to keep dragging new single prefabs into my groups. I just press a button and it fixes all my groups for me.
I believe they are packed together - where would I double check that?
Isn’t it a bit silly to lock something into an unchanging string that’s just their file name? What if I want to rename the prefab? Now I have to do database edits to match that change? That’s a bit not flexible - I’d rather an ID that’s mapped to the prefab so the prefab can change in anyway (location, name, contents, etc) and the ID always points to the same object.
Having to serialize any new prefab I make is also a pain, and shouldn’t be required, hence why we’re using the folder options, so if we want a new prefab we just have to add it to the folder rather than remember to serialize it in some addressable group and rebuild the whole group. We shouldn’t even need a button to “fix” groups, they should be incredibly hands off and “just work”. Atm this is complicating some of the most simple tasks in the project, which is kind of unacceptable.
There are options there for setting the internal bundle id to the GUID instead of the file path or file name. I am not sure how or if that changes how you access that addressable.
I think with understanding these settings and applying some generic project organizational standards, you can make it work for you. I wouldnt get in the habit of changing your prefab names so often. Thats just not great for a project in general.
Hi @aveakrause thanks for the feedback! This is especially useful for us as we are looking into improving usability.
I would second @Jribs 's response here. You will want to change the value of Internal Asset Naming Mode to something other than FullPath. This affects the identifier used to load assets from an AssetBundle.
Hi @Nickromancer yes modifying this setting will fail to load assets from existing local bundles. The bundles will not be aware of the new internal identifier. It is recommended to do a full Addressables build (not a content update build) whenever this setting is changed.