I have a component with a custom inspector. It works correctly in scene mode, detects changes via EditorUtility.BeginChangeCheck and marks my component dirty with EditorUtility.SetDirty.
But when I modify this component in prefab mode neither ‘Save’ button does activate, nor autosave works.
It does work when I modify something else like Transform via standard inspector and it even saves the modified custom data (so the component is really get marked as dirty) but I’m not able to save my prefab when modifying only my component with a custom inspector.
It’s a pity but this behaviour breaks the editing workflow of our project which recently migrated to Unity 2018.3 with the new prefab system.
I’ve filed a bug report with a repro project: 1148906
EditorUtility.SetDirty hasn’t worked properly since multi-scene editing was introduced. You’ll have to mark the corresponding scene dirty.
You do that through EditorSceneMananger.MarkSceneDirty(component.gameObject.scene), and it works both outside and inside the prefab stage.
To this day it baffles me that Unity decided to write up a gigantic warning about it instead of just adding a mark scene dirty call to the method like they should have.
It works this way in 2019.1 now (landed together with asset editing from project view). Calling SetDirty will mark the scene dirty. It seems we forgot to update the documentation page for SetDirty; we’ll get that done.
The problem is that we have a working project (2 years in release) migrated to 2018.3 (which will become LTS, I hope) and it has many of such legacy custom editors. And there was no deprecation warning or something.
I just faced this behaviour experimentally
OK. So what my plan of action now? Should I find all entries of EditorUtility.SetDirty and add EditorSceneMananger.MarkSceneDirty to them or wait until some fixes land into 2018.x branch?
Like Baste said, the behavior is not new in 2018.3; it’s been like this for quite a long time. Of course, Prefab Mode adds some extra cases where it applies as well (before 2019.1).
It’s not clear that anything related to this will land in 2018.3, so yeah, if you need to be on 2018.3 then you should probably do that, as has been the recommended practice for many versions.
