Dropping Slider reference when changing scene

[Murten]

Hey,

My game is dropping the slider reference (which works great otherwise) when I leave the scene and then come back. This means that even though I have the PlayerPrefsController and I can fetch the currently saved value I can not apply it to the slider since it has fallen off when I switched scenes.

Anyone got any good idea on how to make the Inspector refererence of the slider persist through the scenes? I use the slider on a different game object than the audiosource.

Edit:

My problem is that when I re-enter the scene (go back) the slider has dropped out so even though my PlayerControllerPrefs are ok and Im fetching them OK it doesn’t matter since I drop the slider reference.

Could I maybe FindObjectOfType? Since this gameobject carries a “Dontdestroyonload” how do I then trigger that search when I load the script from the level loader.

:…I notice that I didnt make it much better now.

[Nina]

Hi Murten,

Check if your “singleton” calls gameObject.SetActive(false); in the same if-block where Destroy(gameObject); gets called. If there isn’t that line of code, add it.

[Murten]

Hey Nina,

Thanks for a quick answer, would it be possible to expand on it a bit?

I will try to clarify my question as well:

This is how it looks when I start the game.

This is how it looks when I “Go back” to the homescreen. It falls out.

As you can see my “dontdestroyonload” gameobject is different from the slider so I dont “carry the slider with me”.

My question is that if I do the gameObject.SetActive(false) will that not only knock out the AudioObject gameobject and not the “slider” one? Aka the object that the script is on.

I truly appreciate the answer, I’m beyond stuck and can’t find a way forward wherever I look.

//Martin

[Nina]

Thank you for the screenshots. They helped me understand your problem better.

You are right. Since the slider is not below DontDestroyOnLoad, the “singleton” code does not destroy it. Theoretically, given I understood everything correctly, all you do is to load a scene. And you expect that the scene gets loaded the same way as before. If this is what you meant, I’m wondering if there are multiple “Start Menu” scenes. Or scenes that look like the “Start Menu”. Maybe the scene you see first is a different scene than the one you see when you “go back”.

Could you check that?

[Murten]

Hey,

Thank you again for the answer I have really been trying to dig.

I’m quite confident it’s not another scene that is being loaded. I think that when I go back to the first scene the only problem is that I can’t get the slider reference (since that has fallen out) and hence I it just doesn’t work.

The problem being that Unity seem to scrap [SerializeField] / Inspector references when you leave that scene. If that is something I’ve managed to isolate what would be the best way to fetch a slider that is the child of another gameobject only through script you recon?

One more thought, I’m really overkilling this assignment but I got bogged down into it and now I can’t stop. Let’s say I want to be able to change the slider value on every screen in the game (not only in the menus).

Would it maybe be better to

A) Create a Slider Script that I place directly on the slider, I make it a Donotdestroyonload and singleton to not have duplicates.

B) I simply SetActivate(False) when it’s not in use.

C) This would make it easy for me to not destroy the slider / needing to reference it again and I could just always SET/GET the volume from the PlayerPrefsController.

–The problem I see with this is that I would have to re-design the size of it for every screen and I’m not really sure I know how to do that.

I’m just spitballin now but maybe something in that direction would work to always have access to the slider/volume wherever you are in the game?

.PS .Worst case scenario I just run a Options scene but I would prefer not to:)

[Nina]

@Murten

The problem being that Unity seem to scrap [SerializeField] / Inspector references when you leave that scene.

Yes, that seems to be the problem. However, this is not supposed to happen.

Unless something destroys the slider when the scene got reloaded, the concerning field should still reference the slider. Alternatively, it might be that your code overrides the value of the field with null. That’s something you’ll have to analyse further. If nothing helps, disable all game objects but the slider and maybe the game object which loaded the next scene. Then test your game again. If the problem disappeared, enable the disabled game object step by step and test all of them until the problem reappears. Debugging is not difficult, just repetitive and boring from time to time.

Regarding your three approaches, do you need the slider to be in each scene? If so, making it persistent via DontDestroyOnLoad makes sense. If not, I would not make it persistent.

Why would you want to reference the slider anywhere? Referencing is always a bit tricky because a lot is going on during runtime, and we don’t have much control over Unity.

If you want to challenge yourself, create a VolumeHandler class and attach it to the same game object as your Slider component. You could either add the reference to the Slider manually or via GetComponent. The VolumeHandler “communicates” with the PlayerPrefsController.

AudioSources get the relevant data from the PlayerPrefsController, not from the slider or the VolumeHandler.

Instead of a VolumeHandler, you could even create a more general SliderHandler class or something like that and work with enums which are mapped to strings in the PlayerPrefsController class. Look enums up on DotNetPerls to see an example. You could define different slider types and create an enum. If you have multiple sliders and different types, this approach could make sense so you don’t have to create 4 different classes and duplicate code 4 times in the PlayerPrefsController.