How to properly save nested resources edited with custom editors?

[Zylann]

I was almost going to make a proposal, but I think there are still foggy spots in this problem that might need explanations... it also takes a while at this point to explain it, so I'll write it down here.

So I'm making a complex module with custom resources and custom editors. I bumped into an issue where Godot did not save resources that I edited, unless I manually used the floppy button the inspector. In particular, when a built-in or internal object is edited instead of a resource having a file path, and there doesn't seem to be a documented solution.

Note: while I'm working in C++, I consider only what's exposed to me in GDScript and GDExtension, as I wish my project to become an extension (it just can't right now due to other problems, which is another story). Besides this applies to other kinds of non-core plugins anyways.

The problem

Let's consider the following case:

• The open scene contains resource A, referenced by a node.
• Resource A contains Resource B.
• Resource A has a file path. Resource B doesn't, because it's "built-in" into A.
• Resource B gets edited by a custom editor. That custom editor may do changes using EditorUndoRedoManager, in which only resource B appears:

urm.create_action("Change thing")
urm.add_do_method(resource_b, "method1", value1)
urm.add_undo_method(resource_b, "method2", value2)
urm.commit()

• Then right after doing that, the user saves the scene with Ctrl+S and launches the game.
• To great confusion, the user finds out their changes to resource B did not take effect. Godot did not save resource B. It turns out to happen because resource A needs to be saved for this to happen, but as far as UndoRedo goes, no change was done to resource A, so Godot is oblivious of the changes.

This happened to me originally as my resource A contained resource B not as a public property, but as an internal object, which I happened to re-use for making custom resource A, as it was the simplest implementation. But even if resource B was a property of resource A, I have no idea how it would make a difference, as there is still nothing (AFAIK) telling Godot resource B is contained in A when the plugin does changes to B.

And this can be considered with any level of nesting.

Attempted workarounds

UndoRedo dummy method

My first thought was that A should somehow appear in undo/redo actions, since so far I noticed Godot made any resource in UndoRedo be marked as modified and saved. I would then try something like this:

urm.create_action("Change thing")
urm.add_do_method(resource_a, "method_that_does_nothing")
urm.add_undo_method(resource_a, "method_that_does_nothing")
urm.add_do_method(resource_b, "method1", value1)
urm.add_undo_method(resource_b, "method2", value2)
urm.commit()

I successfully used this workaround in other plugins with similar saving issues, as a means to tell Godot "look, I didn't call methods on this object, but I can tell you it has changed, and needs to be saved on the next Ctrl+S".

But this time, in this particular case, it led to more problems, errors like:

UndoRedo history mismatch: expected 0, got 2

Because EditorUndoRedoManager would see two resources with different "auto-deduced" histories in the same action (global and per-scene), so it would not work properly.

Interface object

So for a moment I went crazy and elaborated this ridiculous workaround, still using the UndoRedo method, which amazingly did what I wanted.

_save_external_data

Later I learned about EditorPlugin::_save_external_data, and the last workaround was so ugly I decided to revert it. It was never supposed to be an UndoRedo problem.
Instead, I would make my plugin attempt to find the "parent resource", and save it manually with Resource::save whenever it finds out something changed. This also seemed to work, and was doable because those resources are my own custom classes, it was possible for me to hook them up somewhat.

However it still has issues:

• It causes spurious saves. That approach means I call Resource::save manually. If Godot already decided to save the resource due to other actions, it would save the resource twice when the scene is saved. It could slow things down if the resource is heavy, or cause errors if saving is threaded.
• If the resource is nested a lot more deeply, it becomes increasingly difficult to find out how to tell Godot to save whichever resource holds the file path. AFAIK resources don't have a "get my containers" function. It could also be contained in a resource that's not my own custom (so can't have my own hooks), or even a script.
• An even more concerning issue is: if the user modifies the resource, but then closes the editor intentionally without saving, then the resource will get saved anyways, which means data loss from the user if they havent setup VCS yet... this is because _save_external_data is also called when the editor closes, regardless of the user choosing to save changes or not, and there is no way to find out which case is which inside the method.

So right now I'm back having to use the ridiculously bad workaround involving UndoRedo :(

What do?

That's where I'm at today. I had a few discussions on RocketChat, which so far led to my case being an edge case, lacking known solution. But I'm not so sure of that... nested resources and custom editors can be incredibly common in more advanced projects.

Lastly after looking a bit further, I discovered Object::set_edited and Resource::owners. Neither of them are exposed or documented so I haven't used them yet, but they seem to be used in a few arbitrary places in the engine. I can only suppose that these are ultimately what the engine uses to know what to save on Ctrl+S. Or maybe I should not need to use them directly? What I was doing with UndoRedo initially ended up like a very convoluted way to call resourceA.set_edited(), while the later workaround did almost everything by hand...

I just need to tell Godot "Hey, this resource is now modified and will have to be saved next time the user saves. If it is built-in, figure out how to save its parent resource"... but WITHOUT having to shoehorn that resource into UndoRedo, because it's clearly not working due to how EditorUndoRedoManager works, and it should not be the job of UndoRedo...

I just wonder if I have encountered a bug, or if I should keep doing ad-hoc half-way solutions, or if I'm supposed to do things in a certain way for this situation to work, or if something has to be designed and/or exposed to solve plugin making cases like this?

[devvosaur]

I found this since I noticed the same behaviour with EditorPlugin::_save_external_data() when trying to save external resources for my plugin.
Full disclaimer, I haven't compiled the engine and run it with the debugger, but I used the debugger on the GDExtension plugin to confirm my suspicions.

Looking at the codebase for the current version, this is my reconstruction:
editor_node.cpp: https://github.com/godotengine/godot/blob/655e93d5846b2ef8ebb7d22c8878f51b8f22b312/editor/editor_node.cpp#L1854

editor_data.save_editor_external_data();

during NOTIFICATION_EXIT_TREE, editor_data calls save_external_data() on all plugins (see: https://github.com/godotengine/godot/blob/master/editor/editor_data.cpp#L376 ).

Furthermore, since "Save & Quit" should emit the confirmed signal on the save_confirmation dialog, then EditorNode::_menu_confirm_current() should be called, which in turn should call _menu_option_confirm(current_menu_option, true); where current_menu_option should be FILE_QUIT (see NOTIFICATION_WM_CLOSE_REQUEST). Then the plugin should call save_external_data().
Then the editor is closed via get_tree()->quit(exit_code) (I think via _discard_changes()).

My solution was to check whether the plugin was still in the scene tree or not via is_inside_tree(). If this is not true, the function returns without doing anything.

Attaching the debugger to the plugin, I tested both cases, and:

• when using "Save & Quit", _save_external_data() was called twice: one before and one after the plugin exited the scene tree.
• when using "Don't Save", _save_external_data() is called only once, but the plugin is already outside of the scene tree.

Hope this may help

[cixil]

Hello, coming from Godot 4.2.2.stable. I'm using a custom plugin to bulk edit custom resources that have "nested" resources (class variables that have custom resource types). I was experiencing a similar issue and was about to post my workaround here, but then I got it working.

Note This is not exactly the same case as OP, when I edit subresource variables, I only save the "parent" resource, which recursively saves all the resources assigned to its variables. I have not tried saving solely the referenced resources from the custom editor plugin. Thought I would post my finding here anyway in case someone comes to this thread with the problem I had had.

In my specific case, I was getting this error when I tried to save Attempted to assign an object into a TypedArray, that does not inherit from 'GDScript'. (Similar error for a typed variable that wasn't an array).
There were no typos or errors caught from the editor in my script but I realized I was misusing the _set and _get methods for a property set in _get_property_list

_get and _set do not work with exported variables in the script, and I only had one internal variable that I set via a different property in _get_property_list, so since there was only one variable it could effect, I thought it was fine to simply return the internal variable without checking the property name:

func _get(property):
	return internal_variable

But _get and _set are used for other Resource class variables and this was changing the expected behavior. Changing the code to this fixed the issue:

func _get(property):
	match property:
		'property_name_1', 'property_name_2':
			return internal_variable

Now I'm able to save custom resources and all their custom-typed internal variables with ResourceSaver