Writing a tilemap's custom data disables Area2D collision for the current frame

[BlueberryGecko]

Tested versions

• Godot_v4.4.1-stable_mono_linux_x86_64
• Godot_v4.5.1-stable_linux.x86_64

System information

Godot v4.5.1.stable.mono - Ubuntu 24.04.3 LTS 24.04 on X11

Issue description

Writing to a tilemap's custom data disables collision with Area2Ds only for the current frame.

In particular, if I write to custom tile data every frame, then:

• An Area2D's on_body_entered signal won't fire at all.
• RigidBody collides, but shows different physics results compared to when I don't do the writing. (a ball colliding with a bouncy tilemap will end up at a different spot)
• A CharacterBody collides correctly, but I assume it would show the same inconsistencies as RigidBody if I were to test more thoroughly

---

In the following video:

1. The script attached to the Tilemap toggles the bool value has_severe_commitment_issues every frame inside _process.

2. This variable is entirely unrelated to anything else in the project, but causes the Area2D (godot icon with angry eyebrows) to pass right through the tilemap. The exception is frame 250, where I skip the write operation via script.
3. I configured the Area2D's callback to destroy all colliding tiles, just to get some noticeable effect. Note that I set physics_quadrant_size to 1 for the project to be able to detect the colliding tile. This is unrelated to this issue.
4. The RigidBody still bounces off, and the CharacterBody (godot icon with friendly eyebrows) still stops.

godot.mp4

---

You can also fiddle with a "random write chance" in the MRP I attached. If you put the writing chance to custom_data to a reasonably high value, but such that it is not written to every single frame, the Area2D will collide from time to time and leave some holes:

Steps to reproduce

• Create tilemap with custom data layer and physics
• connect an Area2D's on_body_entered to do something
• attach a script to the tilemap that writes some value to custom_data every frame.
• The Area2D's signal will never trigger. RigidBodies and probably also character bodies show slightly different physics behavior. (To test, you can set the Tilemap's chanceToWrite to 1 resp. 0 in the MRP and see where the ball ends up.)

Minimal reproduction project (MRP)

custom-data-physics-mrp_2025-11-19.zip

[BlueberryGecko]

By the way this was an absolute hell to track down, because of how custom_data and tilemap collisions seemed like absolutely unrelated topics to me ;) . So if Godot exhibits some magic action at a distance here, I think it could be a good idea to consider contributions that simplify the tilemap code, because this is the kind of weird interaction that shouldn't "just happen".

However, I assume this might be because collision boxes are themselves stored as custom data inside tilemaps...? I didn't have time to look into the tilemap code in detail, but my guess is that writing values to custom_data dirties the collision boxes, so the physics server has to re-add them, and the Area2D doesn't like that somehow? That would make the bug a lot less weird to me.

What might also help in tracking down this issue: If I modify the TileMap's script in the MRP to use _physics_process() instead of _process(), the collision detection works. This is still a pretty nasty bug, obviously, but this might be a good workaround for some users.

[skorpnok]

Following the signal rabbit hole:
TileData::set_custom_data()emits "changed" which eventually ends up in TileMapLayer::_tile_set_changed() where it queues a recompute of everything that depends on the tileset (including all the physics shapes). The physics bodies need to be valid for one frame and synced between threads before intersection callbacks can happen iirc, so they never do unless two physics ticks happen back to back in the MRP (you can trigger this by increasing the game-speed). So this doesn't seem like a bug to me, just not very well documented behaviour. Doing the custom data operation in physics_process seems like a reasonable thing here for now.

Though there is also room for improvement imo. Recomputing all of this data for every custom_data_layer change seems wasteful, so maybe adding a flag to the data_layer on whether changes should mark the entire TileSet dirty and more fine grained dirty rects would be good.

[BlueberryGecko]

Thank you for the research :). That confirms my suspicions.

Imo this is definitely a bug and not a documentation issue. Even if we documented it, we've now promoted a corner case to a "feature", which adds complexity to the code base and to understanding Godot. It also restricts the user to setting custom_data only inside physics_process for games that care about physics.

It sounds like we could resolve the issue by tracking which custom_data layer and tile has changed, when we write custom_data. That should be a good performance improvement anyway, because atm all writes to custom_data interact with the physics server.