search

superunitybuild / buildtool

A powerful automation tool for quickly and easily generating builds with Unity.
MIT License
1.19k stars 121 forks source link

BaseSettings.CreateAsset<T> called before existing settings asset present in AssetDatabase #97

Closed nickfourtimes closed 1 year ago

nickfourtimes commented 1 year ago

BaseSettings.CreateAsset<T> is invoked whenever a reference to BuildSettings.instance is called for the first time.

However, it seems as though, even if a valid SuperUnityBuildSettings.asset file exists, it's not yet "present" in Unity's AssetDatabase, and so after this call to AssetDatabase.LoadAssetAtPath<T>, the value of instance is still null.

A result of this is, e.g., when the editor is first opened, and the SuperUnityBuild window is first accessed, the existing default SuperUnityBuildSettings.asset file is "created" anew, overwriting the pre-existing asset (and thus losing any prior configuration).

nickfourtimes commented 1 year ago

Boy, okay, I think I found the cause of this. Basically, I'd created my first SuperUnityBuildSettings.asset when the SuperUnityBuild package had been installed via Git URL in the Package Manager. However, since I figured I might have some tweaks & bug fixes to contribute to the SUB project, I cloned the SUB repo elsewhere on disk, uninstalled the Git URL SUB package, and installed the SUB-on-disk package.

I guess somehow this resulted in the BuildSettings class getting hashed differently, and thus when BaseSettings.CreateAsset<T> was looking for a BuildSettings asset, it couldn't find one (since it was looking for a BuildSettings asset as created by the SUB-on-disk package, and not the Git URL package).

However, if I remove everything – the SUB package, as well as the SuperUnityBuildSettings.asset file – and start from scratch, just using the SUB-on-disk package (i.e., the SUB repo that I've cloned elsewhere on my computer), then BaseSettings.CreateAsset<T> correctly recognises my pre-existing settings file, and does not overwrite it. So the problem was mainly caused by my switching the source for my SUB package – from Git URL to a repo on disk.

Since this is a pretty wild edge case – and (I think) more of a problem on Unity's end – I'm going to mark this as closed for now.