Is it possible to have fields that are only available at build time or specific platforms, without getting spammed with warnings that the serialization layout is different when the app starts?
Simple use case:
#if UNITY_EDITOR
[Multiline]
[SerializeField] string developerDescription;
#endif
Is there any specific reason not to keep the string in builds? SerializeField makes no difference at all once the game is built, which means the private field will be invisible to other scripts unless reflection is used. I really dislike relying on Platform Dependent Compilation too much anyways- mostly because if and when you go to move this script into a standalone assembly instead, it will no longer function properly.
Instead, there are a few alternatives, like assigning a unique ID to your GameObject and saving/loading this data from EditorPrefs in a custom inspector based on that ID. This is useful for information that you want to tie to a specific GameObject, but don’t want to be included in builds or create any weird conflicts anywhere. The ID itself would need to be on a MonoBehaviour somewhere, and would itself be included in builds, but that’s a tiny annoyance. As a slight variation, you can make your own ScriptableObject purely for storing this editor-only kind of data locally, instead of needing to use EditorPrefs. By putting it in Editor Default Resources, giving it a static interface, and allowing it to self-load when referenced statically, you can make it just as accessible and usable as EditorPrefs, but designed exactly to your needs. I do this in my projects.
Alternatively, you can make a MonoBehaviour in an Editor directory or an Editor-Only assembly. It’s not possible to add that MonoBehaviour to a GameObject using the typical Add Component button method, but you can do it with a MenuItem easily enough, or with a context menu option. These components won’t be included in builds- there’s a possibility they may leave a null reference in the component list, but unless you’re iterating over all components on a GameObject for some reason I can’t imagine this being an issue. If you like, you can do a iProcessScene script that checks each GO for null component references and removes them, but I’m not sure it’s necessary- Unity probably already does it for you and I’ve never run into an issue.
I’d like to hook into that question. I have the need to avoid layout warnings about a serialized field that needs to be available on UWP, but not on Android. Fact is, I can’t just keep it, because the namespace the type comes from is not available on Android devices
Have you fins solution for this ???
Optional serialized fields actually seem to be supported now.
I have no idea exactly when it changed, but since at least Unity 2019 I’ve been able to put #ifs around fields without getting the layout warnings and the quick testing I did ages ago found that stuffing a large amount of data in such a field seemed to exclude it from the build file size as expected.
One place it doesn’t work is pre-compiled DLLs. I have quite a few of them in my plugins where I have one DLL for the Unity Editor and another for Runtime Builds and I still get the layout warnings if I try to #if a serialized field between them.