Restore lost ability to rotate the navigation + physics layers of tilemaps

[halgriffiths]

Describe the project you are working on

A 2D tile-placing game with navigation polygons and collision boxes on each tile.

Describe the problem or limitation you are having in your project

In Godot 3.x, I could create one tile with collisions etc, and then use the rotate keys to make all 4 orientations.
When I hit the rotate button, not only did the texture rotate, but so did all the collision and navigation polygons as well.

In Godot 4.0 the new TileMaps system by @groud is excellent but has regressed and lost this functionality. In Godot 4.0 when you rotate a tile (now done via the Alternative Tiles system), only the texture is rotated and the collision/navigation information is unaffected.

Furthermore, when you create an alternative tile from a pre-existing tile, all collision information is similarly lost, so instead of just pressing a "rotate" button to generate a new tile, I would have to:

• Click "Create alternative tile"
• Rotate the alternative tile using the Flip H/Flip V/Transpose toggles
• Hand-recreate the navigation polygons and rotate them manually
• Hand-recreate the collision polygons and rotate them manually

Not to mention that every time I update the polygons of the original tile I would have to go and manually update the 3 other alternative tiles as well.

This is a significant interuption to my workflow, and it is a shame that this previously very useful feature is disappearing - I sont be able to move my project onto 4.0 unless it is added back.

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

The feature would add two checkbox toggles to the Alternative Tile Editor panel:

• "Inherit Navigation from Parent"
• "Inherit Physics from Parent"

When these checkboxes are enabled, for either the navigation polygons or physics polygons:

• The alternative tile inherits the same navigation + collision layers as the base tile they are derived from
• If the alternative tile is flipped/transpose, the navigation + collision layers are flipped/transposed automatically too.
• If the base tile's polygons are edited, the change is reflected in the alternate tile
• Editing the alternate tile's polygons directly will have no effect

If the checkboxes are disabled (perhaps they could be disabled by default) then behaviour would be unchanged.

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

I have actually already implemented this, in a hacky and ugly way! I am happily using it myself on a custom build of Godot, and am only making this proposal to see if it is worth the effort to go back and clean it up so it can be submitted in a merge-able state.

Some GIFs of it working:

Alternate tiles duplicate existing collision layers on creation

My Implementation

Rotating alternate tiles rotates the collision layers too

My Implementation

Implementation details

The way I implement it is like this:

• Alternative tiles store a pointer to their parent's TileData
• When an alternative tile is flipped/rotate/transposed/changed, the alternative tile:
  • overwrites its navigation layer with a duplicate of its parent's navigation layer
  • rotates its navigation layer using the flip_h, flip_v and transpose bools to set it to the right orientation

There is still work to do, if I want to convert my personal hack into a proper feature:

• Add the checkboxes to enable/disable this behaviour
• Currently only navigation polygons work, I haven't implemented the physics ones yet This is now done!
• Currently updating doesn't happen instantly
• I need to disable the polygon editor window when polygon data is being inherited
• Lots of code cleanup I am sure

Something I am concerned about is timelines - I know that there will be a feature freeze for beta, so I am keen to try and squeeze this in for 4.0 if I can.

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

if this feature is part of a users workflow, they will be using it very often (as I have been)

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

This is an integral part of the TileMaps system which is restoring functionality that already exists in 3.x

[halgriffiths]

My hacky branch can be seen here:
https://github.com/halgriffiths/godot/tree/tilemap-inherit-layerinfo

[halgriffiths]

PS I am sure I remember seeing a discussion on this very long thread: #1769 where other people were requesting this feature, but I just went back and can't find it anymore so maybe I hallucinated it, ha ha

[Mickeon]

Related to #3967 and #5158?

[blipk]

Related to #3967 and #5158?

Hey apologies, I should have searched before posting definately related to #5158.

I wasn't aware of the use of alternative tiles, investigated creating them and changing the physics layers via GDScript, however it seems you can't actually get a reference to the polygon points like you could in v3.4 (or I just havent looked hard enough yet)

Are you able to still work on this @halgriffiths? I'm new to the Godot source but can help with any testing that needs to be done.

This branch looks great and would definately be very useful to have this in before the 4.0 beta.

[halgriffiths]

I wasn't aware of the use of alternative tiles, investigated creating them and changing the physics layers via GDScript, however it seems you can't actually get a reference to the polygon points like you could in v3.4 (or I just havent looked hard enough yet)

Yeah, thats correct. The way I do it instead is I get a reference to the parent TileData, and then duplicate the parent's polygon points. In theory this is inefficient, but since TileSet editing would (presumably) be done in-editor and not during runtime, it seemed to me like an acceptable cost to pay.

Its a bit hard to navigate my branch coz I haven't made a PR yet (waiting for maintainer feedback on this proposal), but if you are curious, then this update_inherited_polygons() step is where I duplicate (and flip/transpose) the parent's polygons:

scene/resources/tile_set.cpp

[blipk]

If anyone can't easily build the modified branch, and this doesn't make it into the 4.0 beta, I've written a routine to automatically create transformed alternative tiles along with their physics layers via GDScript:
https://gist.github.com/blipk/1a70249a0277c5e516b1f6000955fac9

Attach the script to your TileSet either in the editor or in your TileMap script:

extends TileMap
func _ready():
	# tile_set.set_script("res://world/tilemaps/TileSet.gd")
	tile_set.tilemap = self
	tile_set._ready()

This will save a copy of your tileset with the alternatives to a new .tres file.
Thanks for the work @halgriffiths has done in CPP to help me understand the TileData.

The problem with this is it creates quite a lot of alternative tiles:

This makes me wonder if transform functionality might be better built in as a flag when placing tile on the TileMap and exposed to the relevant functions as well.

I think the comment by @KingBrainlord in related #3967 is worth quoting here:

Its nice the new system integrates tilesets and tilemaps closely, but it confuses their roles. Tilesets represent the semantics of what a tile is while tilemaps control where and how they're placed and rendered. Flips, transposition, modulation, and z-index concern the latter. Moving the alternatives properties to tilemaps will give the user finer control without needlessly creating new objects.

I've been thinking I'd like to have very gradual, subtle, color shifts in all my tilemaps using modulate, for instance. That would require hundreds, even thousands of tilemap alternatives - or it could just be painting onto the tilemap.

Could we get some feedback from the maintainers of the new TileMap/Set implementations and what their thoughts on restoring this functionality is? @Calinou ?

[Calinou]

Could we get some feedback from the maintainers of the new TileMap/Set implementations and what their thoughts on restoring this functionality is? @Calinou ?

@groud implemented the new TileSet and TileMap editor. I haven't worked on anything TileMap-related on either 3.x or 4.0.

[Calinou]

Per-tile rotation effectively solves the issue reported here and was implemented in 4.2, closing.