I decided to remove GitHub source control from my project. When I open up the project, every single UEasset in my project is gone. Except, it’s only gone in engine, I still see all files in file explorer, but not the content browser. Additionally, my startup map fails to load.
I thought it wasn’t a big deal because I just did my final push. So I download my project files from my latest github archive which I knew for certainty works, and I opened the project from that fresh backup. But problem is not resolved, still the files are missing / not working in engine.
I looked up the problem, but none of the solutions I found worked.
Lots of people say it has to do with switching Unreal version (I’ve only ever installed 1 Unreal engine version so that’s impossible)
“Fix Up Redirectors for Folder” does absolutely nothing.
I tried deleting the saved folder in my project, again nothing.
At this point I am panicking, because it seems 100% of my project has just been perma deleted even despite being very careful of backing things up. But there is still hope because I see the ueasset folders in file explorer, but for some reason I can’t access them.
Hey there @Qeraga! Sorry to hear you’re having issues with the file registry! As you’d already ascertained, the common reasons (and fixes) for something like this have already been exhausted. I’m not entirely sure why breaking source control would affect the assets or their content registry, but when it comes to getting UASSETs to be re-recognized there’s a couple more options we can look to.
My first recommendation would be to back this project up (again aside from source control just to be safe), then delete the entire “Intermediate” folder from your project structure, then launch the project. This will force the asset registry to create a new cache and hopefully will scoop the old connections up.
then delete the entire “Intermediate” folder from your project structure
The archived version of my project files does not have an intermediate folder, but when I start up the project right after installation, it creates it while building. So I should have everything fresh in that department. But I did as you said anyway and deleted the intermediate folder then restarted the engine. But the problem remains.
Interesting! Let’s try an experiment. Is there anything in your ProjectFolder/Saved/Autosaves? If so, try replacing one of the assets that is saved then launch the project. Did that asset appear?
The only thing in my Autosaves folder is a PackageRestoreData.json that says
{
"RestoreEnabled": false,
"Packages": []
}
Can you be more specific about replacing assets? Do you want me to drag one of the ueasset files into the autosave folder? Or are you saying that if I have assets in my autosave folder (I don’t) that I should drag those into the project browser?
Here’s what I found after some research. I found the problem, but there may be no fast solution.
I was under the impression that when I push changes to github my files are stored in my cloud repository. This is NOT true. In reality, any file considered “large” is automatically intercepted and handled by the github lfs (Large File Storage) system. The uasset files I see are not real uasset files, they are pointers to the github lfs. Because blueprints are not well-optimized, all blueprints are considered “large files”.
LFS bandwidth is rate limited whenever you deal with large files, meaning you only get 10GB a month and then you will have to pay to upgrade (this is pretty underhanded business practice because it doesn’t warn you about the limit until you reach it) Since every blueprint is considered large, this makes git LFSa really expensive choice to use with Unreal, since even if you upgrade to a pro account LFS charges based on bandwidth used. However, there is no choice, because there used to be an option to disable LFS and have the files actually stored in the repo, but Github sneakily removed this option at some point. Which is how I ended up using it without realizing it.
Now here’s the particularly insidious part. It won’t even let one download the files if you’ve hit the bandwidth limit. In-fact, it crashes my github desktop when I simply try to clone my repo. The bandwidth limit applies to all interactions, not just uploading. So my files are currently being held hostage for ransom.
I’m not going to mark this thread as “solved” until I am able to successfully retrieve my files. Because there’s a possibility my problem is caused by my git lfs files being corrupted or missing somehow.
Ahhh that makes slightly more sense, I was wondering how standard source control could have this effect. I was checking around to see if it’s noted that when maxed the GitLFS files couldn’t be accessed, but couldn’t verify it. If the Github client crashes, does this still occur with the CLI version? (I doubt it will work if this is intentional but worth a shot).
It runs into the same error message when I try to clone my repo, but it doesn’t close the cmd window, whereas with GitHub Desktop App it straight up crashes after giving me the same error message.
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
Ahhh looks like you won’t be able to access them in the meantime. If something changes and you can get into them to verify, keep me appraised of the situation as it develops.