You should avoid changing them. They

[mortal nimbus]

So if I need a global reference to something that changes, I should use singleton?

@restive sinew So for instance, I have a script that is attached to ground tiles that are generated, if the gameobjects attached script has a int that is lower than the current int the player has, I want to disable the renderer of the gameobject, the problem is each gameobject is maintaining an independent int for managing this.

I want to store the players current layer on the player via a player manager and reference it on each component that is generated after the game starts. I do not want to hand or add the player manager script to all objects.

So I figured I would use a scriptable object for the player and reference it through events or something, is there a better way to do this?

[split trench]

Scriptable Objects should be thought of as a database. If it's a problem that would be solved with a database, it's a problem that could be solved with a scriptable object

[mortal nimbus]

Databases change all the time, haha.

[split trench]

Your example does not seem like something scriptable objects even can do, regardless of whether they should

[split trench]

Yes, but schema don't

[restive sinew]

you can store the player's layer in an SO and have a reference to that SO on the player script. the script on each ground tile reference this SO. that way, they can use the SO the check/compare against their int (layer) . . .

[split trench]

You'd add new rows, but you won't change the actual structure of the database

[split trench]

Not a good use for them. It'd persist between sessions in the editor, but not in a build.

And you'd still need to have a dedicated reference on every object that wants to check the layer, they're just referencing a different thing

[restive sinew]

yes, they would need to reset it during testing (exiting playmode). one of the caveats of using it this way . . .

[mortal nimbus]

I see, so if I wanted one that persisted through scenes and other states I should use a singelton?

[restive sinew]

true, but they're still saving memory because all tiles are pointing to only one (the same) reference . . .

[mortal nimbus]

and not a scriptable object?

That is my overall goal is to have one int that everything references.

[split trench]

Yeah, but so would a singleton, or just dragging in the player object as a reference

[mortal nimbus]

The player should be the only thing that controls what layer the game is on.

[split trench]

Why is that your goal? Seems to me like the goal should be to have a single source of truth that everything else references. Making multiple sources means your data can desync

[restive sinew]

very true. they can pick their poison . . .

[split trench]

Er, wait, I misread your message

We are in agreement I just read "isn't" instead of "is" for some reason

So, you'd have the player or a singleton hold the value, then everything else would read that value from that. Then it always behaves the same way no matter how you're running the game

[mortal nimbus]

Here is an example of the same variable being referenced in two different scripts, but each script owns its own.

So like you said I am getting desync between these:

I am trying to decouple dependancies though, so that I do not have to go playerScript(data)->Movementscript->visabilityScript.

If I have to include a reference to the player script on all of these game objects, I can, I just figured there was an easier way.

so you can see here the value is wrong causing the fish to be missing, but if it reference one of the fish that actually show up, it would work correctly.

I want these two scripts that do different things to be in separate scripts, as they are not fish specific.

[split trench]

If there is always exactly one value for this variable, never more and never less, then it should be a singleton. The code that needs it should reference it from the singleton instance. You can make the variable a property with a public getter and a private setter, that way your other scripts can all read that data, but only that script itself is allowed to change it