Resolved Static fields reset on build?

Hello,

For a use case i created a editor script / scriptable object that basicly reads the player build settings background texture, every time the setting changed, so it can stuff it inside the static field of another script for purposes.

Everything works fine, in the editor, the static field reads the texture correctly etc... But when i build, it appears to reset the static field to null.

I used the following code for setting the static field;

Code (CSharp):

1. if (PlayerSettings.SplashScreen.background != null) SplashscreenManager.splashscreenImage = PlayerSettings.SplashScreen.background.texture;

, where

SplashscreenManager.splashscreenImage

is the static field

I think this might be because of the method of setting the static field? If so, what would be the proper way to set static data like this?

 

This works the same way as in the editor. But either this code never runs in a build, possibly because it's being called from an editor-only method, or you may have a NullReferenceException. Did you try a development build or check the player.log?

 

Yes exactly this... we absolutely KNOW that the following code could never even compile in a build, let alone run in a build.

Why? Because PlayerSettings is part of the UnityEditor namespace.

https://docs.unity3d.com/ScriptReference/PlayerSettings.html

No part of anything in a static variable would ever "make it into" your build anyway, since static variables cannot be serialized.

If you need something prepared before or after build, use one of the pre- or post- process build step interfaces.

 

Both

And

Yes, apparently im just stupid and believed static fields were serialised into the script itself.

For my use case ill just create a system that serialises the reference of the image when changed in the player settings, and loads it into the static field using a non-editor method.

Thank you both

 

Create a system... are you sure?

Is there anything wrong with Unity's reference system to drag an image in, or else drop it in a Resources/ folder and access it by name?

Or are you leaving out some important part of your use case??

Or maybe if you just like "creatin' systems" that you get to maintain and debug far into the future? Maybe? I dunno, I prefer to gamedev.

 

In my use case, i need to run code Before the splashcreen happens (Which is only possible in the static InitializeOnLoad() method), this code requires the aspect ratio of the splashscreen background image. It would be more convenient if the method automaticly gets the image from the settings rather than have the user supply it.

 

I mean, the word 'System' may be a bit overstating the issue, in the end it is only a updated file containing a path string to the latest splash background image in the player settings.

 

You know that InitializeOnLoad() is actually an editor-only attribute too, right? Are you talking about RuntimeInitializeOnLoad perhaps?

And besides, what do you hope to do with a path in your build? The entire Assets/ folder (except for StreamingAssets) is destroyed and gone and does not make it into a build. Knowing that file X was located at

/Assets/MyFiles/X.png

is completely useless in a build.

And even if X.png was referred to somewhere and thus included in the build, its path will not be useful for getting it.

It just feels like this sort of thing is simply going to break again and again on you as Unity changes stuff. I try to stay far away and outside of edge-casey stuff like this.

An alternate solution would be an editor script that lets you select the splash image and simultaneously:

- sets it in the player settings
- saves the string of it in your file (OR, better yet, takes the info you need from it)

That way you commit both changes to source control (you ARE using source control, right?) and you don't have this constant worry of your weird super-early run step failing in the future.

Alternately, make a ScriptableObject solution for what you need.

It seems any of those InitializeOnLoad() type things are just asking for trouble.

 

sorry for my keyboard deficiency, sometimes random letters make it into my comment, did not intend to start the comment with 'sss'

Correction;

Code (CSharp):

1. [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSplashScreen)]
2. public static void InitializeOnLoad() {
3.  
4. }

Tested it in build, and it works...

Was trying to find the strikeout format option to quick edit my comment for the last 4 minutes. Not a file with a path string of course. Might as well put the desired aspect ratio in there.