Pixel Crushers Forum

Hey Toni,

We upgraded to 2.0 and are having some issues figuring out which component to add to an object to preserve its current animator bool state across loading.

For Example:
We have a statue sprite with a light on and it begins with the bool "Lit" set to true. When you attack the statue, the bool becomes false. After saving and loading, the statue's animator bool "Lit" goes back to being true. Is there a way to preserve this value change after loading?

Our current workaround is to create 2 objects, one a parent of the other. The unlit version of the sprite is on the bottom sorting layer and is the parent of the gameobject with the lit sprite, which is on top (as a child). We then added a collider to both objects but turn the lit one off and turn the unlit one on with a sequence. This works because of the Persistent Destructible, because in this scenario, we are disabling a gameobject (the on-top lit sprite) but this would be rather tedious for each and every object that needs to have a persistent animator state across loading.

Would you perhaps know of a simpler way to handle this situation?

Thank you.
-Nik

Hi Nik,

Thanks for taking the plunge and going to 2.x. It has a lot of nice improvements and optimizations, including improvements to the save system.

There's now a component called AnimatorSaver that saves an Animator's states. In the upcoming version 2.0.5, it will also save the Animator's parameter values. Here's the updated AnimatorSaver that will be in version 2.0.5:

AnimatorSaver_2018-10-01.unitypackage

And here's an overview of the save system in 2.x:

Thanks that worked! Also, the entire 2.0 has been working like a charm, we've noticed all the small changes here and there and are really glad the save system is so much easier to use.

Also, for the key field (we don't really use it), but if we have the same named object in another scene, will this overwrite the saved state at the original key or is it differentiated somehow?

I'm glad to hear 2.0 has been working well for you!

If a saver component's Key field is blank, it will use the GameObject name for the key. If two GameObjects with saver components have the same name, even if they're in different scenes, they will overwrite each other's saved game data. You'll need to manually differentiate them by assigning unique keys (e.g., "FountainStatueAnimator" and "TempleStatueAnimator").

The exception is if Save Across Scene Changes is unticked for both. In this case, each GameObject will only record its state in the saved game data if it's in the current scene. When you move to a new scene, its data is dropped. This helps keep your saved game files small by allowing unimportant objects' state to be reset when moving to another scene.

Gotcha, thanks for clearing that up.

We also had another unrelated issue, we tried using MoveTo to reposition our player (in 2D) from a sequence and it stutters as it moves him to the end point. We didn't have this issue before 2.x though so I'm not sure what to do about it.

The MoveTo() command didn't change from version 1.x to version 2.x. Could it be coincidental? Maybe something else changed?