Error - Recursive serialization is not allowed for threaded serialization

Unity Courses Ask
#1

I am attempting to build my game for WebGL and I ran into these two issues… hundreds of errors in my log.

Recursive serialization is not allowed for threaded serialization - files cannot be written during serialization callbacks
UnityEditor.BuildPlayerWindow:BuildPlayerAndRun ()

Unable to write objects to temporary file: Temp/assetCreatePath
UnityEditor.BuildPlayerWindow:BuildPlayerAndRun ()

image
image1061×317 56.9 KB

I finished all four courses and honestly I wish I was building for WebGL continuously to find where in my progress I caused this. I am getting a host of errors and after research it could be due to any of the following

  • Things like “ISerializationCallbackReceiver.OnBeforeSerialize()”
  • Custom classes with System.Serializeable
  • Recursive references (might be from RPG.Dialogue namespace)?
  • Missing use of #if UNITY_EDITOR somewhere
  • Something else entirely

I have my stuff in GitHub source control so I guess I could rollback to various points, but I am a newbie with Git and don’t know what to do to try out old commits without making new ones.

P.S. I have the Gamedev.tv course on Git but haven’t tried it yet - What parts of that course are most relevant for what I want to do.

1 Like
#2

EDIT: I fixed it.
I almost fixed it. I need to run the build process twice and then it seems to work. The first time it produces the errors below. Then it runs.

It points to this chunk of code, namely the CreateAsset line. It’s in an #if UNITY_EDITOR block of code. I will try to set up the render pipeline settings and see if that fixes it. It is weird because to my knowledge I am not using HDRP.

    partial class HDRenderPipelineGlobalSettings : RenderPipelineGlobalSettings
    {
// stuff above
        internal static HDRenderPipelineGlobalSettings Create(string path, HDRenderPipelineGlobalSettings dataSource = null)
        {
            HDRenderPipelineGlobalSettings assetCreated = null;

            //ensure folder tree exist
            CoreUtils.EnsureFolderTreeInAssetFilePath(path);

            //prevent any path conflict
            path = AssetDatabase.GenerateUniqueAssetPath(path);

            //asset creation
            assetCreated = ScriptableObject.CreateInstance<HDRenderPipelineGlobalSettings>();
            assetCreated.name = Path.GetFileName(path);
            AssetDatabase.CreateAsset(assetCreated, path);
            Debug.Assert(assetCreated);

            // copy data from provided source
            if (dataSource != null)
                EditorUtility.CopySerialized(dataSource, assetCreated);

            // ensure resources are here
            assetCreated.EnsureEditorResources(forceReload: true);
            assetCreated.EnsureRuntimeResources(forceReload: true);
            assetCreated.EnsureRayTracingResources(forceReload: true);
            assetCreated.GetOrCreateDefaultVolumeProfile();
            assetCreated.GetOrAssignLookDevVolumeProfile();

            return assetCreated;
        }

#endif // UNITY_EDITOR
}

— ORIGINAL POST —

All those issues (even the Render pipeline issues) went away as soon as I rebuilt it after making the following code change. I made everything inside ISerializationCallbackReceiver.OnBeforeSerialize() look something like this. Not sure if there are exceptions to this rule.

I have a few other unrelated issues, which I will try to debug myself.

       public void OnBeforeSerialize()
        {
#if UNITY_EDITOR
//your code here
#endif
        }
#3

TBH, I don’t think I’ve seen a single WebGL build of the whole project… As the game was targeted towards a PC/Steam environment, there are some other issues… For example, you likely won’t be able to save/restore games, that was a problem with early WebGL, as it doesn’t provide a true long term storage… good for between scenes, rubbish for long term saves.

#4

I found the root cause of the issue thanks to some local help. So I am not using URP/HDRP and confirmed that by following the steps in this Unity document. But I have URP and HDRP in my package manager (they must have been pulled in by some asset store package). I pulled them out of package manager and now I have it building fine consistently.

