I have been working through the Battle Tank section, and everything was going just fine up until now. However, something strange happened when I was starting to work on “Programmatic Sideways Friction”. First, in the Tank blueprint the track components’ icons turned pink and were duplicated. When I tried to delete them, nothing happen.
I fiddled around with it for a little bit before deciding to close everything and load up my latest working commit. Now, whenever I try to open the project I get an error stating “corrupt data found please verify your installation”. I tried verifying the engine installation and even reinstalled Unreal, but I still cannot open the project.
Is there any way to recover my project? I would reeeaaaally like to not have to start over.
I can do you one better: the whole thing is in source control:
Master does have an error: on line 130 in the Private/AimingComponent.cpp file the call to Super::TickComponent is wrong. If you fix that and then try to load the project, it fails with the above error. At least, it does for me. It is always at 91%.
It is worth noting I have tried this on both 4.23 and 4.24, neither work. I am not sure if this is a problem with my project or a problem with my installations. I tried uninstalling and reinstalling the engines, but that also did not help.
Yes. When it told me the installation might be corrupt, I went to reinstall Unreal, noticed there was an updated version, and then installed that instead.
Well having opened the project and waited several minutes for “Discovering Asset Data”. It seems likely that the entire contents of “Content” is corrupted.
I actually have to kill the process in Task Manager because closing the project doesn’t seem to terminate it
Hmmm, okay. Well, I should be able to go back a commit or two before the corruption happened, right? Unreal must do some data caching or something for the corruption to occur without me noticing before I committed the broken files. It is strange.
On my end, even if I try to go back to older commits I get the same error. I assume that might also have something to do with Unreal caching the corrupt versions of the files so when I try to open the project it does not see the working versions of them. Do you know anything about that?
So, I went back a few commits to test each one. Every time I cleared out all of the build files as well as the Visual Studio files to have a clean slate to work with. However, once the project was built and I tried to load it in Unreal, I get the same error message. The commit I am on right now is the one from the day before the corruption became apparent. I can keep going back, but I am really thinking my corrupt project also corrupted something in Unreal that persists between installations.
I am not sure if that makes sense or not (I do not know the inner-workings of Unreal well at all), but if it does the only other thing I can think to do is reinstall Unreal again except start with trying to open the commit I am on (three commits behind master) and work forward to see where the broken commit is (hopefully the broken commit comes after the one I am on).
If it is the case that my broken project broke Unreal, having to reinstall Unreal each time I open a broken project seems a little overkill. I am not sure if there is a faster way to fix Unreal. There is the “verify” option in the Epic Launcher, but when I used that it seemed to take just as long as a full reinstall, so at that point a full reinstall seems like the better route to get a fresh slate.
It’s nothing to do with the engine. Your project compiled successfully and I opened it. The problem is your .uasset files. It looks like you have setup your .gitattributes incorrectly so they are all broken in git.
Did you get the project to open in Unreal? I can get it open in Visual Studio and build it successfully, but Unreal just crashes whenever I try to open it, even after I build in Visual Studio.
The .gitattributes thing is probably that Git LFS thing. I tried using it, but then I pretty much immediately hit the limits. I went through the steps to undo it, and everything seemed fine. I thought it rewrote the history so the files in GitHub were reverted back to their normal state. When they were in Git LFS they were all just text pointing to the files in Git LFS, but now they show as binary. I suppose the transition between the two could have messed something up. That was back reeeeaaal early in the project, though, so I am not sure why the problem would wait until now to present itself.
Yes by deleting the problematic .uasset files which is presumingly everything in the level as that’s the default start up. I guess you could comment out the line in Config/DefaultEngine.ini that sets that.
Well if you never used git to reset to a previous commit until now then that would explain why.
P.S. Fun fact. On first loading your project I immediately switched to helping someone else whilst waiting for it to load. It never did and I forgot about it… It had racked up a 3GB log file when I realised it never opened.
Yes by deleting the problematic .uasset files which is presumingly everything in the level as that’s the default start up. I guess you could comment out the line in Config/DefaultEngine.ini that sets that.
Alright. So, I can go through my content and see if anything is salvageable. Hopefully, something is. If not, I can go back through old videos and rewire things.
Well if you never used git to reset to a previous commit until now then that would explain why.
Okay, I am just trying to get a grasp on what led to this corruption, so I do not make the same mistake. It seems the files have been corrupt for a while, so going back to previous commits will not work. However, the editor did not start acting up about them until Saturday (which is one of the things I am trying to understand), so I basically have been doing all my work in a broken project for however long. Does that sound anywhere close to what might have happened?
P.S. Fun fact. On first loading your project I immediately switched to helping someone else whilst waiting for it to load. It never did and I forgot about it… It had racked up a 3GB log file when I realised it never opened.
While trying to figure out why reverting commits was not working, I did some Googling to see where Unreal caches things (still thinking the corruption was recent and Unreal was holding onto that instead of seeing my “working” files). I found the DerivedDataCaches, which Epic said were safe to delete. Upon deleting them, it took probably around an hour for my computer to regenerate whatever was in those files and try to open my project (which of course crashed again because that was not the problem).
I am glad it generated some logs for you so you could track down the problem. I tried looking through the logs I found, but they were all talking about how the engine failed to load libraries and things like that. There was nothing that told me what was wrong in my project. Are there multiple log locations to check for this kind of thing? I would like to get a better understanding of how to troubleshoot these kinds of crashes, so I do not have to take up someone else’s time figuring them out.
By the way, thank you so much for helping me so far (both on this and on the other posts). It is awesome to have such an active support community. I hope as I progress I can start giving back to the community and help others, too.
I guess I wasn’t clear. I’m saying that all of this time the .uasset files you were committing to git were broken due to the .gitattributes. So while your local files were in good condition the .uasset files you were committing were not.
Making commits doesn’t effect your local files, so when you reset back to a previous commit you were throwing away your good .uasset files for the ones in git that were bad.
There are two locations, Saved/Logs and Saved/Crashes. The first is what I used to see that the .uasset files were broken.
[2019.12.16-18.41.21:719][ 0]LogFileManager: Error: Requested read of 1107296256 bytes when 167436 bytes remain (file=E:/Projects/Repos/Unreal/dawsonBT/Content/Tank/Tank_Blueprint.uasset, size=168904)
[2019.12.16-18.41.34:430][ 0]LogFileManager: Error: Requested read of 1699902563 bytes when 169 bytes remain (file=E:/Projects/Repos/Unreal/dawsonBT/Content/Landscape.uasset, size=1200)
[2019.12.16-18.41.34:444][ 0]LogFileManager: Error: Requested read of 4 bytes when 0 bytes remain (file=E:/Projects/Repos/Unreal/dawsonBT/Content/Tank/Tank_Blueprint.uasset, size=168904)
Ahhhh, okay. So they were just broken in the remote repository, not locally. Sorry it took a bit to understand that. This is the first time I have run into the issue that the remote repository is broken while the local one is not; it is usually other way around. This is also the first time I have fiddled with Git LFS and .gitattributes, obviously, so I probably should have guessed something might be off in the remote.
Okay, so that leads to an interesting overall situation. Something in my editor went weird (the pink icons/duplicate tracks I spoke of in the original post), which is a separate issue from the corruption one. I tried to “solve” the original issue by resetting my state to what I thought was a good commit, but since I had everything broken in GitHub I simply made things worse.
I probably will not try to track down why the original issue occurred given reproduction of it is next to impossible now that my files are messed up.
I believe the original issue is due to the types of the component being changed.
Only solution that I know of to get around that is to create an entirely new blueprint. Duplicating will result in duplicating the bugged component.
Also just in case you forget, delete the .gitattributes if you aren’t using LFS.
Hmmm, that is interesting. I do not quite remember what I was fiddling with before things went sideways, but I will try to remember that if something happens again. Or better yet, I will use Git properly and not break all my .uassets, so I can roll back if need be.
Also just in case you forget, delete the .gitattributes if you aren’t using LFS.
First thing I did once you mentioned it was breaking things. I thought I ran all the commands to basically disable LFS, so I did not realize it was doing anything.
Thanks again for all the help, especially the log locations. I was looking at the logs in AppData; I did not even realize there were logs in Saved (admittedly I have never even looked in that directory before now). I feel like armed with that information I can figure these things out on my own, or at least give a better description of the symptoms rather than “it crashes with this error message”.
Since there were kind of two problems going on and you answered both of them, I am not sure which thing to mark as the solution. Is there a protocol for that sort of thing?
I marked the one resolving the corruption issue correct and then “liked” the other one, so hopefully that gives enough credit to both. Back to recovering/redoing my assets.
