My team and another team at a university had to struggle against this “filename is too long” problem when cooking and to avoid it, we would have to completely restructure the number of subdirectories in our projects, shorten the names of our files (which took away some of their clarity/ease of identification), and even transplant entire project folders to places closer to the hard drive’s root folder just to make things fit within the 180 character path limit.
It would be extremely helpful if a fix for this could be put on the to-do list by the Epic team (if it isn’t already?), though I understand that it’s a relatively low “fix” on the totem pole. While it can simply be an annoyance, it also prevents people from organizing their projects’ directory structures as they would prefer, so I feel it merits some level of attention somewhere down the line.
I agree, this limitation is super annoying, especially given how prone to failure folder re structuring can be in unreal. This is one of the few areas where unreal feels very outdated compared to the way other engines function.
I agree, this limitation is super annoying, especially given how prone to failure folder re structuring can be in unreal. This is one of the few areas where unreal feels very outdated compared to the way other engines function.
At present we will not be able to fulfill this request. The primary reason for the character limit is because certain OS’s have a max filename character limit. Our own limitation is set to ensure that any assets created within the editor do not exceed that hard limit set by the operating system. As one of our goals is to remain as OS agnostic as possible, it is not possible for us to increase the character limit at this time.
Perhaps there should be some tools in place that warn you of file-length issues during folder/file creation?
One of the big issues is that re-organizing or re naming folders and files is prone to causing a lot of problems in the editor so you end up being stuck between a rock and a hard place. If the path length limitation is here to stay (for good reason) then it seems like we need to look at ways of making file-structure changes extremely bulletproof, and at the moment they usually break several things.
I’ve entered a feature request, UE-30092, to add a tooltip to each asset indicating it’s current filepath character length out of the maximum allotted to help developers quickly find areas in which their folder structure may need to be re-evaluated before it becomes problematic.
I manage my dependencies with the package manager conan.io.
A normal path in conan looks like: /Users/macbook/.conan/data/unrealengine/4.18.1/epic/stable/package/3295083bcfe18a75e692460b53e9ab7209b94277/Engine/…
On Windows I can use “short_paths=True” but not on linux/mac (not supported and not needed for most applications). But UE has this stupid limitation for no reason on this platform.
So i will search for a solution on conan.io side → activate short_paths for linux/mac.
Or change the limitation in Unreal → is there a variable for this limit? (i´m building from source)
The problem is that the max path is enforced even for intermediate paths during cooking, even if the “final” filename would fit in the limitation (which is no longer an issue on modern Windows, for example). During cooking Unreal stages the files in the Saved/Cooked/WindowsNoEditor folder, putting your assets 28 extra characters closer to the limit. There should be a setting to detect whether the OS supports longer paths and only check the length relative to the assets content folder in such cases, not the whole thing.
Agreed. Also consider that this path length limitation is largely irrelevant for the vast majority of projects that are using .pak files for their content.
Thats a load of bull. The file name limit is because you are not using CreateFile()… Its not the OS, its epic using the wrong api.
If you guys dont want to fix it thats fine. But stop blaming the OS. Lots of programs work fine within the 16K character limit imposed by the Windows operating system.