I put together an instructional guide for our team on how to fix missing prefab references. I had to scour various forum responses to find the solution, so I thought it would be good to post the solution here!
For context, we’ve been experiencing occasional broken prefab and model references in our scenees. We believe it is caused by the unity yaml mergetool, but are not totally certain. Would you guys have suggestions on how to avoid this issue in the first place?
All the best,
Rich
That sounds quite likely and should be easy to prove: go back in your commit log and find a suspect merge, then compare before / after.
We chose not to use YAML Merge for other reasons (I forget exactly, it was back in 2018) and our team just solves the problem by avoiding simultaneous work, keeping our prefabs small, our scenes small, etc. If there is a conflict we get the two contributors together and agree who is going to redo their work on top of the other.
Here’s my generic all-knowledge-in-one-place “oh noes!” snippet… there’s a section on GUIDs / missing stuff:
Lost progress / project / work / stuff disappeared in Unity.
This article is to help you when you have lost significant progress or work in your Unity project.
It is designed to give you avenues of discovery and investigation.
It is NOT a guarantee of restoring your lost work. It is NOT a substitute for proper IT / Data security procedures.
To decide which parts are applicable to you, look for major bolded headings.
EVERYTHING IS GONE, YOU CANNOT OPEN THE PROJECT
Your project probably is still on your computer. Try a computer-wide search for some unique filenames that you know are in the project you think is gone.
To start your search, one common file to all Unity projects is named ProjectSettings.asset
Some things that might have happened:
As I said, it’s probably still all on your system to be found if you look in the right places.
A typical Unity project will have at a minimum the following folders:
ProjectSettings\
Packages\```
**EVERYTHING IS PRESENT BUT MY SCENE WINDOW IS BLANK**
Close Unity and make a full project backup RIGHT NOW. Do not do ANYTHING else until you back it up 100%.
Ideally copy that backup to another computer, or back it up to another external hard drive entirely. This is just basic data processing best practices during data recovery operations.
If you can see all the files and folders of your project, make sure you are opening the scene file you were working in.
Once you have opened the scene, look in the hierarchy window, select an object and move the mouse over the Scene window and press F to focus that object.
Additional notes:
- ALWAYS use proper industrial grade source control (see below)
- NEVER use Dropbox or any file sync mechanism in Unity.
- NEVER move files within your project, except by doing it within Unity
- ALWAYS be sure you are fully backed up before upgrading Unity
**SCRIPTS OR ASSETS ARE MISSING OR BLANK**
Some info about Missing script warnings, broken prefabs, GUIDs, renaming GUIDs, etc:
https://discussions.unity.com/t/836322/2
https://discussions.unity.com/t/815173/7
https://discussions.unity.com/t/815173/9
EVERYTHING in Unity is connected to the above GUID, which is stored ONLY in the metafile, and hence why the metafiles ALWAYS MUST be source-controlled.
**When Renaming**: It is super-easy to inadvertently change the GUID by renaming outside of Unity. Don't do that. Instead:
- close Visual Studio (important!)
- rename the file(s) in Unity
- in Unity do Assets -> Open C# Project to reopen Visual Studio
- now rename the actual classes, and MAKE SURE THE FILE NAMES DO NOT CHANGE!
If you are NOT using source control while you do this, renaming files is an EXTREMELY dangerous process. Use source control at all times so that you can trivially revert if you miss a critical step and damage your project.
**UNITY CRASHES / FREEZES WHEN I OPEN MY PROJECT**
You must isolate if there is something wrong with your Unity installation, something wrong with your project, or perhaps just a corrupted import or asset database.
First, ALWAYS back your project up. Then try deleting the ```Library/``` and ```Temp/``` folders that are within your project, the directories that are peers to the ```Assets``` and ```ProjectSettings``` folders.
If that doesn't work it is time to bisect. Make a new empty project and get Unity to open that. If you cannot then it is time to fix your Unity installation, either by fully reinstalling or verifying it with the hub.
Once you have an empty project open, begin copying over your project. Try the entire thing. If it crashes, try half of the project, then the other half, etc.
As always, if you're using Windows, another "first thing to try" is to simply reboot the system. This often fixes typical Windows issues related to locked files and locked directories.
**ISSUES RELATED TO UPGRADING PROJECTS (eg, changing to a higher Unity version)**
Upgrading to a later version of Unity is a one-way process. Any project that has been updated should NEVER be reverted to an earlier version of Unity because this is expressly not supported by Unity. Doing so exposes your project to internal inconsistencies and breakage that may actually be impossible to repair.
If you want to upgrade to a newer version of Unity, do not even consider it until you have placed your project fully under proper source control. This goes double or triple for non-LTS (Tech Stream) versions of Unity3D, which can be extremely unstable compared with LTS.
Once you have source-controlled your project then you may attempt a Unity upgrade. Immediately after any attempted upgrade you should try to view as much of your project as possible, with a mind to looking for broken animations or materials or any other scripting errors or runtime issues.
After an upgrade you should ALWAYS build to all targets you contemplate supporting: iOS and Android can be particularly finicky, and of course any third party libraries you use must also "play nice" with the new version of Unity. Since you didn't write the third party library, it is up to you to vet it against the new version to make sure it still works.
If there are issues in your testing after upgrading Unity, ABANDON the upgrade, revert your project in source control and be back where you were pre-upgrade with the earlier version of Unity.
Obviously the less you test after the upgrade the more chance you will have of an undiscovered critical issue.
This risk of upgrading is entirely on you and must be considered whenever you contemplate a Unity version upgrade.
Do not upgrade "just for fun" or you may become very unhappy.Im having similar issues, Ive been trying to get help on several forums since I’m loosing a lot of work every time I use git.
Are you guys creating your scenes from scene templates? I notice when I create a scene with a lot of prefabs, it creates a folder where the.unity scene is created. That folder seems to hold copies of my prefabs used in that scene.
After I git commit I notice this issue next time I try to build and the folder for that scene is missing. That seems to be the cause for me
Heres what my issue looks like, that uicontrols object should really only be one prefab, not sure why there are so many but I think I get one for each scene I create from a scene template
No, haven’t used those yet. I cannot even see the need: I use many additive scenes to avoid having anything significant that is shared among more than one scene!
Not only that I would NEVER EVER EVER EVER EVER!!!! put a singleton or manager in a scene… NEVER! It’s just not smart and it never was, and it never will be despite millions of examples and Unity trying to convince the world otherwise. It’s just BAD. See below.
WOW! Is that how scene presets / templates work?! That would completely defeat the typical use of a prefab in more than one scene. And if you are making a prefab of something used only in one scene, all you have done is undefined-ly split your hard work between two files, for no actual benefit. The only benefit to making a single-use prefab would be on a team so multiple people can update the prefabs used in a given large shared scene, but even then it is fraught with peril: changes made to the scene do NOT get committed to the prefab, YET they overwrite those data channels on the prefab, so someone could edit the prefab and see no changes in the scene.
Lots of red usually means you’re not source controlling everything you need to, usually the meta files.
You should enable visible file extensions in Windows. It has far too much value for developers.
Related snippets:
Additive scene loading is one possible solution:
https://discussions.unity.com/t/820920/2
https://discussions.unity.com/t/820920/4
https://discussions.unity.com/t/824447/2
A multi-scene loader thingy:
My typical Scene Loader:
https://gist.github.com/kurtdekker/862da3bc22ee13aff61a7606ece6fdd3
Other notes on additive scene loading:
https://discussions.unity.com/t/805654/2
Timing of scene loading:
https://discussions.unity.com/t/813922/2
Also, if something exists only in one scene, DO NOT MAKE A PREFAB out of it. It’s a waste of time and needlessly splits your work between two files, the prefab and the scene, leading to many possible errors and edge cases.
Two similar examples of checking if everything is ready to go:
https://discussions.unity.com/t/840487/10
https://discussions.unity.com/t/851480/4
PROPERLY CONFIGURING AND USING ENTERPRISE SOURCE CONTROL
I’m sorry you’ve had this issue. Please consider using proper industrial-grade enterprise-qualified source control in order to guard and protect your hard-earned work.
Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).
You can also push git repositories to other drives: thumb drives, USB drives, network drives, etc., effectively putting a complete copy of the repository there.
As far as configuring Unity to play nice with git, keep this in mind:
https://discussions.unity.com/t/736093/3
I usually make a separate repository for each game, but I have some repositories with a bunch of smaller test games.
Here is how I use git in one of my games, Jetpack Kurt:
https://discussions.unity.com/t/807568/3
Using fine-grained source control as you work to refine your engineering:
https://discussions.unity.com/t/826718/2
Share/Sharing source code between projects:
https://discussions.unity.com/t/719810/2
Setting up an appropriate .gitignore file for Unity3D:
https://discussions.unity.com/t/834885/5
Generally setting Unity up (includes above .gitignore concepts):
https://thoughtbot.com/blog/how-to-git-with-unity
It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place. Digital storage is so unbelievably cheap today that you can buy gigabytes of flash drive storage for about the price of a cup of coffee. It’s simply ridiculous not to back up.
If you plan on joining the software industry, you will be required and expected to know how to use source control.
“Use source control or you will be really sad sooner or later.” - StarManta on the Unity3D forum boards
Simple Singleton (UnitySingleton):
Some super-simple Singleton examples to take and modify:
Simple Unity3D Singleton (no predefined data):
https://gist.github.com/kurtdekker/775bb97614047072f7004d6fb9ccce30
Unity3D Singleton with a Prefab (or a ScriptableObject) used for predefined data:
https://gist.github.com/kurtdekker/2f07be6f6a844cf82110fc42a774a625
These are pure-code solutions, DO NOT put anything into any scene, just access it via .Instance!
The above solutions can be modified to additively load a scene instead, BUT scenes do not load until end of frame, which means your static factory cannot return the instance that will be in the to-be-loaded scene. This is a minor limitation that is simple to work around.
If it is a GameManager, when the game is over, make a function in that singleton that Destroys itself so the next time you access it you get a fresh one, something like:
public void DestroyThyself()
{
Destroy(gameObject);
Instance = null; // because destroy doesn't happen until end of frame
}
There are also lots of Youtube tutorials on the concepts involved in making a suitable GameManager, which obviously depends a lot on what your game might need.
OR just make a custom ScriptableObject that has the shared fields you want for the duration of many scenes, and drag references to that one ScriptableObject instance into everything that needs it. It scales up to a certain point.
If you really insist on a barebones C# singleton, here’s a highlander (there can only be one):
https://gist.github.com/kurtdekker/b860fe6734583f8dc70eec475b1e7163
And finally there’s always just a simple “static locator” pattern you can use on MonoBehaviour-derived classes, just to give global access to them during their lifecycle.
WARNING: this does NOT control their uniqueness.
WARNING: this does NOT control their lifecycle.
public static MyClass Instance { get; private set; }
void OnEnable()
{
Instance = this;
}
void OnDisable()
{
Instance = null; // keep everybody honest when we're not around
}
Anyone can get at it via MyClass.Instance., but only while it exists.
So I’m just learning so I could be misunderstanding what your saying, are you saying a singleton is bad because of potential stale data?
I need to think about what I do, I have a static class, with static fields, but this class is not attached to any gameobject in a scene. Its methods are called by its own reference in other mono objects for example. I use it to store game progress data that will eventually be saved. Actually my class that handles saves and loads is the same design.
Am I wrong in assuming as long as I dont require real time to the second state, these classes should be ok?. Also dont these classes loose all data once the game shuts down?
Singletons are fine. They have benefits and they have detriments.
They have rabid people who rail against them and supporters like me who recognize them as a fantastic tool for certain cases.
In all cases, in the Unity ecosystem, which is NOT pure code, your code MUST behave well with scenes.
Managing the lifecycle of your objects is a critical part of programming. It isn’t an optional part and it might be one of the hardest to grasp because of the possible ways of handling it…
Scenes, which can be anything, and can get loaded / unloaded at any time, are what actually causes your code to run.
Blindly sticking managers in a special scene(s) that must be present is generally a disaster beyond having a pure single scene game, even if you see ten thousand youtube tutorials advocating for it.
Hey so I’ve looked and looked but I cannot find out how to fix this problem. I’ve tried what I know and what I looked up but I couldn’t find anything that works and for me the problem is saying that a prefab does not exist on a model. Sorry if this image is too small but this is what keeps popping up.
