Recently i have encountered this problem.
Lets say i have this blueprint: Right_Fireball_Spawner_BP.
I then duplicate it and the system saves it as:Right_Fireball_Spawner_BP2.
Now if i try to reduce its character length to: Fireball_Spawner_BP it gives me the error “the path to the asset is too long for cooking etc…”
How is this possible?I just made the BP’s name 7 characters shorter.
How can the system save a name that is 1 character longer than the original and it does not let me reduce its length by 7??
Thank you.
Hi ,
What is the filepath to your asset? When calculating the name of an object, the editor does take into account filepath names, so if this is 165 characters or longer it will deny you the ability to name your asset. This is expected behavior.
You’re probably running into the same issue I was where Epic still doesn’t understand that this is a bug -
The workaround is to move your projects in the root of C
Thank you vallamost,
I just read your post and is indeed the same issue.
Why they don’t understand it is bug?
, why it is expected behavior to not let you rename the file to something smaller than the file that the system has already accepted as smaller than 165 characters? It is illogical.Have you read carefully my above example and concluded that this is normal behavior ?
No ,they were both in the same subfolder
All this started to happening as i started to add more and more folders.It is like it adds up every folder you create and after a while it gives you this error message.Another problem i am facing since day one is that i try to delete those two folders that are created when i import a json file from texture packer(for paper2d) named FRAMES and Textures and every time i re load my game they just magically reappear !
I have about a dozen of those scattered around in my project from every import i made and no matter what i do to delete them they are always there!
There is something seriously wrong in the file system in unreal i am afraid.
Hi ,
It would depend on if this file was in the same file location as the previous Right_Fireball_BP. For instance, if you have them saved in the same filepath, I can certainly see that this may be a bug, however if they were already close to the filename limit, and you moved the fireball_BP to another folder that may have more characters in the filepath name, it is possible that this would cause the error despite having a shorter filename. How long is the filepath name of the file that is throwing up the error? Further, does this happen in a clean project with no additional content or is it limited to a single project?
Hi ,
Ok for clarification this seems to be a two fold problem:
-
The more folders you add to a project folder increases the total number of characters that are being added to the original filepath, even when they are not immediately in the filepath being looked at (for instance, you have an assets folder inside blueprints, but it is affecting the word count of anything in the blueprints folder).
-
When importing Json files, you are unable to delete FRAMES and textures files. With this one, have you attempted to hard delete them from outside of the editor?
I am going to attempt to reproduce the filepath names issue again on my end to see if adding additional file folders with extended names affects the name limit of files not actually present in those folders.
Hi ,
Thank you for the confirmation, I will try to repro this as soon as possible. For the second question, if you go into your project folder at \Unreal Projects\PROJECTNAME\Content\ and find the specific folder you placed the json texture into, for example, if you placed it in your materials folder it would be in \Unreal Projects\PROJECTNAME\Content\Materials, you should be able to find the files in the folder and delete them directly from the filepath. If you are able to do so, they should not continue to appear in the editor. Please let me know if this works for you.
Dear ,
I believe you are in the right path in fixing this once and for all!
No 1 is exactly what is happening. But on the same time it makes no sense something like this.
lets say the next example is 165 characters long.
…Blueprints/enemy_blueprint/Bad_guy.If i add one more character i get an error.This is logical.
but the next one makes no sense and this is exactly what is happening.
…Blueprints/Bad_guy1 ERROR.
So as you said it stores all the folders and subfolders you create and then it maxes out the character count no matter in what folder you are in.
Could you please explain what do you mean to hard delete outside the editor and how can i do something like that?
Hi ,
As long as you do not delete the Contents folder you should be ok to delete any files or folders within this folder you do not need. As long as you do not delete things from a folder titled “Engine” you should be fine. Further, make sure whatever assets you delete are not being used in your project, this can cause errors and potentially corrupt your file.
Thank you for your clarification .Although both these folders are empty in the editor they have still have .uasset files inside the actual ProjectsPROJECTNAMEContent.Is it safe for me to delete them?
Hi ,
I attempted to reproduce this and unfortunately thus far I have not been able to on my end. Do you have a project that is producing this bug that you would be comfortable sharing? I would be happy to take a look and see what may be occurring that way.
About 10 minutes ago i decided that i had enough and i moved my project to c:/udk4 and for the time being it stopped giving me all these error messages.Although my project has a lot of my assets since you are working for unreal i wouldn’t mind sending you the project through a p.m since i cannot post it publicly for obvious reasons.
If you are interested please let me know.
Hi ,
I emailed you about this post and could not reproduce the bug on my end. When copying files it did name them with additional characters, however when I pressed enter I received the same file name size warning that I received with the other files. I am marking this as answered for tracking purposes. Thank you!