Collectible Card Game Headquarters

KrazyTheFox wrote:For example:
On the field: 1 Graypelt Refuge, 1 Elvish Mystic
Cast: Elvish Mystic
Game taps: Elvish Mystic, leaving 2 types of mana open.

Regardless, I think we can all agree that it's at least a bit better than getting hit for 1 when it's not required.

Seems like a good first step. As this gets tweaked over time, it would be nice for Creatures to be generally lower on the priority (especially manlands, and other creatures that are needed for an upcoming combat).

friarsol wrote:

KrazyTheFox wrote:For example:
On the field: 1 Graypelt Refuge, 1 Elvish Mystic
Cast: Elvish Mystic
Game taps: Elvish Mystic, leaving 2 types of mana open.

Regardless, I think we can all agree that it's at least a bit better than getting hit for 1 when it's not required.

Seems like a good first step. As this gets tweaked over time, it would be nice for Creatures to be generally lower on the priority (especially manlands, and other creatures that are needed for an upcoming combat).

Right now creatures are lower priority when put against things like basic lands. In the above instance if there were a forest on the battlefield, it would tap the forest instead. I'd like to eventually have it look at the player's hand and figure out what can be played and how to leave enough mana open to play the most things (or something along those lines). With the Graypelt Refuge bit above, since I don't know what's in the player's hand, I figure it'd be better to leave the options of both green and white mana open (should this be changed?).

Good job on the initial changes, this should at the very least make the mana managed better for the AI so that it can get more stuff out and cast more spells (and hopefully not as frustrating for the human's "auto" tapping as well, at least as long as the human attacks with all the creatures before casting spells, 'cause in some corner cases like 2 Bayou and 1 Llanowar Elves (ready to attack for 4 with Giant Growth), I expect that if the player tries to cast, let's say, the second Llanowar Elves and hits "Auto", the AI may mistakenly tap Llanowar Elves and make it impossible to set up an attack - in these specific cases, of course, the player wants to be very careful and particular about what to do so hitting "Auto" is probably a good way to ask for trouble anyway ). It would be really amazing if you could make it figure out the best potential options using hand analysis, but I also realize that it's a very hard job to do because Magic is very complex and it's difficult to predict what may be the best options considering all the hand and battlefield options available once the battlefield gets "populated enough". Anyhow, it's a very good first start, and I'll be happy to see your further improvements in this area! Good luck!

- Agetian

Could Commanders display how much commander damage they dealt to each player?

Marek14 wrote:Could Commanders display how much commander damage they dealt to each player?

That should now show in the Details pane when hovering over them, as of the next snapshot build.

Playing Quest mode vs the Minotaur deck. Crimson Muckwader is in play on my side. I guess it's trying to figure out if it should attack, but the casting is too narrow.

RuntimeException | Open

Code: Select all

Forge Version:    SVN
Operating System: Windows 8 6.2 amd64
Java Version:     1.7.0_51 Oracle Corporation

java.lang.RuntimeException: There is an error in the card code for Crimson Muckwader:forge.player.PlayerControllerHuman cannot be cast to forge.ai.PlayerControllerAi
   at forge.ai.ComputerUtil.canRegenerate(ComputerUtil.java:800)
   at forge.ai.ComputerUtilCombat.canDestroyBlocker(ComputerUtilCombat.java:1720)
   at forge.ai.AiAttackController.shouldAttack(AiAttackController.java:999)
   at forge.ai.AiAttackController.declareAttackers(AiAttackController.java:864)
   at forge.ai.AiController.declareAttackers(AiController.java:1162)
   at forge.ai.PlayerControllerAi.declareAttackers(PlayerControllerAi.java:405)
   at forge.game.phase.PhaseHandler.declareAttackersTurnBasedAction(PhaseHandler.java:474)
   at forge.game.phase.PhaseHandler.onPhaseBegin(PhaseHandler.java:291)
   at forge.game.phase.PhaseHandler.startFirstTurn(PhaseHandler.java:1060)
   at forge.game.GameAction.startGame(GameAction.java:1558)
   at forge.game.Match.startGame(Match.java:81)
   at forge.control.FControl$4.run(FControl.java:447)
   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)
