Putting Combat in order

[Max mtg]

The 22261 revision changes how Combat works in game.

1. The instance of Combat (acquired from game.getCombat()) exists only during combat phase and only if attackers were declared. No more Combat instances are created or reset during untap step. If there's no combat or no attackers, noone gets priority during combat phase. So acutaully if any player has priority between declare attackers and end combat, the Combat does not need to be checked for null.

2. Card class no longer has methods like isAttacking(). Although it sounds natural from the perspective of language that card is attacking, but this is really a property of combat. There may exist several combat instances (like different options to declare attackers and blockers) tested by AI, so tests for cards should be performed against a certain combat instance.

3. ComputerUtilBlock class was a complete mess - in a sense it consisted of all static methods and fields and pretended to create new Combat instance. Firstly for several games run at a time such static fields are completelly unacceptable. Multiple AIs might access the fields at a same time that would lead to problems.
So this class is now known as AiBlockController, and its method getBlockers alters a provided Combat instance to assign blockers. There still remains a task to assign blockers for other player (who has been mindslaved or has let Odric with 3 fellows attack), but this does not seem to be a high-priority one.

4. Combat class is initialized with player who is to attack. All possible defenders are set up in class constructor. All those initDefenders no longer needed. The named class contained a lot of redundant maps, like card-to-band, AttackingBand held defender and blockers for unknown purpose. They all were removed for being duplicate fields of information avaliable elsewhere not to confuse other developers. The mentioned 'card-to-attackingBand' map had been originally intended as an index to locate bands faster - so it potentially can be restored (but has to be marked as an auxiliary index)


I have updated many dependent classes, so do not hesistate to report any problems related to combat.
The validation of blocker assignments according to rule 509 seems to work fine without changes.

[friarsol]

I don't believe AttackingBand.isBlocked() works correctly anymore before blockers have been declared (which is why I was using a nullable boolean)

[Max mtg]

I don't believe AttackingBand.isBlocked() works correctly anymore before blockers have been declared (which is why I was using a nullable boolean)

Report specific problems, please, with steps to reproduce and a few words on how game behaviour is different from an expected result.

[friarsol]

I don't believe AttackingBand.isBlocked() works correctly anymore before blockers have been declared (which is why I was using a nullable boolean)

Report specific problems, please, with steps to reproduce and a few words on how game behaviour is different from an expected result.

Since the blocked variable is being set to False, instead of null as it was just a few days ago, cards that interact with being unblocked are incorrect before blockers are actually declared.

1. Attack with any creature
2. Before declaring blockers, activate a creature with Ninjutsu (like Mistblade Shinobi) choosing your "unblocked" attacker
3. That's it, there isn't really much of a repro here.

[Max mtg]

Thanks for details. Now I know exactly what to do. Taken some measures in r22275.