To later simplify some things for my current project I am first creating a custom EditorWindow tool. Since I want to be able to save its current state (to make it survive entering/leaving play-mode or restarting Unity without always resetting) I have created a settings-object that gets saved and is supposed to hold all the data.
However, it seems that my current implementation results in the warning “Serialization depth limit 7 exceeded”. The data structure looks like this: (Hierarchy on the left for inheritance, arrows for references to instances of a type)
Basically when opening the TilesetEditor it loads the TilesetEditorSettings object. In there is a list of 1-n TilesetEditorPanels which each have their own few references to some PanelElements (e.g. Grid, Texture, Zoom). Since some PanelEements need to access data from other elements (e.g. Texture needs to be scaled according to Zoom) they have a reference to their containing Panel (lower upward-travelling arrow). Also it will later be necessary to acess other Panels (e.g. to check if a drag started in a different Panel than the one it ended in) which is why there is a referene to the TilesetEditor in order to get to the Settings (upper upward-travelling arrow).
From my understanding of the serializaton manual page those upward-travelling references are the problem, since they lead to endless loops when deserializing (which then get interrupted by the warning).
The question is how to best resolve this.
I suppose one way would be to derive my TilesetEditorElement class from ScriptableObject as well, since apparently references to those types can be resolved properly. The downsize though would be that apart from the Settings object I’d also need to save all objects which then derive from TilesetEditorElement into an Assets folder, which could get a bit messy. Also it means that I couldnt use a normal constructor with parameters anymore so I’d need to use the ScriptableObject.Instantiate method and a custom Init method to set up the parameters.
Or is there maybe a better approach?