Caused by: java.lang.ClassCastException: forge.player.PlayerControllerHuman cannot be cast to forge.ai.PlayerControllerAi
   at forge.ai.ComputerUtilMana.isManaSourceReserved(ComputerUtilMana.java:683)
   at forge.ai.ComputerUtilMana.canPayShardWithSpellAbility(ComputerUtilMana.java:635)
   at forge.ai.ComputerUtilMana.payManaCost(ComputerUtilMana.java:421)
   at forge.ai.ComputerUtilMana.payManaCost(ComputerUtilMana.java:80)
   at forge.ai.ComputerUtilMana.canPayManaCost(ComputerUtilMana.java:54)
   at forge.ai.ComputerUtilCost.canPayCost(ComputerUtilCost.java:378)
   at forge.ai.ComputerUtil.canRegenerate(ComputerUtil.java:769)
   ... 14 more


friarsol wrote:Playing Quest mode vs the Minotaur deck. Crimson Muckwader is in play on my side. I guess it's trying to figure out if it should attack, but the casting is too narrow.

RuntimeException | Open

Code: Select all

Forge Version:    SVN
Operating System: Windows 8 6.2 amd64
Java Version:     1.7.0_51 Oracle Corporation

java.lang.RuntimeException: There is an error in the card code for Crimson Muckwader:forge.player.PlayerControllerHuman cannot be cast to forge.ai.PlayerControllerAi
   at forge.ai.ComputerUtil.canRegenerate(ComputerUtil.java:800)
   at forge.ai.ComputerUtilCombat.canDestroyBlocker(ComputerUtilCombat.java:1720)
   at forge.ai.AiAttackController.shouldAttack(AiAttackController.java:999)
   at forge.ai.AiAttackController.declareAttackers(AiAttackController.java:864)
   at forge.ai.AiController.declareAttackers(AiController.java:1162)
   at forge.ai.PlayerControllerAi.declareAttackers(PlayerControllerAi.java:405)
   at forge.game.phase.PhaseHandler.declareAttackersTurnBasedAction(PhaseHandler.java:474)
   at forge.game.phase.PhaseHandler.onPhaseBegin(PhaseHandler.java:291)
   at forge.game.phase.PhaseHandler.startFirstTurn(PhaseHandler.java:1060)
   at forge.game.GameAction.startGame(GameAction.java:1558)
   at forge.game.Match.startGame(Match.java:81)
   at forge.control.FControl$4.run(FControl.java:447)
   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)
Caused by: java.lang.ClassCastException: forge.player.PlayerControllerHuman cannot be cast to forge.ai.PlayerControllerAi
   at forge.ai.ComputerUtilMana.isManaSourceReserved(ComputerUtilMana.java:683)
   at forge.ai.ComputerUtilMana.canPayShardWithSpellAbility(ComputerUtilMana.java:635)
   at forge.ai.ComputerUtilMana.payManaCost(ComputerUtilMana.java:421)
   at forge.ai.ComputerUtilMana.payManaCost(ComputerUtilMana.java:80)
   at forge.ai.ComputerUtilMana.canPayManaCost(ComputerUtilMana.java:54)
   at forge.ai.ComputerUtilCost.canPayCost(ComputerUtilCost.java:378)
   at forge.ai.ComputerUtil.canRegenerate(ComputerUtil.java:769)
   ... 14 more


I'm working on fixing this right now, this is indeed related to an illegal cast in the new code I introduced yesterday. Will fix ASAP. A question for everybody who is in the know in case I run into difficulties: what is the best way in the current code base to determine if the player is AI-controlled?

r27214: Should be fixed right now, though I'm not sure if the way I'm determining the controller type is optimal. Let me know if you see any more of this issue or any other related crashes, I'll work on fixing them ASAP. At the very least, all the other similar casts are in the AI controller code proper, so they shouldn't misfire for the human player.

- Agetian

Since I've worked this release on making Momir Basic easier to play, I felt it was time to make it quicker to pay X mana costs. I just committed a change so that now, when prompted to pay X, the left button will display as "Auto" until you manually click a mana source. If you press Auto, you'll be prompted to pick a value for X, with it defaulting to the maximum value you can afford. If you press OK on that prompt, Forge will use AI logic to automatically pay whatever value for X you chose. This way, if you want to tap out for an X cost and have say 8 lands, instead of needing 8 clicks, you only need 2, one for Auto, and one for OK on the prompt. Even if you don't want to tap out, it only adds one extra click to choose a different value for the prompt.

