Godot Version
4.6.2
Question
I previously had trouble exporting a project. As documented there, lauching in console mode revealed a new error message and solved the problem. However, I am now suffering from the same problem once more, and despite increasing the memory message queue memory up to 4096, Godot still crashes during the export process, it just takes longer to do so.
Running the engine in console or verbose through the command line provides no aparently relevant information outside of the following error messages:
Failed method: Control(TileGrid)::set. Message queue out of memory. Message queue out of memory. Try increasing 'memory/limits/message_queue/max_size_mb' in project settings.
================================================================
Failed method: CanvasItem::_redraw_callback. Message queue out of memory. Message queue out of memory. Try increasing 'memory/limits/message_queue/max_size_mb' in project settings.
But, as previously mentioned, increasing the memory only makes the process take longer. This seems to suggest an infinite loop of some kind, or a problem necessitating exponential computation resources, but either way I am not sure how to check what the problem is or how to fix it.
The mentioned script (TileGrid) is a @tool and has many @exported properties, if that matters, but runs completely fine in the editor. It seems to be the source of the problem, as it’s allways mentioned in the error message, and the export process actually works (and is quite swift) if that scene and all scenes inheriting from it are excluded.
But, again, I am not sure how to properly identify or solve possible problems with the scene in relation to it’s exports other than systematically stripping it down until it works, and then building it back up again.
I can upload the relevant scenes and their dependencies, but as they are not stripped down it seems like it would be difficult to parse for someone unfamiliar with the rest of the project
Update: the scene in question is actually not functioning properly inside the editor. When running the scene or the game it does work fine, but trying to copy the faulty part for backup causes Godot to crash
This is most likely the issue, but I will update this post with confirmation later
Confirmed. Scene no longer crashes and exports normally
Still combing through the deatils, but making it so the problem script is no longer a @tool worked as a temporary measure. It seems the problem was related to the fact that, for visual clarity, the node in question was creating scenes while inside the editor. The problem might be that they were not saved to disk, but it’s not clear why that would matter considering the way the code is written.
Will mark this as solution, but will still update this with the confirmed solution later
That was not it
Turns out the problem was that a few functions in that class, including a set function, would call_deffered on themselves should is_node_ready() evaluate to false. On runtime, this worked as intended, waiting untilt he node was ready to excecute the function. However, when trying to copy the nodes, as wellas aparently during exporting, this lead to an infinite loop, as the node would never evaluate as ready
An obvious solution is to have those functions simply abort should is_node_ready() evaluate to false, and for ready() to explicitely call them.
Of note is that the set function necessitated this measure as it would pass a set texture to a TextureRect child, but on further reflection a TextureRect child can be simply created on the fly if necessary
On another update, the error messages I was receiving in regard to the non-existent nodes (wich would be created by the @tool script, but not saved to disk) have ended. I was receiving them earlier even after explicitely changing the code to double check if the node still exist, hence my confusion, but it seems that might have been the known issue where the editor needs to be restarted for certain @tool changes to be implemented
1 Like
Likely a last update: the error messages are back. Still loading, copying, and exporting, but the warnings still show up consistently.
Will attempt to save them to memory and see if that fixes it, or simply remove the @tool since the need for instantaneous feedback no longer exists now that the functionality of the nodes has been confirmed.
Either way, will likely not make a new update to this thread.
Thank you for your time!