[SCENE TAB] Scene-Tree Meta Elements

[TCLNA]

Scene-Tree Meta Elements

Proposals aiming to help organize nodes without worrying too much (also you can direcly jump to the PROPOSALS section )

PREAMBLE

Hello everyone 👋! Sorry if my issue is a duplicate, or if it's a little bit over-the-top.

The node system is one of the best advantages of Godot Engine. But the Scene Tab only shows the strict minimum of what the objects are.

A string representing a name that is also the ID of the node. A simple circle for icon most of the time. White = basic node, red = 3d node, green = canvas/2d node...

You see what i mean, and it's great as it is. Or is it ?

This proposition tries to give some tools ideas to improve greatly the Scene tree experience.

Since I'm certainly not the first one to ask for that, i may as well propose multiple little things that i think could improve the editor, or at least give ideas to people. I'm sorry if it's not the way to do, and if you ask me i can make it into separated issues and delete this one.

Describe the project you are working on: I'm working on a simple RPG game that requires a certain amount of nodes - for example the famous Finite State Machine's states.

Describe the problem or limitation you are having in your project: I found myself having too much possible states, and had to break some working code to separate them in different node folders, also limiting my overview of the possible states.

PROPOSALS

Describe the feature / enhancement and how it helps to overcome the problem or limitation: This issue proposes multiple solutions, since i don't know which individual one would go with another, or which one would be more hard to implement.

INDEX:

• COMMENTS NEXT TO NODES NAMES

  Gray comments edited via the inspector.

• VERTICAL NODE CATEGORY

  Node that acts as a folder, but not as a node.

Here is the original image, using sub-nodes to organize the States:

COMMENTS NEXT TO NODES NAMES

Displays a comment text next to the node's name, in italic and with distinct but non-catchy font color (gray maybe). Examples of usages:

• Using the comment as a breaker for categories, not ideal but it does show up well.
  • Put emojis or tags to quickly distinguish items

    Emojis could be added via add-ons / emoji pack files...

• Allow Plugins (such as godot-git-plugin) to display custom informations (such as the commit message / the Author / the modification date).
• Show user-customizable information, such as modification date, kanban/checkbox completion, tags, assignee dev.

Even tho I'm giving three usages, the only one I recomment implementing/using is the 1st one.

The comment could be edited directly in Inspector.

We could also use the proprerties of prohibed name characters (such as '/') to trigger comment edition while renaming a node, or simply double click on the comment if there is already one - even tho those two things may not be instinctive.

VERTICAL NODE CATEGORY

Virtual Category node separator. With distinct icon and font color (gray).

• Categories can be added as new nodes.
• optional: Categories only contain nodes "virtually", meaning they don't indent the tree view.
• Categories can be fold.
• When a category is "fold", it wraps all the nodes below until it bumps into another category (like a fake folder).
• When a "folded" category is moved, it's the same as if every nodes inside it were in a multi-selection state.
• When a "non-folded" category is moved, it acts as a normal node and doesn't drag any "child" nodes with it.

Example where categories doesn't begin at first child.

Note that the design is just a quick drawing I made by fighting with Gimp and it's far from being art.

IMPLEMENTATION

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: Since we're working with scenes, we don't want to store editor-only informations into the scenes files. In theory it is possible to put the categories and the objects comments directly in the .tscn but it will be easier to implement it as it's own thing. So, what we should do is store the meta informations in another file. Of course it could be stored in the import folder, but it can also be stored as a file with it's own distinct extension (like .meta or .gdmeta) that suffixes the scene full name and extension (e.g. World.tscn.meta). If the meta file is in the FileSystem, the meta file should either:

• Have its own icon.

  optional: be in a distinctive color (gray)

• Be hidden inside FileSystem tab.
• Be folded inside the scene object.

The meta file should also be written similarly to the TSCN format, which has the benefit of being simple enough, helps with VCSs, and corresponds to the scene's structure so it's easier for devs to understand (obviously).

The meta file could also be written in TOML, but would not need to use all its features. BTW if someone knows if there's a specific language that inspired the TSCN format please tell me what it is.

JUSTIFICATIONS

If this enhancement will not be used often, can it be worked around with a few lines of script?: It will not be easy to implement, but at least I hope it can be implemented without breaking anything.

Is there a reason why this should be core and not an add-on in the asset library?: This proposal is about features that can be added without changing the core functioning of Godot engine. However, I don't think this can be implemented as an add-on. Also, I think that these features could greatly improve the workflows of game devs.

PS:

Sorry if I'm not going into details for now. I may comment further details later, just tell me if you're interested. Also -i know it'll sound cheesy but- please contact me if you're interested in what I presented and if you can help me understand the godot repo's infrastructure and implement those features. Thank you if you read my mess and tolerated my poor english btw !

[Xrayez]

Since we're working with scenes, we don't want to store editor-only informations into the scenes files.

Regarding displaying comments next to the node's name, did you know about the godotengine/godot#31389 allowing to add descriptions for each of the node inside a scene (3.2)?

