Editing prefab causes references to it to become null until the object referencing it is reloaded

The snippet is from the prefab.
The scene doesn't get any changes from it, neither do the other prefabs that reference this prefab.

Basically what I did is edit PrefabA through inspector (increased radius of collider from 0.4 -> 0.5)

PrefabA <-- changes here, the UUID is from the snippet above
PrefabB contains PrefabA nested inside (PrefabB still contains PrefabA but the transforms have been reset (i.e. everything at 0,0,0). PrefabB is basically the level, PrefabA is like the enemy

ScriptableObjectA contains a list of Enemies (PrefabA being one of them). The reference in the list is set to NULL.


Unable to reproduce consistently though. I fixed it by manually reverting the GUID. This fixed the broken transforms in PrefabB but ScriptabelObjectA still had null references. Reloading the assets fixed the remaining issues.

However, I tried to make the same edit again (change radius this time from 0.5 -> 0.6) but no broken referrences and the GUID did not change. Only diff is the radius.


Trying to create a smaller project to repo, but even in my main project we are unable to consistently reproduce it. Which I guess is similar to what @iMobCoding seems to encounter as well

 

No, nothing like that. On the plus side this seems to be a temporary issue, since I was trying to reproduce the issue so i could explain the sort of action causes it, it no longer happens. So once you get the "missing" for a given prefab in a scriptable game object and you reassign it, it doesn't seem to happen to that prefab again. But i'm not 100% sure for all i know this might happen again in the future.

The adjustment that seemed to be the main offender is if I change the size of a list within a prefab variant, so maybe something about lists being outside the correct "range" of the parent objects is throwing things off, but i'm not entirely sure about this either.

 

No I always make edits to prefabs at the lowest level. So in this case, since PrefabB contains PrefabA, I edited PrefabA by entering prefab mode for PrefabA. My understanding is that editing PrefabA while in PrefabB would not apply the changes to all instances of Prefab A. (The snippet is from prefabA)

I don't have any scripts that run in edit mode and all the Destroy() calls are on the instantiated versions of prefabs.. no Destroy(this) either..

When I run the game of course it will do something like Instantiate(Prefab) but that shouldn't have any issues - anything else to look for?

 

Yeah, it is a variant. Basically of "Base Enemy" but we rarely make any change to that. It's only if we add a new component or something.

In the previous encounter of this issue I edited the 'radius' of enemyA, so enemyB was unaffected. Attached a diagram to better show what happened.

Structure looks like this:




One other side effect is we have scriptable object that is basically just

Code (CSharp):

1. public class EnemyList : ScriptableObject {
2.   public List<Enemy> Enemies;
3. }
4.  
5. That contains basically
6. [EnemyA, EnemyB] and after the GUID change it becomes [null, EnemyB]

 

@SteenLund
Uploaded the relevant parts here:

https://gist.github.com/xjjon/54aa0d7fa778f6ff8ce627d4d0d21b61

Basically from

Rollobot Variant.prefab the diff is on line 122 and 133

Also included the Base prefab that the enemy variants from. This one has no diff changes though.

Also included the .asset that gets the references nulled out. Although this also has no diff changes.

Basically the only diff after changing the radius of the variant is on line 122 and 122 (and line 118 for the actual radius value change).

 

Are the dev team at Unity unclear on what is causing these issues? I would be more than happy to commit time to help build some understanding around the problem, though It's very concerning if the underlying issues still haven't been identified?

 

We haven't pinpointed what might be causing our problems (2018.x - 2019.2) - we just know that prefabs, nested prefabs, scriptable objects and even stuff in the scene like materials just sometime turn into nullrefs, and that various methods of restarting Unity or reimporting various assets (scenes, prefabs, nested prefabs, so's, whatever) helps reconnect everything.

Other bugs have been holding us back from trying 2019.3 and the new asset database v2. It will be interesting to see what issues persist. Until then, we'll keep on trying to figure out what workflow breaks serialisation.

@SteenLund I know that the Odin Inspector team are aware of a lot of strange serialisation issues over the last couple of years with stuff going missing (usually in memory). Perhaps you could contact them and see if they know of particular workflows or ways to repro the problems.

 

