Prefab overrides inconsistent - leading to all components on prefabs in scenes being completely dirty

[TheXRMonk]

It might be me who's doing something wrong, since we started using ForceReserializeAssets to automatically update all our assets when we update unity, or when we pulled in this package. But it seems like different values are written to the serialized asset based on whether it's run by ForceReserializeAssets, or inspected in prefab mode, or in scene mode.

Are you able to shine some light on this issue?

[hybridherbst]

Hmm, I thought we serialize the global object ID of the script file here, which shouldn't change; but looks like it may be the ID of the object instead.

Thanks for the report!

[marwie]

We're using the global object id yes (as you can see in the string itself too) - I have seen Unity serializing different data depending on context for this before. Not sure what we can do about it - perhaps ignore it when the guid is missing (just 000000)

[HamzaRino]

hello, sorry if I'm hijacking this issue,

I have more than one question if I may,

I will start with one related to the issue reported here:

I'm interested to know if the "$ {globalObjectId}" suffix is necessary here (at all). for instance it's not being used here

thanks a lot
and keep on rocking the unity tools world!

NOTE: @hybridherbst still waiting for the UPM extensions package to be open sourced as you said in the JetBrains video 😛

[TheXRMonk]

I'm interested to know if the "$ {globalObjectId}" suffix is necessary here (at all). for instance it's not being used here

Are you using that package instead? Does it have similar issues? Pros/cons?

[hybridherbst]

@marwie I meant we could use the GlobalObjectID of the script file instead of the object (

missing-component-info/package/Editor/MissingComponentHelper.cs

Line 75 in 5231bfb

var identifier = type.AssemblyQualifiedName;

) but on second thought that may be stupid since when the guid changes that would change as well 🙃

@HamzaRino feel free to join our discord https://discord.needle.tools, Package Tools have already been made public on our registry for everyone to use, just not open sourced yet

[HamzaRino]

I'm interested to know if the "$ {globalObjectId}" suffix is necessary here (at all). for instance it's not being used here

Are you using that package instead? Does it have similar issues? Pros/cons?

yes I settled on using that one instead because I was not sure about the "$ globalObjectId" suffix also about not sure if we need all the heuristics comparisons (LevenshteinDistance for all types?)...
so it seemed like it's too much for me (maybe it covers more use cases for bigger projects)
while the other solution looked much more simpler.
but at the end I had to also make a custom one (based on SolidAlloy's) for us and simply search for files based on their names either using AssetDatabase.Find or simple plain Directory.GetFiles as there are cases where the script is there, unchanged (same path, same name, same GUID) but Unity fails to pick it up (while switching branches or changing packages)...

besides the MissingReferences folder and tools here should probably belong somewhere else?

[HamzaRino]

@HamzaRino feel free to join our discord https://discord.needle.tools, Package Tools have already been made public on our registry for everyone to use, just not open sourced yet

thanks @hybridherbst
when I tried the package after watching the video it threw errors in our project (I think it was Unity 2021 LTS back then now we are on 2022), I was just curious why the other packages are open while this one is available to use but not open...maybe you want to sell it at some point but hey I'm not complaining I love your work and what you do!

[TheXRMonk]

there are cases where the script is there, unchanged (same path, same name, same GUID) but Unity fails to pick it up (while switching branches or changing packages)...

Funny, that's the exact same issue we have and why we need a package like this. We just need to know which asmdef failed to import, then we can just reimport it from within Unity and everything will work fine again. Tried raising the issue in the unity forums but they just dismissed the issue with "the meta file must have changed" and "prove it".

[marwie]

Are you able to get this information from the data written to the EditorClassIdentifier or is there something missing for you @TheXRMonk ?

@HamzaRino The distance of types etc is only invoked if the script is missing AND you open the relevant foldout in the UI to try to find a matching name. There should be no performance overhead by default after writing the script information into the EditorClassIdentifier field. Let me know if you see cases where that's not the case

[TheXRMonk]

Are you able to get this information from the data written to the EditorClassIdentifier or is there something missing for you @TheXRMonk ?

Get which information? Why the id changes?

[marwie]

Which asmdef failed to import

[TheXRMonk]

Which asmdef failed to import

I don't see how that's relevant. I was just confirming the need for this package because it helps with solving these issues that come up with unity sometimes. Unrelated to wether or not this package is installed.

My issue as originally posted is that the EditorClassIdentifier is serialized differently based on where you inspect the component. Prefab or scene or through the ForceReserializeAssets.

[marwie]

Ok great 😉

I got that

[marwie]

Just published an update (1.5.1) that should prevent serializing data like reported above.
I couldnt reproduce it here unfortunately in 2022.3.3 and with ForceReserialize. Could you perhaps check if this fixes the issue for you @TheXRMonk ?