That way, I think it would be nice to display these existing comments inline node names, just like you suggest. If the description is too long, it can be shortened with ..., and/or only use the first line of the description text (similarly to commits in git, which are nodes AFAIK, making this feature intuitive for those familiar with git, and probably other VCS's):

This can be made as an editor setting of course.

[TCLNA]

I do now, thanks !

BTW I'm in 3.2 but I didn't saw this feature, maybe I didn't paid attention because it was between the objects properties and the script field, and the script field is already in the treeview.

[willnationsdev]

It sounds to me like everything you want could be accomplished by making a few tweaks to the group system for Nodes.

1. Refine and complete godotengine/godot#24262 to have project-wide group definitions that can be formally recognized by the editor.
   1. Enable users to assign an icon to a project group.
2. Have a toggleable option to display a node's editor-defined groups beside it in greyed-out text.
   • Make it optional and turned off by default because many users are likely to find it too cluttered if they use many groups at once and/or it takes up too much space on their small monitor.
3. Allow users to reorganize the scene dock by group name rather than by tree position (again, toggleable, and off by default).
   1. Have groups with slashes in their name generate sub-branches in these organized lists.

This would resolve all of the issues without introducing a new sorting system and without affecting users who prefer Godot the way it is now. The only downside is that it requires users to define groups for editor organization purposes when they may not necessarily care about or make use of those groups in-game. Still, I believe the cost would be negligible considering the maintenance cost of expanding the editor's features to accommodate editor-only node categories and the like.

Thoughts?

[TCLNA]

Thanks for making me discover this amazing incoming feature ! I like the idea of a global classification with sub-branches defined by the users & plugins.

To add to your idea, maybe have the possibility create a new group by right clicking on a node on the scene dock.

About 3.'s scene dock, maybe this view could be toggled in the scene, such as this example: The only hitch about it is that this layout may confuse people since there is no arborescence on this configuration. So it could be better to have this kind of layout in its own tab. Maybe Add the full tree path instead of the name.

Nodes inside the groups could have sub-nodes shown inside as well.

There is lots of possibilities with your idea, so should this secondary layout focus on an unique display mode that would be enabled via the parameters, or should it be totally customizable ? If so, maybe those options could be in the head button group ?

Sounds really great to me !

[willnationsdev]

There is lots of possibilities with your idea, so should this secondary layout focus on an unique display mode that would be enabled via the parameters, or should it be totally customizable ? If so, maybe those options could be in the head button group ?

1. Definitely not totally customizable. If that's what you want, you can just write your own Scene dock (most of the tools and access methods are there, though some things might be missing/unexposed).

2. What do you mean by "enabled via the parameters"? Which parameters. Either something is in a group or it isn't. If I have two nodes like this:

   • Mario ("entity/player", "character")
   • Goomba ("entity/enemy", "character")

   then I would expect to see a layout like this...

   - Entity
       - Player
           o Mario
       - Enemy
           o Goomba
   - Character
       o Mario
       o Goomba

3. What do you mean by head button group? I was just thinking that there would be some sort of menubutton with filter options above the Tree node in the Scene dock (if there isn't one already).

Edit: oh, did you mean based on the scene dock's parameters and/or the ProjectSettings parameters? I thought you meant something on the filter itself. My bad. And, it wouldn't be something you can parameterize anyway (no value in the project or editor settings). Just something you can toggle directly in the scene dock, locally.

[TCLNA]

To answer 2), I meant the editor settings. And to answer 3) I did mean the top menu on the scene dock. No problem ! I'm still bad at explaining ^^

What I also asked was if it should be an option in the scene menu to have the nodes children in this kind of view (even if they are probably scenes already).

- Entity
  - Player
    v Mario
      > States
      > Items
  - Enemy
    o Goomba
- Character
  > Mario
  o Goomba

Howerver, now that I see how you think it should be implemented, I think it makes more sense to me than the example I made above with node childs if there is already multiple group inheritances possible. (shouldn't it be named tag then ?)

[willnationsdev]

@TCLNA groups are basically tags, yes, although they are generally runtime values whereas other engines might require you to define them up-front statically. Groups can be generated as needed to create ad-hoc groups of nodes, hence the name "groups" used instead of "tags". For example, when you add or remove any Node to/from the SceneTree, it searches up the SceneTree and identifies its closest ancestral Viewport node. It then joins a group that references the Viewport's instance ID. This then enables the Viewport to remotely execute functions, like _input() on every Node within the Viewport without actually needing direct references to any of those nodes. And because nodes move around all the time, they are constantly changing up their would-be tags at runtime. This makes them feel less like tags (some sort of permanent category) and more like groups that shift over time.

You can read more about the process here.

Anyhow, to get back on topic, yes, it would be better to keep the GUI confined to showing nodes and/or instanced scenes under the group branches in the Tree. We might still add an "editable children" flag so that internal nodes can be exposed the same way.

[TCLNA]

Groups do so much more things than I thought. I'll check the further explanations later. I definitely need to learn more about the engine when i have more free time if I want to help with this ! Anyway thanks a lot for the explanations.

[me2beats]

I like ♥️ the idea to have node folders/categories

This would make it possible to arrange the nodes without having to use scenes-just-as-folders or "dummy nodes" for this.

Using additional dummy nodes to group nodes in the scene affects the path of the node and complicates refactoring. I am also sure that there are cases where the use of such dummy nodes is difficult or impossible.

So I am in favor of introducing such a folder / category system in the scene tree editor. I am also for extending the modification of the scene editor using plugins in general. This could make working with scenes more convenient and flexible.

[TCLNA]

Yes, it would be very nice to tingle the explorer via plugins :D

[TCLNA]

Thanks again, i'm closing it for cleanup (and sorry for the ping)