Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice
  3. Dismiss Notice

Bug Variable set in inspector becomes null at runtime

Discussion in 'Scripting' started by noonoox, May 23, 2024.

  1. noonoox

    noonoox

    Joined:
    Nov 15, 2014
    Posts:
    27
    In editor:
    upload_2024-5-22_16-42-20.png

    In playmode:
    upload_2024-5-22_16-42-32.png

    Context: Microgame Preview Default Sprite & Mg Ceelo are both set to asset files.

    Things that don't fix this:
    • Restarting Unity
    • Updating Unity
    • Restarting my PC
     
  2. Kurt-Dekker

    Kurt-Dekker

    Joined:
    Mar 16, 2013
    Posts:
    39,357
    Look for any code that writes to it (assigns to it)... there's an extremely-bad common pattern out there where a public field is ALSO then assigned to from GetComponent<T>().
     
  3. noonoox

    noonoox

    Joined:
    Nov 15, 2014
    Posts:
    27
    These variables are not touched by any code at all when entering play mode.
     
  4. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,682
    Tried tossing the Library folder?
     
  5. noonoox

    noonoox

    Joined:
    Nov 15, 2014
    Posts:
    27
    unfortunately that didn't work either :/
     
  6. CodeSmile

    CodeSmile

    Joined:
    Apr 10, 2014
    Posts:
    6,922
    Are you sure?

    If they are public change them from
    public Sprite microgamePreviewDefaultSprite;

    to
    [SerializeField] private Sprite microgamePreviewDefaultSprite;

    and see if the compiler complains. ;)

    Also check all uses of this sprite in your script. Perhaps you assign it somewhere? Consider whether it might assign null. Set a breakpoint and debug.
     
    Bunny83 likes this.
  7. noonoox

    noonoox

    Joined:
    Nov 15, 2014
    Posts:
    27
    This bug occurs even if I comment out the *only* line of code referencing it. Also I can't set it to private because the I set the variables using the inspector asset picker.

    Note: My screenshot is taken with the editor paused immediately upon entering play mode.
     
  8. CodeSmile

    CodeSmile

    Joined:
    Apr 10, 2014
    Posts:
    6,922
    SerializeField exists to expose non-public fields to the Inspector. ;)


    Try creating an empty scene, put that component on it, add the same references and then enter playmode. If necessary comment out some code that doesn't work in isolation.

    Also post the code for the component in case there's something one of us can spot.
     
    noonoox and Bunny83 like this.
  9. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    8,391
    That's... not true. We have the
    [SerializeField]
    attribute to serialize non-public members. And it of course draws with the exact same drawer as public fields.

    There's no custom inspectors at work here?
     
    Bunny83 and Spy-Master like this.
  10. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    2,166
    no chances somethings being destroyed?
     
  11. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    8,391
    A destroyed object would show 'Missing' rather than 'None'.
     
    Bunny83 likes this.
  12. Bunny83

    Bunny83

    Joined:
    Oct 18, 2010
    Posts:
    4,189
    Whenever you may have issues with a variable getting changed, you can always exchange them with a property that does additional logging when you read or write to it. The only thing that could not be detected would be Inspector or serialization system changes.

    So if you have

    Code (CSharp):
    1. public Sprite microgamePreviewDefaultSprite;
    you can temporarily replace it by
    Code (CSharp):
    1.  
    2. [SerializeField]
    3. [FormerlySerializedAs("microgamePreviewDefaultSprite")]
    4. private Sprite m_MicrogamePreviewDefaultSprite;
    5. public Sprite microgamePreviewDefaultSprite
    6. {
    7.     get {
    8.         Debug.Log("Reading microgamePreviewDefaultSprite: " + m_MicrogamePreviewDefaultSprite, gameObject);
    9.         return m_MicrogamePreviewDefaultSprite;
    10.     }
    11.     set {
    12.         Debug.Log("Writing microgamePreviewDefaultSprite old value: " + m_MicrogamePreviewDefaultSprite + " new value: " + value, gameObject);
    13.         m_MicrogamePreviewDefaultSprite = value;
    14.     }
    15. }
    16.  
    This will log any occation when the variable / property is set to a different value. The stack trace of the log tells you which method (chain) caused this change.

    If this does NOT detect anything, you either have some dodgy CustomEditor that is messing with the fields or you use some serialization system (JsonUtility, ...) or reflection code that is overwriting those values. We can't really help you here any further. At the moment we don't even know if we talk about a MonoBehaviour or ScriptableObject or if those fields are part of a custom serializable class instance. You have to do the debugging as we don't have your code or project, so that's all up to you.
     
    Kurt-Dekker and noonoox like this.
  13. noonoox

    noonoox

    Joined:
    Nov 15, 2014
    Posts:
    27
    And now the part where I feel silly! Yup, this helped me track the issue down. I'm definitely going to keep this snippet in mind!
     
    Kurt-Dekker and Bunny83 like this.