Why do addressables need (another) name?

I'm not sure if I missed it being mentioned, but why do addressables need to have another string name (their "address") instead of simply using the asset's filename/path? It seems like AssetReference would use the GUID, and with the way it is now it seems very easy to rename assets and forget to update their "address" such that the two would then get out of sync.

 

When you use the filename/path, u have to update it when you rename the file or when you change it's location. The advantage with addresses is that once u figure out the "address" for an asset, u can rename the asset or move it wherever you want, but the "address" will still point to the asset.

 

Due to the way AssetReference implemented, no matter you change asset filename or addressable name (the primary key) it will just work fine.

The major benefit as @Kerber996 said, seems that you can name the asset to something human-friendly, and reference that in code, and won't worry about moving or renaming path in future.

However consider the trade-offs, it's seems a trouble design.
A) Naming filename is already a headache thing, now there's one more thing to do. Why not keep it consistent?
B) If you really worry about assets location changes in future, consider AssetReference or AssetLabelReference? After all if you change the "human-friendly" name in addressables window, your code won't get update anyway.
C) You may accidentally make duplicated name, which allowed by current system (bug?). This is impossible for path, path are always unique.
D) You make changes on filename, but forget to update the addressable name in window (out of sync as @Ziflin described).

It's a design issue hopeful unity internal developers can revisit it. Some options
- Remove the rename feature.
- Add a checkbox to always sync the path to addressable name. If you change the name, the checkbox is unchecked.
- [workaround] write a build script to verify the name and path, and log warning the differences ourselves.

 

@Kerber996 I had assumed that AssetReferences would store a GUID (stored in the .meta files) making renaming or moving the asset a non-issue. And as @Favo-Yang pointed out, now you have to worry about duplicating "address" names for things that, if it just used the asset name would also be a non-issue.

I'm with Favo that having a way to keep the address in sync automatically with the asset name would be nice and then allow users that feel the need to hardcode an address the option to do so would be nice. Basically if the "address" is left empty it could just default to the asset name.

 

+1 to have a toggleable automatic-sync feature

 

sounds like a handful of issues are being discussed here, so I'll try to hit on what seems to be the two main points.
1. AssetReferences do use the GUID under the hood. so you can change the address or path of an asset without breaking the reference.
2. you are welcome to use the path as your address. For many, the point of addressables is that you no longer have to load by path, so forcing people to use path would not be good. But there's no reason you can't. As to making it maintain path as address when you move the file, we'll probably make that into an Analyze rule at some point (if address looks like a path, but is not the path, make it the path).