I'm not sure I understand what you meant? We keep running into this issue. It seems it is actually two different issues though.

1) nested prefabs lose their transform position in the parent prefab. this happens when the 'nested prefab' is changed via prefab edit mode

2) scriptable objects or prefabs referencing other prefabs lose reference to that prefab. this happens when the 'nested prefab' is changed via prefab edit mode - although I have seen it happen without any changes to both the prefab and the scriptable object. (i.e. i check the diffs and no changes have been made for a few days but somehow the reference is lost today)

 

I'm not sure how to debug this issue but here is another case where it happened:

Basically we have this SerializedObject:

Code (CSharp):

1. public class DeathSplitAction : ScriptableSerializedObject
2. {
3.     public int Count;
4.     public EntityComponent SplitEntity; // field in question that gets reset
5.     public GameObject ParticleEffect;
6. }

Now here is the interesting part.

After noticing the value has lost the reference, I set the value again.

Which produces this diff:

Code (CSharp):

1. MonoBehaviour:
2.      SerializedFormat: 2
3.      SerializedBytes:
4.      ReferencedUnityObjects:
5. -    - {fileID: 7648963456065140530, guid: ef668afeae88cdb49a7afb554ed09f8a, type: 3}
6. +    - {fileID: 2815703088370932560, guid: ef668afeae88cdb49a7afb554ed09f8a, type: 3}
7.      SerializedBytesString:
8.      Prefab: {fileID: 0}
9.      PrefabModificationsReferencedUnityObjects: []
10.  

Now what you'll notice is the fileId has changed.

However, that new fileId actually doesn't exist anywhere in my assets.

A quick grep shows:

This is the "new" referenced fileId. It only exists in the scriptable object! None of the assets even use this Id!

Code (CSharp):

1. $ grep 2815703088370932560 * -r
2. Resources/Data/DeathActions/SplitterDeathAction.asset:    - {fileID: 28157030883                                                 70932560, guid: ef668afeae88cdb49a7afb554ed09f8a, type: 3}

This one is the referenced asset! Notice the fileId `7648963456065140530` is the one that was 'removed' in the diff. This is also the value that got 'nulled' out somehow.

Code (CSharp):

