[0.15.33] .set_tiles should clean more entities up

[eradicator]

When using surface.set_tiles(tiles,true) the game does not remove ore/trees from the tiles it corrects internally (i.e. not the ones that were explicitly changed by .set_tiles, but the adjacent ones).

Picture

no_cleanup.jpg (637.89 KiB) Viewed 1614 times

[eradicator]

Erm. If this is "not a bug" then how am i supposed to handle this?

The only method available for tile reading is a one-position-per-call function. This means after changing a chunk of 32x32 tiles i'd then have to call get_tile on the outside of all four edges of the chunk, that's 34*2*4=272 calls _per chunk_ (assuming correct_tiles corrects up to 2 tiles outside of the area of the original set_tiles). And then i'd have to further call find_entities on every single tile that has been changed and then further try to determine if whatever entities i find are allowed on the new tile type (probably via prototype collision mask comparison?).

Given the fact that your already removing entities on the area affected by set_tiles directly it seems odd that i'd need to reimplement that behavior for the tiles affected by correct_tiles.

Edit:
Just to clarify, it's not just weird transitions, the ore is actually on top of the water tiles (==unwalkable, unbuildable).

Picture

waterore.png (235.21 KiB) Viewed 1567 times

[Klonan]

You can use find_entities_filtered{} to cleanup your mess

[eradicator]

Well. Even assuming i was just looking for trees and ore and doodads, i'd still have to call those 272 get_tiles because i don't know which tiles were corrected. Meh :/.

Mh. I looked up the definition for water tiles and they _do_ collide with the resource-layer. So this is clearly ore where it shouldn't be. And as i have no control over what correct_tiles does after my set_tiles call i still think this is your mess