#TypeManager.Initialize() in BakingAnalytics in editor

1 messages · Page 1 of 1 (latest)

pallid dust
#

Well everything is in a title - is there reason that BakingAnalytics now initializes TypeManager in editor under InitializeOnLoad (since 1.1.0-exp.1), well I understand that's because they want to access SkinnedMeshRenderer type index, but why not do it lazy on first call, the only reason is probably because it's called from OnImportAsset? Is really hard to control now, and only thing we can rely is assemblies topological order. It's now hard to dynamically load types in editor before TypeManager initialization to properly handle them by TypeManager as we haven't any posibility to put additional types after initialization. Maybe @toxic siren know answer or whom to ask?

image.png
urban python
#

To elaborate a bit as I was discussing this with eizenhorn, it prevents you loading 3rd party dlls that include systems - for example for mod testing

#

I guess we could be a bit dodgy and call Shutdown and initialize it again?

pallid dust
#

Well it not "prevents" I would say, if your [InitializeOnLoad] loads before BakingAnalytics then you may be lucky to load dll and initialize that earlier, but it's not so reliable.

#

But in addition there is another issue here - UnityEditor.TypeCache, as in editor (for example) systems from external dll's even if they're in current domain not picked by type manager, because of TypeManagerSystems.InitializeAllSystemTypes() using GetTypesDerivedFrom which uses TypeCache in Editor. In build all works well.

image.png image.png
#

Example, we have this code called in [InitializeOnLoad]. ModSystem is simple managed system in global namespace. We see it's loaded in current domain and exists. But not for TypeManager (and specifically UnityEditor.TypeCache) as there is no TypeCache know ModSystem! in log

image.png image.png image.png
toxic siren
#

Oh yeah that looks wrong, don't know who did that, but I think @pliant hearth can fix it!

pallid dust
#

As said - at runtime all is ok as it doesn't use TypeCache and TypeManager get types from current domain and properly load types (and specifically systems) from external dll if it loaded before TypeManager.Initialize. But in editor it nearly impossible to test such use case (for testing mods) as it uses editor TypeCachewhich we have no control

pliant hearth
#

I looked at the BakingAnalytics and the TypeManager.Initialize is indeed unnecessary here. I made a fix for it and backported it to 1.2.? (whenever the next one comes out). I don't really know if we are going to/can make bigger changes to TypeManager, but it might be a while. If you want to avoid this slipping through the cracks, you could make a ticket. For now at least this should solve your problem wrt the BakingAnalytics.

pallid dust
#

Thanks! At least we can load our types before TypeManager.Initialize safely and stable without need of modifying package source

pallid dust
#

Because it will just open in editor modding logic testing, and will save a lot of time instead of building every time, also will help debug things a lot!

pallid dust
#

Hey @pliant hearth, just wanted to ask, 1.2.0-pre.12 is out but TypeManager.Initialize(); is still in BakingAnalytics() static constructor, is it intended or fix just been landed after this package version been approved to be pushed in public?

pliant hearth
#

@pallid dust I looked into it, turns out, while I thought the fix was in the new version, I was in fact 2 days after the cutoff point😅 . Sooo... you are correct, unfortunately the fix is not in this version.

pallid dust