Mandatory targets

[North]

Wouldn't this have been easier by setting mandatory to be default and override it where it isn't? Also, most people just create a target without setting the mandatory flag, when implementing a new card that is.

Maybe not easier (thanks to find and replace) but probably a better solution is to make it required by default.
As you said new cards will be more often implemented correctly then.
Yes we should change it the way you suggested. We have to take care that it works with targets that have 0 to X targets correctly.
I admit, this was just an easy to do fast improvement without any redesign in the target area.

What I don't like in mandatory target is that I cannot cancel spell or ability at the step of target selection if I made a misclick or just changed my mind.

That's correct quercitron, but if the target is set to not required and you cancel, only the target definition is canceled but the spell casting / ability using goes on.
So if I got it right, your demand is more an enhancement to be able to cancel the spell casting / ability using while selecting targets and not first on mana payment (if mana payment is included).

Yeah, it would be great to have possibility to cancel spell or ability (if it's possible) at any step before it becomes cast.

Honestly I don't fully understand what this mandatory field means and how it should be used now, particularly when should we set this field to False. As I see it, if we cast spell or activate ability and cancel target selecting, we cancel the action itself; and for triggered abilities we cannot cancel target selection (or maybe we can cancel, but only for optional abilities). Could you please give some ideas about this mandatory target concept?

[LevelX]

Ok, I thought a bit about this.

I guess the problem I refered to, that can arise if "required" is not set to "true" is mainly (or only?) for triggered, replacement or game state effects (special actions) that need a target decision.
A target decision of a spell cast or ability activation can be canceled and that causes the spell or ability activation to be canceled.
One exception comes to my mind, that is if the target/choice has to be done from a player != controller (e.g. Gifts Ungiven).

So shouldn't it be possible to remove the required flag completely from the target object and show the "Cancel" button depending on two conditions:
1) the ability is a spell ability or activated ability
2) the player acting is the controller of the ability

Text edited a bit.

[North]

I think it is possible. If I remember correctly, I wanted to work on the targeting system because of this issue but I got sidetracked. Now I forgot everything about what I wanted to do. I remember wanting to remove duplicate methods and the required field. The optional part can be implemented inside the engine. At least this is my opinion.

[quercitron]

I've implemented next approach for handling of required status:

1. If target selection has source (ability) then target is not required if:

a. Source is spell or activated ability
b. Target is selected during the spell's casting, not during the spell's resolution. This condition is needed for situation with Gifts Ungiven and many others.

2. If such source doesn't exist (e.g. target for battle actions), standard required field is used.

I didn't remove required flag completely because Target is used not only for abilities, and in those other cases we have to have some way to set this flag explicitly.

[LevelX]

Ok, good you started changing this.

However
mage.player.ai.ComputerPlayer.java
mage.player.ai.SimulatedPlayerMCTS.java
and
org.mage.test.player.RandomPlayer.java
now need some changes too.

[quercitron]

Thanks, didn't consider these projects. I fixed build for them.
Though not sure that using required status make sense for AI players now, will look at this.

[LevelX]

Seems to work so far very well.

I released a new dev version today so we'll proably get some info soon if something won't work.

[LevelX]

ok Scry won't work anymore because you don't have a Cancel button.

[quercitron]

I modified implementation of required status: now if required status is set explicitly, then this value is always used. It helps to control required status when it is needed.
Also changed default required status to True for target without source.
I set required status to False for first scry target, it should fix the problem.

[quercitron]

I'm afraid we can face more issues in complex constructions similar to Scry, and some of them can be quite critical. Unfortunately, the only way I see how to fix them is to find them while playing. Maybe you can suggest some good method how to deal with them?

[LevelX]

I released a new version fix fix for NPE of Target.
Checkout in git if it's ok in your opinion.

This NPE happened in loop.
FATAL [2014-06-15 17:10 [53:066]] GameImpl[pool-2-thread-10]: Game exception
java.lang.NullPointerException
at mage.target.TargetImpl.isRequired(TargetImpl.java:160)
at mage.player.human.HumanPlayer.chooseTarget(HumanPlayer.java:294)
at mage.game.GameImpl.checkStateBasedActions(GameImpl.java:1554)
at mage.game.GameImpl.checkStateAndTriggered(GameImpl.java:1271)
at mage.game.GameImpl.playPriority(GameImpl.java:1047)
at mage.game.turn.Step.priority(Step.java:87)
at mage.game.turn.Phase.playStep(Phase.java:199)
at mage.game.turn.Phase.play(Phase.java:112)
at mage.game.turn.Turn.play(Turn.java:132)
at mage.game.GameImpl.playTurn(GameImpl.java:654)
at mage.game.GameImpl.play(GameImpl.java:620)
at mage.game.GameImpl.start(GameImpl.java:589)
at mage.game.GameImpl.start(GameImpl.java:574)
at mage.server.game.GameWorker.call(GameWorker.java:59)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

[quercitron]

I think your fix is correct, thank you

[LevelX]

A german user wrote about a bug while pile building of Jace, Architect of Thought that is caused by mandatory target changes.

I submitted a fix, but I'm sure there are more cards not fixed yet that use that technique. But I have also no idea how to find them easy.

Fixed bug of Whims of the Fates, Liliana of the Veil, Fact or Fiction, Sphinx of Uthuun, Jace, Architect of Thought, Brilliant Ultimatum and Steam Augury that the player had to move all cards into one pile because the selection for the first pile could not be stopped until all cards are selected.

[Plopman]

Commander mulligan and primeval Titan are bugged. Search in library is never require

[quercitron]

Search in library is never require

Good comment, never thought about this before. What I've found in the rules:

701.15b
If a player is searching a hidden zone for cards with a stated quality, such as a card with a certain card type or color, that player isn’t required to find some or all of those cards even if they’re present in that zone.

701.15d
If a player is searching a hidden zone simply for a quantity of cards, such as “a card” or “three cards,” that player must find that many cards (or as many as possible, if the zone doesn’t contain enough cards).

I've changed search in library according to those rules.