1. grep 7648963456065140530 * -r
2. Resources/Prefabs/Enemies/Splitter(Purple).prefab:      objectReference: {fileID: 7648963456065140530, guid: ef668afeae88cdb49a7afb554ed09f8a,

So somehow the game can start and run. No issues when the scriptable object is loaded and referenced.
BUT, I suspect this scriptable object will lose reference and break again soon. Maybe when cache is cleared or something.

I will try to pull this repo on different workstation to see what happens to the IDs.

 

Okay provide a little update.. did some debugging today and also @SteenLund was very helpful.

No root cause found but at least we have a better understanding of what is causing these issues.

Basically the problem is only detected when a prefab is edited because when you save it will update/recalculate the 'fileID' of the transformParent.

So when editing a small field in the prefab, you save it, then Unity may get a new fileID.

This would have a diff like this:

Code (CSharp):

1.    - m_TransformParent: {fileID: 5255327216107892660}
2.     + m_TransformParent: {fileID: 6254788915503491296}
3.     m_Modifications:
4.     - target: {fileID: 102318, guid: 2e0601d5751d2d94ab4a90191a78e2ca, type: 3}
5.       propertyPath: m_Layer
6. @@ -385,11 +385,11 @@ PrefabInstance:
7.     - target: {fileID: 8476175317561794800, guid: 7962000a5b6804b488c7f6227f82b428,
8.         type: 3}
9.       propertyPath: m_Radius
10.     -  value: 0.7
11.     + value: 0.8
12.       objectReference: {fileID: 0}
13.     m_RemovedComponents: []
14.   m_SourcePrefab: {fileID: 100100000, guid: 7962000a5b6804b488c7f6227f82b428, type: 3}
15. - --- !u!4 &5255327216107892660 stripped
16. + --- !u!4 &6254788915503491296 stripped

Basically the expected diff is only the radius change, but instead both the radius and fileID is mutated.

Now here is the interesting part. At first I thought it something where we changed the script or layout of a prefab that caused the fileID generated to be "updated" and just not reflected in the prefab.

However after some testing.. found Unity changing the FileID again! So now not sure how to determine which one is the 'correct' one and what could have happened to change it.

Here is the latest diff to show that:
Basically all I changed was set boolean of "DropsHealth" to true. And you can see that the parent fileId has once again changed..

In between these two builds.. the only thing that happened:

• Build for PC
• Build for Android (Switch platform)
• Made some code changes in scripts that don't touch these prefabs
• Wrote some unit tests for those scripts that don't touch these prefabs

However.. it decided to generate new fileId:

Code (CSharp):

1. -    m_TransformParent: {fileID: 6254788915503491296}
2. +    m_TransformParent: {fileID: 5255327216107892627}
3.      m_Modifications:
4.      - target: {fileID: 102318, guid: 2e0601d5751d2d94ab4a90191a78e2ca, type: 3}
5.        propertyPath: m_Layer
6. @@ -382,6 +382,11 @@ PrefabInstance:
7.        value:
8.        objectReference: {fileID: 6647321959924371367, guid: 7962000a5b6804b488c7f6227f82b428,
9.          type: 3}
10. +    - target: {fileID: 6647321959924371367, guid: 7962000a5b6804b488c7f6227f82b428,
11. +        type: 3}
12. +      propertyPath: EntityData.DropsHealth
13. +      value: 1
14. +      objectReference: {fileID: 0}
15.      - target: {fileID: 8476175317561794800, guid: 7962000a5b6804b488c7f6227f82b428,
16.          type: 3}
17.        propertyPath: m_Radius
18. @@ -389,7 +394,7 @@ PrefabInstance:
19.        objectReference: {fileID: 0}
20.      m_RemovedComponents: []
21.    m_SourcePrefab: {fileID: 100100000, guid: 7962000a5b6804b488c7f6227f82b428, type: 3}
22. ---- !u!4 &6254788915503491296 stripped
23. +--- !u!4 &5255327216107892627 stripped

 

Hello there. We are having the same issue and it has ground production on our game to a halt as whenever we modify a prefab, changes to instances get discarded and references to sub-objects get destroyed. This is a really dangerous issue - does anyone have any advice on how to fix it? It feels like a serious bug in the prefab system...

 

Do you have a diff of what happens in your prefabs? Is it the fileID changing?

I have been doing some testing and seem to narrowed it down to this step causing the issues:

1) build a apk or exe
2) make a change to the prefab
3) check the diff, it will show the value that i changed and also that the fileId has changed <-- this is what causes the prefab references and stuff to break

now if i revert the change, restart unity, and make the change again, there is no issue with the fileId

does this reproduce for your project?

 

Eh, sorry to hear that. Told you, it was really inconsistent but happened multiple times for me...

Yeah, I already prepared 2019.3 template for new projects, but there is one I am stuck on 2019.2 and can't update it now and risking bugs in this latest phase

 

Just wanted to chime in about my experiences in 2019.3 again. As I stated before the links will continue to break after the upgrade, but it seems that once they do and you fix them, you don't have to do it again, so 2019.3 won't instantly fix everything, but it no longer breaks things once they are reassigned.

So if you do upgrade to 2019.3 the issue does appear to go away, but it takes some finagling and fixing of broken links over time until they appear to stop breaking. So you may want to make a backup of your project if for any reason you think you might forget what assets are linked where.

TLDR if the issue is indeed fixed in 2019.3 then u will have the issue for a short time after upgrading when you update prefabs, but it will slowly fix itself over time.

 

That sounds like what I am experiencing - nice work, Steen!

Will this fix be applied to Unity 2019.2? (I am having a nightmare upgrading to 2019.3).

 

Just checked... my prefabs are variants... but are not in the Resources folder.

 

Thanks for the info, @SteenLund

I am seeing this happen with regular, non-variant prefabs. I don't instantiate, or have anything in the resources folder.

I can't upgrade my project to 19.3 as I get stuck in an infinite import loop. If you can get a fix into 19.2 that would be rad I understand if you can't though, and appreciate the transparency!

 

@SteenLund does your latest repro suggest anything about non-build problems like we are experiencing up to 2019.2?

