TileMap Layers 2.0 - Enhancements

[Gurigraphics]

Describe the project you are working on

Improves the organization of any project that uses Tilemap

Describe the problem or limitation you are having in your project

Current layer organization and usage

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

The problem -> Layers should be treated as much more relevant elements. And not as only Tilemap configuration.

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

The improvement -> Layers can be Nodes

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

It is possible to use several Tilemaps as layers, as many do.
However, this is bad practice. It is better to use what is simpler and more suitable.

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

It is essential because it directly affects the quality of the project organization.
The current organization leaves something to be desired.
It's not practical to deal with "multiples open configuration lists infinite scrollbars".
Much better each configuration in its proper folder, node or group.
The possibility of grouping layers also is not possible in this old system.

[KoBeWi]

Layers were introduced with the purpose of not having to deal with multiple nodes. Working with multiple layers is a breeze now, because you can switch between them very conveniently. Which wouldn't be possible with multiple nodes.

[Gurigraphics]

1. Selecting nodes is much better
   Selecting a node is much more practical. Just click once.
   In the traditional way, you have to click on the central menu and then click again to select the option.
   You need to do this several times and several times. Unnecessary work.

2. Nodes can be grouped
   The more complex the game, the better it is to group the layers into different groups to organize the project.
   For example: flowers types, trees types, npcs types, collisions types, etc.
   In the traditional way the developer is limited to a single stack of layers

3. Nodes offer greater possibilities for expansions
   When selecting a node, on the right the inspector displays the Node's settings.
   Traditionally the settings are limited. And the more there are, the more everything is crowded and difficult to work with.

4. Code reuse.
   Nodes can be combined and shared between different Tilemaps and projects.
   In the traditional way, the settings are limited to that single Tilemap.

It's a natural way for Layers to become Nodes. I just suggested it ahead of time maybe.

[KoBeWi]

Selecting a node is much more practical. Just click once.

No, clicking is not practical at all. When editing maps, the less your cursor is outside gameplay area the more effective you are. Hence I almost never use the layer dropdown, only the shortcuts. (the same applies to selecting tiles and it's why good picking function is important)

For example: flowers types, trees types, npcs types, collisions types, etc.

idk, IMO the only distinction you need is between background and action layers. Flowers and trees can be on the same layer, if they don't overlap.
But I agree that ability to group layers would be convenient.

Traditionally the settings are limited. And the more there are, the more everything is crowded and difficult to work with.

Layers don't really have that many properties and they can always be organized better within the same inspector.

Nodes can be combined and shared between different Tilemaps and projects.

Well this is supported right now. You can copy a TileMap to another scene and delete layers you don't need. But yeah, copying layers between existing TileMaps is not possible. It could be implemented in the current system though.

I think the proposal is ok overall, as long as we have some way to switch between layers with a shortcut. The problem is that layers are just an internal data of TileMap. They can't be moved to nodes. The nodes would have to act as a "proxy" that expose properties of the main node. I think this might be possible with a custom addon.
IIRC the option to support editing groups of tilemaps was discussed before the TileMap rework, but it would make the implementation much more complex, so the current layer system was implemented instead.

[Gurigraphics]

The problem is that layers are just an internal data of TileMap. They can't be moved to nodes. The nodes would have to act as a "proxy" that expose properties of the main node. I think this might be possible with a custom addon.

You can do the opposite. Move Tilemap data to Layer. So the Layer accesses the Tilemap data. A Layer can be treated as a "visual database" that stores the position of tiles and objects. However, the data can continue to be stored in the same place as before, in Tilemap. It just won't be noticed visually, like it never needed to be. When creating the Node Layer it can be automatically associated with the selected Tilemap. Or rather, a Layer Node is a type of Node that only fits in a Node Tilemap. Unable to move this Node to one that doesn't have a Tilemap as Parent.

No, clicking is not practical at all. When editing maps, the less your cursor is outside gameplay area the more effective you are.

Clicking on that central menu is more bureaucratic. In terms of usability, I think Nodes are more convenient. After all, practically everything in Godot uses Nodes and no one complains that it is not practical to use.

In terms of implementation, it is certainly possible to improve what has already been done without having to create the Nodes. In that case, it would look like Photoshop handles layers. The ability to drag in drop, group into folders and hide group of layers. Or tabs between layer groups.

However, Nodes present greater flexibility, greater complexity of composition and at the same time simplifies the design.

[Zireael07]

Or rather, a Layer Node is a type of Node that only fits in a Node Tilemap. Unable to move this Node to one that doesn't have a Tilemap as Parent.

That sounds more like resource than node, tbh

[Gurigraphics]

That sounds more like resource than node, tbh

Resource is something used. This looks more like a class extension.