somethign i found with #if UNITY_EDITOR and serialized properties

Unity Engine
1

this may be face palm obvious to the more acute coders out there…
but! …it took me a while to debug a problem between editor player and standalone player

The problem was my varibles kept returning null or widly whacked out numbers when deployed to a standalone build when compared to the behaviour in the editor
eg) public int foo = 4;
If I wrote this to debug in Update I’d see ‘4’ if I was testing the game in the editor.
But in a standalone build the log file kept reading either nothing (just a callstack with no value) or 7 digit numbers!

In the end, I found it was because I was declaring and initializing some serialized variables inside the UNITY_EDITOR preprocessor.

#if UNITY_EDITOR
public bool showDetailsFoldoutInInspector = true;
#endif

So, the reason for doing this was to have a more persistent editor state. On other engines/editors I’ve worked on, you often want an object to remember all it’s foldout values (especially objects that may have many many foldouts and ‘tree’ style arrangements of properties, such as a SkyEditor) so we thought that declaring them in the monobehaviour object would be fine - discarding them upon Standalone build.

A hint in the standalone log was position - byteStart != info.byteSize which I could assume as it tries to deserialize an object it was expecting data to be there which has been stripped out due to the preprocessor, but was serialized in the Editor!

…so yeh just a heads up if this wasn’t already obvious to others, it wasn’t to me until now :stuck_out_tongue: but makes perfect sense after having to fix it up!

2

Preprocessor conditions are a powerful and potentially dangerous tool. Unfortunately, the easiest place to save that sort of data is definitely on the object itself. Otherwise, you might try serializing that data elsewhere manually, and addressing it via Object.GetInstanceID().