Search Issue Tracker
Fixed
Votes
0
Found in [Package]
1.4.7
Issue ID
UVSB-806
Regression
No
Macro assignments and object variables reset on object instantiation
[Original Issue|https://support.ludiq.io/communities/5/topics/2258-runtime-scene-loading-causes-deserialization-failure]
----
<p>Using Bolt 1.4.0f7 and Unity 2018.1.9f1</p><p>When instantiating a clone of a prefab into a scene all Bolt components get reset to an empty state. Object variables are reset and any assigned macros are removed. This only seems to happen if an object is spawned right at the start of a scene being loaded. </p><p>So when I load a level, all of the players that get spawned into a level at start have no macros. However, if I set a player directly in a level and hit play the player will be fine and I can spawn things during runtime and they'll still have their macros (firing bullets, etc). </p><p>This ONLY happens in the editor, it does not happen in a build.</p>
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Crash on when D3D12RenderPass::SetupDeviceResources when opening FBX animation preview
- Serialization errors are thrown when "com.unity.render-pipelines.core" is added as a custom package and Graphics window is opened
- Character Joints unexpectedly rotate when a ragdoll is created using the Ragdoll Wizard
- Crash on GfxDeviceD3D11Base::DrawBuffersBatchMode when rendering the Scene view
- The shared EditorBuildSettings.asset file of symlinked projects is not updated when changing the order of the Scenes in Build Settings in one of the projects
Resolution Note:
Lazlo Bonin (Lead Developer)
×
Lazlo Bonin (Lead Developer)
483.97• 139• 4,532
2 years ago
So I haven't been able to reproduce it, but I'll be issuing a tentative fix for v.1.4.0f10.
Basically, what seems to happen is that objects are Awake-ing while other objects are getting deserialized. I'm guessing it may have to do with a quirk in Unity multithreading mentioned here:
Beware that the serializer, including these callbacks coming from the serializer, usually do not run on the main thread, so you are very limited in what you can do in terms of invoking Unity API. (Serialization happening as part of loading a scene happens on a loading thread. Serialization happening as part of you invoking Instantiate() from script happens on the main thread).
My fix will attempt to put a mutex on the machines collection to make sure the loading thread doesn't modify it while it's being iterated upon. If all goes well, it should be enough. If there's an unexpected side effect, you might get a deadlock, meaning your game will freeze completely instead of outputting the deserialization failure error you posted.
You'll have to let me know how it goes!
Another note re: loading scenes: it's normal that you have to wait one frame before a scene is loaded. This is by design in Unity. Here's an answer from a UT staff on the forum that confirms it:
The way scene loading work and always have worked in Unity is that it complete in the next frame (Async version maybe even later), so you cannot immediately change the active scene to the new scene it simply not loaded at that point.
The right solution is coroutines or some other way of waiting at least one frame for the loading to complete. LoadScene is guaranteed fo complete in the next frame, LoadSceneAsync has no guarantees about completion time.