Unity loses references when pulling from Collab

Hi,

use case
====
Developer X creates a GameObject property in a c# class and exposes it in the Inspector.
Developer X drags a game object onto the property in the Inspector
Developer X saves the scene and commits the changes to Collab

Developer Y pulls the changes from Collab
Developer Y gets a notice that the scene needs to reload
Developer Y reloads the scene and press Play

Actual: The reference is missing/not set in the inspector
Expected: The reference should be set, of course...

To avoid the problem: After pulling changes from Collab, DO NOT SAVE THE SCENE. Restart Unity. Now the reference is correctly set.

For six months now we have been struggling with this stupid bug, and we start to wonder if Unity care about it at all? We have been reporting it several times.

If a developer forget about the routine to restart unity after pulling from Collab, all hell breaks lose, and almost daily we have a build that crashes on the device because of this. It's a major distraction and show stopper. Restarting Unity 15 times per day to avoid the problem, and constantly having to worry about if our builds are working or not is not ideal. Towards our partners, it makes us look stupid. So many times they are downloading a build from Collab only to see it crash after the splash...

We have seen this bug in all versions of 2017, in 5.6 and in 2018 beta.

When will someone on the Unity side of the table actually do something about this bug?

https://forum.unity.com/threads/obj...t-survive-after-2nd-push.515322/#post-3377012

 

Yea, we've had this bug a couple of months ago and it took us a while to figure out the workaround as well.

In Unity 2017.3 it seems to have been fixed, or at least we haven't experienced it in a while

 

Hi @HaakonL! I apologize for the delay in this fix. It's making its way through release management now. It likely won't get into the next 2018.1 beta but we'll aim to get it in by that version's release.

 

This fix is confirmed to be in 2018.1.0b12. Feel free to try that beta when it comes out or wait until the official release of 2018.1.

 

I think this should be backported to 2017.3.1.p3 asap, we can't work in a beta version.

 

We do plan to backport many of these fixes to 2017.3.

 

On 2017.4.14f1 and we're having to recover references manually after each pull. Not all of them, but some.

 

Hi @lexi89puzzle! Can you go into more detail about which kind of references are being lost each pull? Are they between you and your teammates or between yourself on different machines? Are they references to prefabs, scripts or something else? Do the same references seem to be getting lost each time or different ones? Are you on Mac or Windows?

 

2017.4.17f1
All the new fields lose references on prefabs and ScriptableObjects. AudioClips, GameObjects, even AnimationCurves.
Good luck to me fixing curves on the remote machine...

 

Hi @E-Cone! That is incredibly frustrating. Does this happen every time you add a new public field in your ScriptableObject, edit its default value and push those changes? Are you developing on your own or is anyone else potentially working on this asset?

 

It happens even on gameObjects in a scene. Every time I add new field with a reference to a class and change its value, my other PC pulls everything with default values.

I stopped my Collab subscruption and converted recent projects for github.

 

This problem still happens on current Unity 2019.1.3f1 , also reverting to old commits does not work and also pulling it from remote from scratch does not help...

I think Unity Collab may have issue with indexing GameObjects in a scene somehow...

(I encountered this bug in 2018.x and 2017.x versions as well)

Edit: Indeed, the file IDs were set to 0 by Unity collab. This occurs sometimes, this time while switching from version 2019.1.2 to 2019.1.3

 

Hi @dimib, thank you for letting us know about the upgrade scenario. What other times have you noticed the file IDs being set to 0? Do you happen to have a repro project that you'd be willing to share with us to help with debugging the source of the issue?

 

This is still happening on 2019.1 - is there any way of fixing this?

 

Hi @Farage, before we can even start fixing it we need a consistent repro for when this happens, which has been very difficult since nearly everyone we've reached out to for more information hasn't followed up with us. If you'd be willing to help us by providing us with a project that reproduces the problem consistently then we'd really appreciate it and can begin debugging and figuring out how to fix it.

 

@ryanc-unity

We, too, are struggling with this and really require a fix.
We are using Unity 2019.1.4f1, working on a project that's about 2 years old.
The fix that's mentioned in the OP kind of works, it requires us to restart Unity every time we pull from Collab, which is ridiculous.

How to reproduce:

Make a new public variable in a file that's a ScriptableObject. Fill that reference via the Inspector. Save. Push to Collab.

Other developer pulls from Collab. Opens the ScriptableObject data file. Reference is set to null/none.

Could you assist us with this?

EDIT: In case that matters, we are using the Odin Inspector Plugin, maybe that could be causing the breaking?

 

@ryanc-unity

I may provide some usefull finding:
It happens to me when im pulling changes from git repository. Refreshing or reimporting asset does not help, HOWEVER when i delete problematic file in Unity project window and then discard this change in git client it magically works. Also when i'm opening misbehaving asset in text editor, all values seems to be set properly.

 

Hi @kbm and @przemeknowaczyk! Thank you both for your additional input and repro steps! I was able to verify that the bug could be reproduced in 2019.1.14f1. However, it appears that the bug is fixed with the new Asset Import Pipeline v2 in 2019.3.0f5. If you're unable to upgrade to 2019.3 then let us know and we can open a back port bug for 2019.2, which is the earliest non-LTS release that we support right now.