I did some large-scale cleanup and might have deleted a script that is still referenced somewhere I can’t find. At runtime I’m getting hundreds of these warnings: “The referenced script (Unknown) on this Behaviour is missing!”
They contain NO IDENTIFYING INFORMATION. No stack trace. Clicking on them does not take me to the behavior in question, possibly because it has already been destroyed.
I’ve tried searching all my scenes and prefabs using this script:
using System.Collections;
using System.Reflection;
using System.Linq;
using UnityEditor;
using UnityEditor.SceneManagement;
using UnityEngine;
/// <summary>
/// A helper editor script for finding missing references to objects.
/// </summary>
public class MissingReferencesFinder : MonoBehaviour
{
private const string MENU_ROOT = "Tools/Missing References/";
/// <summary>
/// Finds all missing references to objects in the currently loaded scene.
/// </summary>
[MenuItem(MENU_ROOT + "Search in scene", false, 50)]
public static void FindMissingReferencesInCurrentScene()
{
show original
But it either can’t find missing Components, or the problem isn’t as obvious as I thought.
None of the suggestions in this StackOverflow post have helped me find the cause:https://stackoverflow.com/questions/54969972/unity-the-referenced-script-unknown-on-this-behaviour-is-missing
SUGGESTION to Unity: please improve this warning by at least including the name of the Behaviour in question, or better yet its full path in the scene. Even better: make including the name of the thing that is broken a Unity platform standard for all warning messages. Unity has too many generic warnings that are incredibly difficult to track down because they lack any identifying data.
4 Likes
I’m sorry you’ve had this issue. Please consider using source control in order to guard and protect your hard-earned work.
Personally I use git because it is free and there are tons of tutorials out there to help you set it up.
As far as configuring Unity to play nice with git, keep this in mind:
There really isn’t any fix because git works perfectly with Unity when configured properly.
Best practices involve saving your work and closing Unity before using git.
But if you understand how Unity does and does not flush changes to disk (or at least ALWAYS do a save-project), you can get away with leaving Unity open.
The only thing linking EVERYTHING together in Unity is the GUID assigned to a script or asset. Name is irrelevant. Only the GUID connects it. This GUID is in the meta file.
I…
Here’s how I use git in one of my games, Jetpack Kurt:
Yeah, what Praetor said is it… Debug.Log is your friend, and also since this is animation related, you can open up the Animator window when you expect the animations to go, and actually visually see where the state machine is, see which state it thinks it is in. You can combine this with Debug.Log() output at the locations where you set the animations to be what you think they should be, and that should lead you to some intel.
I highly recommend setting up git source control. It really plays ni…
Using fine-grained source control as you work to refine your engineering:
This is a reasonable initial approach. The problem is you have listed the parts, but you haven’t really listed how they interact, and even if you did, it’s still sorta up to you how to organize it.
Only YOU will know how to organize it, and the only way you can tell is to do the work.
I recommend this: first, develop ALWAYS with source control (such as git), and every time you get even the slightest thing working, commit those changes with good commit messages.
Then move to the next thing, c…
Share/Sharing source code between projects:
I have found that bundling your own code into DLLs only serves to slow down your workflow. I base this on several years of experience dealing with other teams well-intentioned packaging mishaps. With games, it is almost always useful to reach into library code, make a temporary tweak to isolate a problem, and then revert it. With DLLs this is impossible, making workflow harder and more brittle.
I prefer to share source code at the C# level. That way I can reach into libraries trivially and inje…
Setting up the right .gitignore file:
Not sure what you are "auto generating" with... I usually start from one of my other projects, or a gitignore example online, and reason about all the parts inside it, and start from there. Like any other configuration change, after you make it, pay attention for a while to make sure it is what you want.
You can always clone the repo somewhere else to verify that the correct files are being tracked. Doing so to a brand-new computer is the acid test to make sure you can still bui…
Some specific info about Missing script warnings, GUIDs, renaming GUIDs, etc:
If you delete a script and recreate it, Unity will produce a new .meta file, with a randomly chosen guid.
The guid inside that metafile is what “connects” the script to the prefabs / scenes / assets.
Here’s an example, with the guid fortuitously underlined with a red squiggle:
[7024801--832060--Screen Shot 2021-04-10 at 9.13.40 AM.png]
What you need to do is look in git history and find out what the original guid was for that file (the one you deleted when you deleted the script), then modif…
The linkage between a scriptable object instance and its script is twofold. For one it is the GUID contained in the .meta file for the script, but the other requirement is the class and file naming requirement as you list above.
For instance, this is my StartingShips scriptable object: (StartingShips.asset, NOT the meta file)
%YAML 1.1
%TAG !u! tag:unity3d.com,2011:
--- !u!114 &11400000
MonoBehaviour:
m_ObjectHideFlags: 0
m_PrefabParentObject: {fileID: 0}
m_PrefabInternal: {fileID: 0}
…
If you rename the class from within visual studio, the currently infuriating state of that function (for actually the past decade, going back to Monobehavior) is that it renames the .cs file but does NOT rename the .cs.meta file.
Therefore, Unity throws out your original GUID, which you MAY have already used, and creates a new one when it creates the new .meta file. It is the single most Fisher-Price non-professional feature there is in Unity. It is probably responsible for more bugs and lost …
I run a Subversion server on AWS and agree that developing without source control is a super dumb idea. I wrote a how-to guide about it in 2014 that is very out of date, but I have no regrets and still prefer SVN to GIT.
It’s a good thing I had it, because the way I fixed this was:
restoring all recently deleted components one at a time until the error stopped
copying the guid from that component’s .meta file.
doing a raw text search for the guid in all *.prefab files (also *.scene and *.asset)
This requires Project Settings > Editor > Asset Serialization > Mode = Force Text.
But my suggestion to Unity stands and I strongly feel there should be a better way to find the source of any warning Unity logs.
2 Likes