Topic was automatically imported from the old Question2Answer platform.
Asked By
shianiawhite
From what I understand about TileMaps and TileSets, the TileSet defines (as it’s children) a bunch of nodes which can be used as tiles. Then in the TileMap, you can easily arrange lots of instances of these nodes. Is there an easy way to have the TileMap return all tile instances which it currently has on the map? That is, the list of nodes that are the tiles, and when you receive that list, you can preform operations with those nodes as though they were just regular nodes? Or are these nodes not easily interacted with as nodes when they are being used as tiles? (I realize moving them independently might cause issues, but other operations I would think should be fine.) Or am I missing something else? Thank you!
You can get the currently used tiles using get_used_cells(), which will tell you what tile is in each used location. With that information you can manipulate the cells, changing tiles, deleting them, detecting certain tile types, etc.
However, you are making an incorrect assumption about TileMaps and TileSets. The tiles are not “nodes”, at least not in the sense you seem to be thinking. A TileSet is a Resource type. It’s a bunch of data defining a texture and attached collision/occluder/nav information linked to a unique id.
The purpose of a TileMap is exactly the opposite of placing a whole bunch of individual nodes. When a TileMap is used, all of the drawing and collisions are batched together to create a single object. For example, when you collide with a TileMap, you don’t collide with a tile; instead there is a single collider for the whole map. This is much more efficient at runtime.
But again, it’s not as straightforward as them all being separate “nodes” and what you can do with them is limited.
I see. The fact that you create them like nodes in the tile set and give them collision the same way you would with other nodes made me believe they were entire nodes like normal. But limiting what they actually are later for efficiency certainly makes sense. Thanks!
