When I delete “GameObject B” (or just remove the component “ScriptB”) and then Undo its deletion, a NullReferenceException is thrown inside the Update method, because the variable “reference” is null; even though the inspector still shows the proper link.
It’s important to note that this only occurs with references to MonoBehaviours. At least, I was not able to reproduce with other type of Components.
This is a simple representation of the bug, which is preventing me from working on more complex scenarios/setups.
Does anyone have any workaround or solution to this issue?
PD: Attached is a simple .unitypackage with the previous setup.
I was just about to submit a bug report for this. I am seeing this issue in 2019.1.12f1.
I guess it is not fixed yet? Can we have a link to the issue on the issue tracker? A status update? I don’t want to waste QA’s time with a duplicate report.
Oof. Yes I can imagine internally it might be very a hard problem to solve. I guess there is some sort of desync between the serialised data and scene representation of that data? It is a real shame. Is there any more details on the Undo system improvements?
In the spirit of moving on and getting stuff done - how do you suggest we go about writing editor tools that reference other things to make sure we are ctrl+z safe?
My use case is pretty simple. I have a BezierCurveManager object, which has a list of Point’s, and between the points it generates bezier LineSegments. I have other scripts that can reference the Points or Segments (Gameobject+Behaviours’s in the scene) and do something with that. For example, I could write a tool that takes a list of LineSegments, and lofts a rope mesh along the LineSegments. A RopeMeshGenerator. It observes the LineSegments, and whatever other dependancies go into forming that Rope Mesh. If it detects some change, it recreates its mesh. It is a very straight forward setup. But if I delete a line segment or a point, and press ctrl+z, my ‘RopeMeshGenerator’ is broken now. The LineSegment it was referencing is null because of this bug.
So what is the ‘correct’ way to do this?
The way I am doing is by using ExecuteAlways, and having the RopeMeshGenerator ask the LineSegments if they are ‘dirty’ (Custom code), and if so, the RopeMeshGenerator recreates the mesh.
Using SerialisableObject seems to be the way forward, but I only get a SO for custom editors, and I won’t have the RopeMeshGenerator’s Editor open at the time - because I have the LineSegment selected as I delete it. The RopeMeshGenerator’s Editor is not ‘persistant’. So I cant run this kind of logic in the editor script.
Im not entirely sure how your system works but if you have a system that is referencing the data and using it to generate some other data then you could try doing it all inside of a single undo operation.
var group = Undo.GetCurrentGroup();
Undo.RecordObject(curve, "Change curve");
// Change the curve properties
Undo.RecordObject(objectThatReferencesTheCurve, "Generate mesh from curve");
// Generate a new mesh
Undo.CollapseUndoOperations(group);
If you do this and the generated data is also serializable then you wont need to do anything when an Undo occurs as everything will be reverted.
You just need to know what objects are referencing the curve. You could add a list of subscribers to the curve who get notifed of changes or try using the AssetDatabase to find out what assets are referencing it.
I see this bug was produced using Unity 5 in the issue tracker, and the verdict was ‘Won’t Fix’. I am still getting it in Unity 2018. Has this bug been fixed in any Unity version?
I have an editor script that deletes a GameObject A in the scene (using Undo.DestroyObjectImmediate) which has a component referenced by another component on GameObject B in the scene.
Upon performing Undo, the GameObject B appears to have a proper reference to GameObject A, but the reference is actually null. Even manually re-dragging GameObject A into GameObject B’s reference it continues to be null.
This seems to be an incredibly ugly bug since it not only renders Undo useless for restoring references, but also puts in ghostly references in the inspector that look fine but are actually null. At a minimum, I would expect the editor to reflect the actual state of the variable, even if restoring references are not possible.
I have very similar problem here in Unity 2019.3.13f1.
I have 3 levels of nested ScriptableObjects (referenced further in the text as SO) that are stored as a part of an Asset file. Nesting is implemented via List and I work with them in my Editor scripts using Array functions of SerializedObject.
When a root SO is being deleted the following is done:
Undo.RegisterCompleteObjectUndo() is called for the root (asset) object (that’s SO too btw).
The script goes through all nesting levels of SOs and calls AssetDatabase.RemoveObjectFromAsset() for each of them.
The root SO is deleted using Undo.DestroyImmediate(). This deletes the SO from Asset file as well.
The step 2 is required because step 3 doesn’t delete nested SOs from Asset file leaving them there forever as garbage.
When Undo operation is performed, everything looks fine except that Unity loses references to the nested SOs: they appear in the Inspector and work “fine” until the next Asset reload where they become null.
One could suggest replacing AssetDatabase.RemoveObjectFromAsset() with Undo.DestroyImmediate() in the step 2. This doesn’t really help. The problem event gets worse: after Undo is done all the references become null not even in Asset file but in memory too.
I tried many different combinations of Undo.() and Destroy() calls but nothing solves the issue: references keep being lost. In Asset file all references to the nested SOs are saved as “{fileID: 0}” instead of smth. like “{fileID: 6092419105996449486}”. That’s happening because Undo doesn’t restore deleted SO as a part of Asset file.
So I came up with the following temporary solution until Unity guys fix the problem on their side. Here is the recipe:
Register Undo.undoRedoPerformed callback and use AssetDatabase.AddObjectToAsset() for each of them.
So when an Undo/Redo is performed, your callback is called and the restored SOs are added to the Asset again. This magically restores references.
Here is the code example:
private void OnEnable()
{
Undo.undoRedoPerformed += UndoRedoCallback;
}
private void OnDisable()
{
Undo.undoRedoPerformed -= UndoRedoCallback;
}
private void UndoRedoCallback()
{
// your checks here
if (!AssetDatabase.Contains(target)) return;
target.items.ForEach(item => {
if (!AssetDatabase.Contains(item))
{
AssetDatabase.AddObjectToAsset(item, target);
}
});
}
I found a hack/workaround that works well (at least in my case), so I thought I might as well share since this is the only post I could find on the issue.
Since the reference is valid in the inspector that means the serialized data must still be valid. What we can do is look up the object id in the serialized data, find the object with that id in the scene, and then manually set the value of the missing reference:
if (scriptToFix.myBrokenReference == null) {
// Create a serialized object for the component that has the broken reference
SerializedObject serializedObject = new SerializedObject(scriptToFix);
// Get the serialized value of the broken reference as a serialized property
SerializedProperty serializedProperty = serializedObject.FindProperty("myBrokenReference");
// Find the game object by the serialized instance id
GameObject actualReference = EditorUtility.InstanceIDToObject(serializedProperty.objectReferenceInstanceIDValue) as GameObject;
// Assign the broken reference the object we just found
scriptToFix.myBrokenReference = actualReference;
}
This is just the simplified pseudocode, you would need to tailor the code it to fit your case and add validations etc.
You would call this code in some sort of validation method when something in the scene changed for example.
I had a related issue that I was able to solve with info in this thread. Posting my solution here in the hope it helps someone else.
In my case I had a list of game objects referencing each other in a loop (used for mesh generation). I wanted to handle the case that the user selects one of the game objects and presses the delete key, the loop should be maintained by joining the two neighbours. When the user presses Undo, the deleted object should be restored and re-inserted into the loop (List<>) of references.
The issue occurred when someone selected multiple nodes, pressed delete, then undo, redo, then undo again. (There were other ways to reproduce but this was a common one). When trying to get back to the original state, some nodes would lose their to the next node in the loop, breaking mesh generation.
The fix ended up being to switch Undo.RecordObject for Undo.RegisterCompleteObjectUndo inside JoinNeighbours
[ExecuteAlways]
public class FloorNodeScript : MonoBehaviour { ...
private void OnDestroy()
{
if (Application.isEditor)
{
JoinNeighbours();
}
}
private FloorNodeScript JoinNeighbours()
{
var prevNode = GetPreviousNode();
if (prevNode != null)
{
Undo.RegisterCompleteObjectUndo(prevNode, undoString); // <- originally Undo.RecordObject
prevNode.SetNextNode(nextNodeGameObject);
prevNode.shouldRebuildMesh = true;
PrefabUtility.RecordPrefabInstancePropertyModifications(prevNode);
}
return prevNode;
}
Thank you super much for sharing! For years I’d been finding workarounds during runtime to restore MonoBebaviour references. Never knew RecordPrefabInstancePropertyModifications() was a thing.
