Questions

[smoore2171]

This set of scripts looks very useful. I just had some questions about the implementation.

I'm following that the UnityWeakReference class will allow an object to reference a unity Object and have it convert to a path string pre-serialization of a generated UnityWeakReferenceScriptableObject object.

I would like to understand more of what EditorUnityWeakReference is doing. What it looks like it is doing is a build preprocess pass it goes over every unity object in the assets folder, iterating over properties looking for any property that extends the UnityWeakReference type (albeit ignoring arrays? It doesn't appear to drill down in DoWork) and then creates a bunch of UnityWeakReferenceScriptableObjects in the resources folder back to the real object. In this case it doesn't look like the real object would be in the resources folder, but would it still be packaged and loadable as a resource just by being referenced from an object in resources?

How bad does this preprocess step hurt build times on large projects? Iterating over every unity object in Asset/ seems like it might have scaling issues.

[nostek]

Hi!
Sorry for the late answer.

You are correct! That is how it works :) so the Resource folder only has small scriptableobject files in it.

Never actually tried arrays of weak references, that could very well be a problem.

It takes longer the bigger the project gets, but it is still alright in our project with 100+ scenes 10000+ prefabs+scriptableobjects. Compared to the rest of the building its small part, but it is worth it for the flexibility of day to day work.
There is probably room for improvement there, but it hasn't been worth it for us yet.

Thanks for the questions and fun that you find it useful :)

[smoore2171]

Thanks! For arrays, I meant if I have a scriptable object type has an array of some other type (like an item list), those would get missed. I ended up pulling this down and changing up a couple things. I added support for drilling down into array types and added a manual list of types to support instead of going over every asset.

Array types is simple, DoWork middle just becomes
`if(!itr.isArray)
{
var pref = itr.FindPropertyRelative("reference");
var pgo = pref.objectReferenceValue;

				if (pgo == null)
					continue;

				var pt = validTypes[itr.type];

				var path = AssetDatabase.GetAssetPath(pgo);
				var guid = AssetDatabase.AssetPathToGUID(path);

				if (!assetsToReference.ContainsKey(guid))
					assetsToReference.Add(guid, new AssetInfo { GUID = guid, Type = pt, Path = path });
			}
			else
            {
				// drill down into arrays
				for(int i = 0; i < itr.arraySize; i++)
                {
					var element = itr.GetArrayElementAtIndex(i);
					if (element.propertyType == SerializedPropertyType.Generic && validTypes.ContainsKey(element.type))
						DoWork(element.serializedObject.targetObject, assetsToReference, validTypes);
				}
				
            }`

And I just gather the guids via a list of my supported types like so:

            `List<string> guids = new List<string>();
	
	foreach(string supportedType in supportedScriptableObjectTypes)
	{
		guids.AddRange(AssetDatabase.FindAssets("t:" + supportedType));
	}`

For my project I don't need prefab/scene support ~yet so I have no need to drill down into those two, but good to know its not a huge issue for you on a larger project.

[smoore2171]

Sorry for formatting, not used to git's code block, and apparently I have no idea how to fix it

[nostek]

Fun! You are very welcome to make a pull request with the fix :)

also the change with supported typed.. come to think about it, a optional setting file with that list and toggles for where it should look (prefabs/so's/scenes) wouldn't hurt either

[smoore2171]

yeah, there are probably better ways to support type filtering, especially for a team larger than 1 person :) My implementation is more of a quick and dirty optimization.