godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.08k stars 69 forks source link

Allow connecting of `GraphEdit` nodes from the editor #9544

Open ivakam opened 2 months ago

ivakam commented 2 months ago

Describe the project you are working on

A game featuring extensive note-taking (powered by GraphEdit) tools for the player.

Describe the problem or limitation you are having in your project

There is currently no way to connect GraphNode nodes from the editor. This makes things rough for me since I would like to use "premade" graphs for things like tutorials, non-player created content, etc.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Allowing the connecting of graphs from the editor (and to be saved as part of a scene) would allow me to use graphs for non-player created content in my game. In short, it would entirely solve that particular problem.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

This is tough since connections are many-to-many for a given node, needing both the slot and node for the source and destination. Internally, a connection is a refcounted struct, and while I'm not sure it seems to me that the sensible solution would be to expose the connections as either a node or resource. If it's a resource, the GraphEdit would export a list of GraphConnection resources, and if it's a node, you would simply add them as children of the GraphEdit and they would in turn export node paths for the source/destination nodes, and ints for the slots.

However, if there is a simpler solution that just involves exporting a dictionary of strings or something to the GraphEdit without exposing the internal Connection struct, that would probably be easiest for now.

If this enhancement will not be used often, can it be worked around with a few lines of script?

Currently the only real way of working around this is to do something horrible like giving your GraphNodes unique names and then connecting them up manually on node ready. This obviously sucks, not only because it's fiddly, but it also doesn't let you see how the connections look without running the project.

Is there a reason why this should be core and not an add-on in the asset library?

Since this deals with existing nodes and existing functionality, it would not really make sense to use an add-on to expose what already exists, but is internal to the engine.

Calinou commented 2 months ago

but it also doesn't let you see how the connections look without running the project.

Shouldn't this work with a @tool script?

ivakam commented 2 months ago

I was able to find a sort of workable solution by having the graph nodes export a Dictionary<GraphNode, Array<Vector2I>>, with the key being the destination node and the vector containing the source/destination ports respectively. It's still quite cumbersome due to how fiddly exported dictionaries are, but that's a separate issue.

I was, however, not able to get it working with a tool script. It's also a bit cumbersome since it puts me in the position of having to manage a tool script on top of whatever my graph is already doing, with all the caveats that come with that.