Thanks for posting the CA response.

This is illustrative of the smokescreen behavior CA will use to respond to legitimate issues. And also the little arrogant insult: "Since the player has NO clue..." (emphasis mine). Well, duh, if we lift the FOW and can clearly see what the threats are, I think we have quite the clue. How many cases have there been where people have demonstrated the bug by saving a game, playing out a few more turns to watch the AI finish the siege, then reloading that save and watching the AI break it off at end of turn immediately thereafter? The CA staff does us no favors in assuming we have the mental power of a load of rutabagas! It really galls me that CA will make use of the thousands of hours of free beta testing they get on their finished product, then insult the people who provide data on the flaws!

The devil is in the details. Yeah, no doubt the AI assesses threats each turn, and in some cases, legitimately needs to lift the siege for its own good. But loading a save somehow overrides the planned actions the AI had in the previous game session. It's pretty obvious that when the AI builds 5 rams in a siege on wooden walls, it plans to assault the next turn. To have it fail to do that ONLY when the game is loaded from a save is proof of the bug when you consider the example test I cited above. Whether the actual bug is caused by poor assessment, or by a total reset of variables is a problem for CA to figure out, but the presence of broken code is a given.

The key to defining inappropriate activity as a bug is that it has no basis in logic (true in this case), is repeatable for all users with the version in question (true in this case), and that it definitively effects the performance in a negative way (true again).