Godot: GraphNode lack of flexibility

[groud]

Hi everyone,

I am currently working on a new editor feature to create Finite State Machines. I started on designing the editor using GraphEdit and GraphNode classes. Those are great, but were initialy designed to handle "port-based" application.
In my case, I have no interest in using ports, but rather create transitions between nodes. Also I wanted to be able to modify the title bar to add the possibility to edit the node name (with a double click), which is not possible with the current implementation.

I wanted to suggest a new design for graph nodes that would split the graph nodes functionnalities into multiple parts:

• The GraphNode class becomes a generic container which only handles generic functions such as: resizability, offset on the graph...

Then two possibilities:

• We create a GraphNodePort class inheriting from GraphNode that implements all missing features.

or

• We create a PortContainer class that just extends the Container class with a set of displayed ports.
• We create a GraphNodePort class that includes this PortContainer class along with an HBoxContainer to create a top title / tool bar (or we built in from scratch into each editor depending on each specific needs).

I think the last solution is cleaner, as it truely split the functionalities and allow a very flexible design of graph nodes.

I could work on that but I would like to have more opinions about it.
What do you think ?

[n-pigeon]

I think it's good idea to update GraphNode. It will make it applicable for bigger variety of tools.

@kubecz3k Ping? :)

[eon-s]

Yes, I was thinking too that GraphNode could be a lot more flexible to allow different visual implementations (for games and editor).

[toger5]

More flexible graph nodes would be great. Blender moves a lot of settings into graph nodes. So having a similar really powerful and flexible graph editor is great since it becomes almost a standard tool for graphics/3d/games.

[kubecz3k]

I don't have any strong opinion about GraphNode. But if you are developing FSM module for Godot with contribution to the main sources in mind, please ensure first this is a desirable feature. We can't just accept big feature contributions without depth consideration, since we are those who will need to maintain this code for years. That's main reason why we are working on on Asset Store and plug-in system, to allow people to contribute features that can be maintained by the community - outside the main sources.

[groud]

Well, I can't remember when I found this (which may be only feature proposals, I don't know), but it includes "transition graphs", which are basically FSM extended with transitions that take time to execute.
So I guess if it is planned for 3.1, I can start to work on it right now. :)

Anyway, this is not the issue to talk about it, let us use #8847 instead.

[puppetmaster-]

My game also would love to have a more flexible GraphEdit and GraphNode. They have so mutch potential for cool ingame gui elements.

[kubecz3k]

@groud I assume the issue is still valid?

[groud]

Yes :)

[mateusfccp]

How is it going? Any decision about if it will be implemented or not? I like the idea.