Script behaviour has a different serialization layout when loading [Resolved]

Gidday everyone,

I've just begun moving a project into WebGL and have a bit of a game-breaker that seems to be bringing things to their knees. While the project itself does run fine on everything from iOS through to Linux I'm getting a really strange error and pitifully little supporting information.

A script behaviour has a different serialization layout when loading. (Read 60 bytes but expected 260 bytes)
Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?

Can anyone please give me a hint as to what could be wrong here. We don't use #ifdef UNITY_EDITOR anywhere in the project, and I've been systematically pulling things out but it's just taking me too long so I figured it best to ask.

Thank you so much!

 

does it mention which script it is? or can it be inferred from the context of when this happens ?

 

It's an error the comes up when the programme has just finished loading, and doesn't give me any more information than that. At least the error reporting is better than Apples I suppose

 

That was the third thing I checked actually. We're pulling a few other errors at the moment if that'd help to diagnose the issue:
run() called, but dependencies remain, so not running
pre-main prep time: 419 ms
Calling stub instead of signal()

I'm picking through the project slowly. As per usual all help is appreciated!

EDIT: I decided to give the latest beta a crack and it's giving me a bit more feedback in the console, as is now only throwing the errors:
pre-main prep time: 246 ms
A script behaviour has a different serialization layout when loading. (Read 60 bytes but expected 260 bytes)
Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?

 

The same is happening for me. The app relies on a local web server before it can start up, but I don't think it's getting to that point. I'm going to file a bug and hope for the best.

 

After hours of searching and narrowing issues down I managed to isolate the CS script that was apparently pulling the error - it was the main script that we'd made to handle our downloads from various locations (similar I'd guess to your code akeplinger) and had a lot of switch cases for changing paths according to platform (of which we deploy on everything except for consoles) it also makes use of files and classes present in the plugins folder. I separated the file from the project with the intent to submit a test case however cannot seem reproduce the issue outside of a very large project.

Still get the pre-main prep time error even with a fresh project and empty scene however. I assume this is just a notification?

Is there any way to build to WebGL without obfuscation as it'd be easer for tracking issues through complex projects

 

Right. Just reporting back that I knocked the bastard off. It was the result of having two script files with the same name within the project despite being in different locations and referenced through different parts. Yes it's poor programming but:

[backstory] I took this project over from someone who left our company. He programmes in very modern ways that just isn't my style as I'm a very straight forward and simple kinda person [/backstory]

Anyway there were two copies of the file: FileLoadManager.cs in the projects. One in the plugins directory being used by a sophisticated loading system, and another in the main branch that was in use by the more moderate systems. There was also a text file copy of this file (who knows why) lying around in the plugins directory also. I combined the files to one and whacked the text version and on compile that seemed to resolve the A script behaviour has a different serialization error.

I really do apologise for the time wasted here, but do hope that this might help someone in future if the same issue arises for them.

 

Ran into this issue today, it was 'Data Caching', clearing the browser cache cleared up the immediate issue and let me get back to the other problems with webgl. heh.

(Shift+Reload wasn't good enough.)

 

Thanks for that addition!

Given that we're still developing this project I'll keep an eye open to make sure that it doesn't happen. Although that doesn't help the poor user were it to happen to them.

Go figure.