Search Issue Tracker
Fixed in 1.4.0
Votes
0
Found in [Package]
1.3.0
Issue ID
1191483
Regression
No
Windows build path BundleName does not handle large file paths
Steps to reproduce:
1. Open User-supplied project
2. Go to Addressables -> Build - > Build Default Script
Expected: the build finishes
Actual: the build fails
Reproduced in: 2018.4.11f1, 2019.2.10f1, 2019.3.0b8, 2020.1.0a19
Note: 2017.4.33f1 - no Addressables
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- [VFX] Custom HLSL with 'int' parameter, without the 'in/out/inout' access modifier is not supported
- [Windows] Lens Flare doesn't work in the Lens Flare Showroom URP Sample Scene
- Crash on ujob_execute_job while using OverlapBoxCommand when collisions are more than maxHits
- The validity of the multiple handles can behave differently based on the load/release operations order, when multiple Addressables.LoadAssetAsync and Addressables.Release are used to load and release the same Addressable Asset
- Dynamic text is rendered in the background when it is inside the <font> tag
Resolution Note (fix version 1.4.0):
Currently, we don't have control over the Windows MAX_PATH limitations. Addressables does already generate a unique hash for bundles that is appended to the name. This hash will change if the bundle's contents change. This functionality indeed would already allow a user to call the bundle by it's hash, if they desire. So, there seems to be little need for a long file structure.