Reply To cazfi
nor does it seem to take any action to handle the situation (namely: there's no reality_check_city() call suggested by update_dumb_city() header)
Well, that should happen already when the tile is first revealed again (unfogged), at map_change_seen().
Seems like debugging needed. I can reproduce this (though it happens only after turn 1000, so it takes some time to run the autogame there)
The root cause was that a player was assumed to be able to see trade partner cities even when that was not enabled. This probably has more serious consequences than the failing check that got us to investigate the thing in the first place.
As player was assumed to see the city, even when they actually didn't know the tile at all, it was added to their player map (FoW map) by some call to refresh_dumb_city(). When the player then really revealed the tile, with the new city on it, the old city was not removed from the player map, as the code assumes that there can't be a know city on unknown tile.
Attached fix adds also an assert to update_dumb_city() to catch future bugs where we try to place city to a player map on a tile which player doesn't know.
This happened on heavily patches master autogame, but the bug seems like something that would be present in the mainline too (at least in master, possibly also in older branches)
Assert 'pdcity->identiry == pcity->id' from update_dumb_city() failed. This was called from refresh_dumb_city() itself called from unit_move(). The update_dumb_city() header specifically says: "If the player_tile already contains a city it must be the same city (avoid problems by always calling reality_check_city() first)"
I see no reason to assume that the city unit_move() reveals is the same as one in the player_tile (city earlier seen on the same tile - possibly then destroyed) nor does it seem to take any action to handle the situation (namely: there's no reality_check_city() call suggested by update_dumb_city() header)