I think I have a fix for the saving in WebGL builds. Will post here. I am using WebGL for early prototyping and play testing. So much easier than asking someone to set up steam and download a game. My game is targeted for kids K-8. Long term it will be a app on app stores, targeted for tablets. But I don’t have a mac so I can’t build to an ipad for testing otherwise I’d go straight to using something like Test Flight.

#5

On local saves I found this. My prior experience is in SaaS (not engineer) so I know today’s browsers have persistent data storage. This forum post seems to confirm that Unity WebGL can access it. 10MB of storage which I think is more than enough. One person is also point folks towards playerprefs.

https://forum.unity.com/threads/save-file-in-localpath-webgl.985157/

The console in the unity editor is also prompting me with this but I can’t find any example code for how to point my persistentdatapath to the browser’s storage. I feel like it’s just a setting away from working!!!

Brian - you should 100% tell me that is out of scope if you feel it is. Or I can just post a different standalone topic and let the community take a stab at it.

saving has no effect. your class ‘unityeditor.webgl.httpservereditorwrapper’ is missing the filepathattribute. use this attribute to specify where to save your scriptablesingleton. only call save() and use this attribute if you want your state to survive between sessions of unity. unityeditor.buildplayerwindow:buildplayerandrun ()

#6

I’d let the community take a stab at it. Everything I’ve seen, though, it only works if the stars are aligned, and the gods are not malign…

Ordinarily, I’d say avoid PlayerPrefs like the plague (in fact, to be absolutely clear, do NOT store a save file in PlayerPrefs on any other platform, including within the Editor. PlayerPrefs are usually stored in the system registry, and are intended for small amounts of data per key.
As it turns out, the PlayerPrefs on a WebGL game are saved to a custom db (when they work), which can be up to 1mb in size…
Of course… using the Json Saving System (you ARE using the Json Saving system, right?), a save file can get much larger than 1mb…

The real problem with WebGL is that it’s sandboxed like crazy. That’s actually sort of a good thing, because it makes it harder for WebGL to do something malicious (sadly, not impossible, pay your local witcher/antivirus vendor).
Android and iOS are also heavily sandboxed, but do provide access to a persistent storage, where we can store save files.

#7

Roger that. I also figured it was not the right place for a save file.

Yes I migrated using your guide BEFORE building to webgl. Thanks again for a great guide!

If it doesn’t work in Webgl that will be tolerable I guess. This is just for early play testing before I can get late model Mac and late model android device to start doing app builds.

I will mark the thread as solved as the fix was to remove URP/HDRP from package manager.

#8

Another option is to leverage the Unity Gaming Service. I’ve been playing around with the Unity’s Cloud Saving in Unity Gaming Service and while it takes a bit of code to get going, it seems pretty robust. As far as I know, it works with WebGL, I haven’t found any info that it doesn’t.
I use the Unity Log In option (misleading, you can use a Unity account (not our accounts for programming, but they have an account system), or Google/AppleID to log in. Once you have an active session token, you should be able to store THAN in PlayerPrefs.

I have a fairly robust login/cloud save setup going in my soon to be released (after the licensing terms are something I won’t mind signing). I need to make it more generic and make a tutorial for it.

1 Like
#9

A sample in action (from an older version of the game, not the current one, but the cloud save is pretty much what’s in my current)

1 Like
#10

Yeah I was thinking the cloud stuff was going to be an option. I am looking forward to seeing your tutorial. I bought some of the other gamedev courses on multiplayer /networking expecting I’d need that later.

As of now I am working on making the game UI more intuitive for a good “out of box experience”, making low poly levels that play nice on low power devices, and just adding more gameplay content.

Alright. I posted a separate thread on Saving & WebGL in here for the community.
https://community.gamedev.tv/tags/intersection/rpg/saving-system/18_SS_RPG

#11

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms