add signal for when contents of cell are changed

[iatenine]

Rebased version of old PR to add signal emitted when grid map cells change

Bugsquad edit: Fixes #11855.

[aaronfranke]

@iatenine For future reference, you absolutely can rebase without creating a new PR, you just needed to force-push.

@akien-mga This change is pretty simple and has been waiting a long time in #34475, probably best to just merge this right away once the CI checks finish.

[akien-mga]

There's also #33832 for the same feature.

But I'm not clear on the use case - when can GridMap cells change without the developer knowing it? Signals in Godot are meant to notify of changes that happened automatically so that the developer can react to them, but in this case changing the contents of a cell is (AFAIK) something that the developer would do themselves, and they can thus react to their own change directly (or emit a signal when changing cells).

TileMap doesn't seem to have this kind of signal either.

[iatenine]

Signals in Godot are meant to notify of changes that happened automatically so that the developer can react to them

Guess I never realized the pattern for built-in signals and always thought of them more as shortcuts for things I could (but would rather not) code by hand and, as Aaron mentioned, this is a pretty old PR so I don't fully recall my thought process at the time

Still, if I'm not the only one asking for the feature, surely there's a discussion to be had about balancing requested features and avoiding bloat

I await the council's decision and will close the PR if appropriate

[aaronfranke]

@akien-mga I thought signals were general-purpose tools for communicating around the scene tree?

For example, here is a chart from @TheDuriel showing the way he recommends communicating between nodes:

If this chart is to be followed, a signal that could be connected to notify a parent node would make sense.

[akien-mga]

@aaronfranke Sure, but that's why you can emit your own signal when you modify the GridMap yourself:

func change_tile(pos, cell_id):
     set_cell_item(pos.x, pos.y, pos.z, cell_id)
     emit_signal("cell_changed", pos, cell_id)

Built-in signals are meant to be emitted to notify you of relevant events that happen without you having triggered them directly. If you call set_name("New Name"), we won't emit node_changed_name as you did this change yourself, so this signal would be clutter (and we would then add signals for every action that can impact a node, i.e. any method in the API).
On the other hand, if you add a node to the scene, the signal ready will be emitted when the node is ready (which is not synchronous with your addition of the node in the scene, so it makes sense to have a builtin signal that you can connect to - you wouldn't have a way to emit it yourself as this happens several CPU cycles later).

[WatchThemFall]

I agree there should be a signal for this for editor tools, but it also needs the gridmap object being changed (like how the tween signals work) and new item to be passd for it to be useful. As I've done here: #33832 It is rather useless if the gridmap being changed isn't sent along with the cell information. Having the gridmap in question passed in the signal allows a single script to work on multiple copies of the gripmap. (I am using gridmaps to create pushable blocks of multiple shapes in a project). Having the new item ID allows you to set 1 specific item ID to be the "auto" block so it does not get stuck in an infinite loop of changing itself AND allows you to have items that are NOT changed with you place them.

Making any kind of complex gridmap without a signal like this takes forever. For example, in my project I have over a 21 blocks that all need specific rotations depending on which blocks they are surrounded by. This signal allows automatic change of the item and rotation depending on the situation.

Example: https://imgur.com/a/nyHrH0N

Also, this implementation doesn't trigger when a cell is erased which is also needed.

[iatenine]

I'm willing to accept #33832 as the superior implementation. Closing this PR