Chunkifying Details
When a Bundle is 'Chunkified' by the Layout/Chunking system the Bundle creates a cache of data in each TileBundle for rapid loading or re-loading of tiles using the TileChangeData
and Tilemap.SetTiles(TileChangeData[] tileChangeDataArray, bool ignoreLockFlags)
.
When the layout system wants to fetch a chunk of tiles to load in this fashion it uses the Bundle's `GetCachedTcd(RectInt locator, out TileChangeData[]? tcd)' method.
For Unity tiles the cached data are directly copied into the output array. The array itself is an instance field of the Bundle.
For TPT tiles, these are new, fresh, clones of the archived, Locked, TPT tile assets which are sub-objects of the Bundle asset.
What this means is that every time that the chunk of tile data are retrieved in this fashion new, fresh TPT tiles are created. Immediately after SetTiles
is used the instance array is cleared.
Why do this??
Since each TPT tilestile is an independent instance, anyonce it's loaded to a Tilemap its internal state changesmay within the TPT tile would actually be saved into the TPT tiles which were cloned from the locked tiles in the Bundle asset.
If the tile has any state variables (fields) which are modifiedchange during the time that a TPT tile is actually loaded onto the Tilemap, what'it's actually affected arein the cached,Tilemap; clonedi.e., tiles.until it's unloaded. Hence, we really don't want to re-used these modified tiles once they're unloaded.
If these were unloaded and re-loaded later then the modified fields will still be modified, which can cause all sort of wierdbizarre errors.errors that would be hard to troubleshoot. Obviously you'd like an unmodified clone of the corresponding locked tile in the Bundle asset.
The end result here is that the TPT instance which gets loaded to the Tilemap has no references anywhere else. That way, when the tile is eventually unloaded it becomes garbage collected properly rather than be a potential memory leak.