As part of this, I also simplified the prompt message for InputPayManaX so it looks more like other mana cost payment messages.


Let me know what you think or if you encounter any problems with this new functionality.

Thanks.
-Dan

drdev wrote:Since I've worked this release on making Momir Basic easier to play, I felt it was time to make it quicker to pay X mana costs. I just committed a change so that now, when prompted to pay X, the left button will display as "Auto" until you manually click a mana source. If you press Auto, you'll be prompted to pick a value for X, with it defaulting to the maximum value you can afford.

Sounds like a great idea! I'll update a bit later and will test this in action.

- Agetian

drdev wrote:If you press OK on that prompt, Forge will use AI logic to automatically pay whatever value for X you chose. This way, if you want to tap out for an X cost and have say 8 lands, instead of needing 8 clicks, you only need 2, one for Auto, and one for OK on the prompt. Even if you don't want to tap out, it only adds one extra click to choose a different value for the prompt.

Well, technically the way it should work is that you choose the value of X during the announcement portion of paycosts. In some instances X isn't really "declared" it's "assigned"; For example, Spell Blast assigns X by the spell that's targeted. You don't really need to "declare X" of Spell Blast to be 4 so that Armageddon is a legal target.

This would solve some bugs with cost reducers and X costs (since X would be known at the time costs would be reduced). So if this X announcement was moved earlier and applied for all X costs that otherwise aren't defined then X would just get rolled into the ManaPayCost and I think we wouldn't need a specific InputPayManaX at all. (So you could just use the normal "Auto" button that exists there.)

friarsol wrote:

drdev wrote:If you press OK on that prompt, Forge will use AI logic to automatically pay whatever value for X you chose. This way, if you want to tap out for an X cost and have say 8 lands, instead of needing 8 clicks, you only need 2, one for Auto, and one for OK on the prompt. Even if you don't want to tap out, it only adds one extra click to choose a different value for the prompt.

Well, technically the way it should work is that you choose the value of X during the announcement portion of paycosts. In some instances X isn't really "declared" it's "assigned"; For example, Spell Blast assigns X by the spell that's targeted. You don't really need to "declare X" of Spell Blast to be 4 so that Armageddon is a legal target.

This would solve some bugs with cost reducers and X costs (since X would be known at the time costs would be reduced). So if this X announcement was moved earlier and applied for all X costs that otherwise aren't defined then X would just get rolled into the ManaPayCost and I think we wouldn't need a specific InputPayManaX at all. (So you could just use the normal "Auto" button that exists there.)

The problem with that is it forces the dialog when some people would just prefer to tap lands manually as we've supported up until now. I don't think we need to adhere to specific timing defined by the rules at the cost of usability.

drdev wrote:The problem with that is it forces the dialog when some people would just prefer to tap lands manually as we've supported up until now. I don't think we need to adhere to specific timing defined by the rules at the cost of usability.

Well, the key here is that there are bugs in delaying the "declaration" of X until after costs are reduced (as causes problems with Trinisphere) At some point we will need to pull the plug, and just deal with it the right way. While I agree in general we should try to adhere to usability, rule bugs not being fixed solely due to usability isn't a great excuse for people who report errors of not winning a game because they didn't get to cast a spell the way they were expecting to.

friarsol wrote:

drdev wrote:The problem with that is it forces the dialog when some people would just prefer to tap lands manually as we've supported up until now. I don't think we need to adhere to specific timing defined by the rules at the cost of usability.

Well, the key here is that there are bugs in delaying the "declaration" of X until after costs are reduced (as causes problems with Trinisphere) At some point we will need to pull the plug, and just deal with it the right way. While I agree in general we should try to adhere to usability, rule bugs not being fixed solely due to usability isn't a great excuse for people who report errors of not winning a game because they didn't get to cast a spell the way they were expecting to.

Fair enough.

So is the consensus that I should just eliminate InputPayManaX and include the prompt for X at the time of declaring the spell/ability prior to mana payment?

It would be a very good idea drdev!

As promised, I just finished adding the Momir Basic variant to the desktop game.


As part of this, I also eliminated the Archenemy combo box in favor of a separate checkbox for Rumble and adding descriptions for each variant to a tooltip for each checkbox.

Let me know if you have any thoughts on this or ideas for other variants to add. It should be easier to do so now.

Thanks.
-Dan