We have reference issues with prefabs, nested prefabs, scriptable objects, and sometimes materials in scenes just null out (in memory) - they require combinations of manual reimports or editor restarts to flush out and populate the references again. This happens sometimes after builds, sure, but it also happens often after updating assets from a source repo (and I saw the materials nulling out from renderers issue happen a few times just working in the editor).

We have not migrated to 2019.3 yet (other issues) but so far in tests 2019.3.9/10 seems a bit more stable than 2019.2.17 (our current version), so maybe you've already fixed some of the bugs causing our issues.

 

Bug report filed! I also found a work-around and updated the bug report. We're currently updating to 2019.3 and are looking forward to your fixes!

You can do it! <3

 

Great, thanks for the update and for the fixes @SteenLund.

 

Yeah I notice this too. Sometimes preferences to prefab gameobjects (not component) will be nulled out randomly.
A reload or reimport USUALLY has fixed this. It's not changing the fileID or anything though, just for some reason in the inspector the value shows as null.

Looking at the actual file reveals that it's not the case

 

Yeah, we have a lot of in-memory problems when stuff is loaded in the editor. They don't appear to be problems in the source assets/yaml unless we modify stuff and save (without noticing there were some missing refs in the scene etc), and then sometimes that bad data is persisted... but not every time. Bit of a minefield at the moment in 2019.2.x.

 

For clarity - a few mentions of fixes in 2019.3 - Are these in the currently released version, or some upcoming version?

 

Quick question for @SteenLund - do you have a rough ETA on your latest fixes for 2019.3?
I won't hold you to your answer, but an estimate would be really helpful, as we are currently trying to ship a demo.
Thanks in advance!

 

Hmmm. On version 2019.3.10f1, with the new asset library system, I am still seeing prefab links dropping all over the place.

What is even weirder is that I can check everything, and the links are all good... then I submit all the files to my source control, for safety. Then I build my project... see the links break... revert back from source control... and different links are broken, totally at random - links that I just checked, and successfully built and tested.

Is there a directory that I could be missing from my source control? Because building my project is currently destroying it irreversibly.

I am trying to be patient, but this is an extremely serious bug in a critical system of the engine, which is causing emotional stress on our team and financial stress for our company, as we try and wrap our game (not an easy part of the creative process at the best of times). I am, quite honestly, flabbergasted that the new prefab system was released with this kind of issue in it.

I hope this can get fixed quickly - any and all help is very much appreciated!

 

Yes.

What I saw most recently is that links would be broken on a few objects. Some are Prefabs... some are Prefab Variants.

These objects are nested prefabs (i.e. a prefab inside a prefab).

It took me a while to notice, but In the main scene the objects weren't even there... and were showing as "missing prefabs". However, there were no overrides, and opening the parent prefab showed the child prefabs to still be in place. Re-importing the parent prefab and then reloading the scene brought the objects back and fixed the links.

 

@SteenLund nice work tracking these bugs down.

Is there anything we can do in the meantime to prevent this problem (eg. while we are still using 2019.2.x) or is the only solution just to keep reimporting assets, restarting the editor, etc and wait for fixes and to also be able to migrate to 2019.3? This has been a big problem for us for nearly 18 months. If the problem was more widespread I assume you would have received more bug reports and been able to fix it sooner, so are our issues an edge case we can avoid or a more general issue?

 

Thanks for the update - that's great to hear.
As well as restarting the editor, do I have to roll back any changes made to prefabs during the build process?

 

One month anniversary of having a fix, is this in a live version yet?

 

I look forward to a stable release in the stable release version!

 

Sounds great. We'd really appreciate getting these serialisation fixes back into 2019.3 as it's still killing our productivity chasing nullrefs every day in prefabs, nested prefabs, SO's etc. It's so unreliable that updating from source control and reopening a scene that uses prefabs is a constant nightmare - you just never know what's going to be missing.

(Currently using 2019.2.17 and 2019.3.13)

 

Thank god this has finally been nailed down. We've been struggling with this for months. Mainly prefabs losing sprite references from the PSD Importer plugin when uploading and downloading from source control.

 

@SteenLund, any update on when we might see this in 2019.3? Massive productivity killer, but its not practical to upgrade the entire project to 2020.