Page 1 of 1
SaveSystem Execution Order
Posted: Tue Mar 01, 2022 1:50 am
by VoodooDetective
This is a two part question:
Part 1
Is the Script Execution Order for DSU documented anywhere? I just want to make sure I haven't messed it up.
Part 2
I'm trying to track down an issue whereby the SaveSystem coroutines are not running before the default execution order coroutines. Instead, it seems to be running after all other coroutines. I know there are weird attributes that can change execution order from code without it showing up in the Editor's menu. I was just wondering if you had any idea what might cause this.
Re: SaveSystem Execution Order
Posted: Tue Mar 01, 2022 9:24 am
by Tony Li
Hi,
The Save System doesn't sneak any execution order attributes into any scripts. They're all included in the .meta files, so you'll see them in Edit > Project Settings > Script Execution Order.
Which coroutines are not running? If you look at SaveSystem.LoadSceneCoroutine, you'll see that, after loading the scene, it waits the number of frames specified by "Frames To Wait Before Apply Data". Then it waits until the end of the current frame. And then it calls Saver components' ApplyData() methods. It waits until the end of the frame to allow GameObjects in the scene to finish up their own initialization first if "Frames To Wait Before Apply Data" is 0.
Re: SaveSystem Execution Order
Posted: Tue Mar 01, 2022 2:27 pm
by VoodooDetective
Part 1
OK great! That's easy.
Part 2
I think I figured this out. There are two things happening that are causing problems for me. I think one of them might be a bug, or just an under-documented feature of Unity.
--==Issue 1==--
I've started loading scenes using Addressables. To do that, I had to edit SaveSystem to use Addressables.LoadSceneAsync(). This method takes an optional parameter called "priority". It's default value is 100 (which I didn't know). If you keep the priority at 100, it disrupts script execution order completely. I have no idea why. I'm going to file a bug and see if it's a bug.
--==Issue 2==--
Even after I set priority to "0", I was still having trouble.
SaveSystem.LoadSceneCoroutine(SavedGameData savedGameData, string spawnpointName)
Uses:
Code: Select all
yield return new WaitForEndOfFrame();
My understanding, and my experience everywhere else outside of this scene loading context using addressables, WaitForEndOfFrame wares off after the first frame it's used on. But for some reason, with these coroutines that exist between scenes and make use of the addressables scene loading methods, WaitForEndOfFrame never stops working. Everything after that point runs at the end of the frame no matter how many yield return nulls I put in.
Fixing the priority and commenting out the WaitForEndOfFrame fixed the issue. I'm mystified. I'll post here if I find out either of these issues is a bug in Unity.
Re: SaveSystem Execution Order
Posted: Tue Mar 01, 2022 2:40 pm
by Tony Li
Thanks for the info.
I'll need to look into supporting Addressables.LoadSceneAsync() in the future if you can't already do it by making a subclass of SaveSystem.
The only gotcha with yield return WaitForEndOfFrame() I'm aware of is if you're playing in the editor and the Game view isn't currently visible. In this case, the Game view doesn't update, so it never finishes a frame, and WaitForEndOfFrame() waits forever.
Re: SaveSystem Execution Order
Posted: Tue Mar 01, 2022 2:53 pm
by VoodooDetective
Actually, I've been experimenting more and I think no matter what, if you load the new scene with addressables, anything in that scene ends up running before other coroutines regardless of script execution order...
Sorry for the confusion. I think this has to be a bug of some sort? Anyway, I think what I said about WaitForEndOfFrame is incorrect. The priority parameter doesn't seem to matter either. It really is Addressables.
OK! So I'll post any answers I find.
RE: Using Addressables and Subclassing:
I also wanted to have EnterScene() run after save state was loaded so that's one other reason I decided to modify SaveSystem directly. But addressable scene loading might still be a cool feature (despite how tricky Addressables can be).