Page 15 of 16

Re: Implementing variants

PostPosted: 25 Sep 2013, 00:03
by sagephoenix
If a player has been dealt 21 points of combat damage by a particular Commander during the game, that player loses a game.
This isn't implemented correctly, I'm winning games from Niv-Mizzet Firemind's triggered ability without doing 40 damage,

Re: Implementing variants

PostPosted: 25 Sep 2013, 01:21
by swordshine
sagephoenix wrote:
If a player has been dealt 21 points of combat damage by a particular Commander during the game, that player loses a game.
This isn't implemented correctly, I'm winning games from Niv-Mizzet Firemind's triggered ability without doing 40 damage,
Fixed. Thanks, sagephoenix.

Re: Implementing variants

PostPosted: 25 Sep 2013, 01:50
by sagephoenix
swordshine wrote:
sagephoenix wrote:
If a player has been dealt 21 points of combat damage by a particular Commander during the game, that player loses a game.
This isn't implemented correctly, I'm winning games from Niv-Mizzet Firemind's triggered ability without doing 40 damage,
Fixed. Thanks, sagephoenix.
Thanks, no problem.

Re: Implementing variants

PostPosted: 25 Sep 2013, 08:27
by MIC132
I wrote it already in snapshot bug reports, but this may be a better place.

Sometimes I have a situation where AI taps his mana as if wanting to cast commander (judging by the amount, thought sometimes he just taps everything), but instead of his commander going to stack it just disappears. It's not in comm zone, not in grave, not in exile ant not on stack. This only happens to AI though, never happened to me when casting commander.

Re: Implementing Variants (from Bug Reports (snapshot builds

PostPosted: 25 Sep 2013, 11:01
by Doomlord
Description: This crash happens everytime I try to start a commander game.

NullPointerException | Open
Code: Select all
Forge Version:    1.4.8-SNAPSHOT-r23305
Operating System: Linux 3.5.0-34-generic amd64
Java Version:     1.7.0_25 Oracle Corporation

java.lang.NullPointerException
   at forge.game.RegisteredPlayer.forCommander(RegisteredPlayer.java:154)
   at forge.gui.home.variant.CSubmenuCommander.startGame(CSubmenuCommander.java:154)
   at forge.gui.home.variant.CSubmenuCommander.access$100(CSubmenuCommander.java:38)
   at forge.gui.home.variant.CSubmenuCommander$2.actionPerformed(CSubmenuCommander.java:88)
   at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
   at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)
   at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
   at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
   at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)
   at java.awt.Component.processMouseEvent(Component.java:6505)
   at javax.swing.JComponent.processMouseEvent(JComponent.java:3312)
   at java.awt.Component.processEvent(Component.java:6270)
   at java.awt.Container.processEvent(Container.java:2229)
   at java.awt.Component.dispatchEventImpl(Component.java:4861)
   at java.awt.Container.dispatchEventImpl(Container.java:2287)
   at java.awt.Component.dispatchEvent(Component.java:4687)
   at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
   at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
   at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
   at java.awt.Container.dispatchEventImpl(Container.java:2273)
   at java.awt.Window.dispatchEventImpl(Window.java:2719)
   at java.awt.Component.dispatchEvent(Component.java:4687)
   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735)
   at java.awt.EventQueue.access$200(EventQueue.java:103)
   at java.awt.EventQueue$3.run(EventQueue.java:694)
   at java.awt.EventQueue$3.run(EventQueue.java:692)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
   at java.awt.EventQueue$4.run(EventQueue.java:708)
   at java.awt.EventQueue$4.run(EventQueue.java:706)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Re: Implementing variants

PostPosted: 26 Sep 2013, 16:20
by sagephoenix
Could we implement the Noble variant? http://www.noblemtg.com/
It's a lot like Commander.

I'm not sure exactly how the deck builder for commander is implemented? I noticed that when you switch over, it will only show cards eligible for the command zone. Is this a list/array/set that is updated whenever new cards are added, or is it taking the whole set of cards and ruling out all non-legendary cards, then ruling out anything from that set that are not creatures?

If it's the latter, then Noble will be more difficult to implement because it's parameters involve the lowest printed rarity.

The next issue is issues with the command zone.
1. Your Noble is face-down. This purpose isn't to have a 2/2 morph creature but rather information hiding.

2. When you noble is destroyed or exiled, it behaves normally and doesn't return to the command zone.

What are your guys thoughts on implementing this?

Re: Implementing variants

PostPosted: 26 Sep 2013, 16:37
by friarsol
sagephoenix wrote:Could we implement the Noble variant? http://www.noblemtg.com/
It's a lot like Commander.

I'm not sure exactly how the deck builder for commander is implemented? I noticed that when you switch over, it will only show cards eligible for the command zone. Is this a list/array/set that is updated whenever new cards are added, or is it taking the whole set of cards and ruling out all non-legendary cards, then ruling out anything from that set that are not creatures?

If it's the latter, then Noble will be more difficult to implement because it's parameters involve the lowest printed rarity.

The next issue is issues with the command zone.
1. Your Noble is face-down. This purpose isn't to have a 2/2 morph creature but rather information hiding.

2. When you noble is destroyed or exiled, it behaves normally and doesn't return to the command zone.

What are your guys thoughts on implementing this?
It's just a filter looking for Legendary Creatures. I'm not sure we have a way to filter by Rarity in the way that would be needed. Does lowest printed rarity mean more common or more rare? I could see arguments for either way. Ok, it looks like it means more common. That's definitely awkward phrasing to me.

It could certainly be added to the list of potential future variants, but I'd imagine it would need either a developer who is excited about the format, or a huge burst of popularity for that to happen.

Re: Implementing variants

PostPosted: 26 Sep 2013, 17:15
by sagephoenix
friarsol wrote:It's just a filter looking for Legendary Creatures. I'm not sure we have a way to filter by Rarity in the way that would be needed. Does lowest printed rarity mean more common or more rare? I could see arguments for either way. Ok, it looks like it means more common. That's definitely awkward phrasing to me.

It could certainly be added to the list of potential future variants, but I'd imagine it would need either a developer who is excited about the format, or a huge burst of popularity for that to happen.
I actually had to contact the person who started the format about this. It is extremely awkward phrasing. I've even had people think it means how many times it has occurred at that rarity. Basically, if it was ever printed at common, it's a common, even if it was printed as a mythic rare at some other point.

I would help however I could, but I barely understand Forge's structure. I'm only a second-year Computer Science major, so I know a lot of programming concepts and I can code classes and such, but I'm not quite at the point of being able to look at a pre-existing architecture at a level such that Forge is and implement something new with it.

Re: Implementing variants

PostPosted: 28 Sep 2013, 08:00
by Hellfish
Alright, I just finished moving to a new apartment, so I should have some time to tart up Commander again.

Todolist:
-Fix disappearing AI Commander.
-Fix crash on game start.
-Fix commander deck editor not allowing multiple Relentless Rats or Shadowborn Apostle.

Re: Implementing variants

PostPosted: 29 Sep 2013, 21:58
by Hellfish
Hellfish wrote:-Fix disappearing AI Commander.
I gotta hit the sack before a busy work week but what I've found is that the cause seems to be that the AI is failing to pay the full cost when it has been increased.I don't know how exactly the ComputerUtilMana.payManaCost function works but the DEBUG_MANA_PAYMENT output seems to indicate that the increased cost is ignored altogether in the test phase and decreased by 1 in the PROD phase. ComputerUtilMana.calculateManaCost returns the original cost in test and the correctly increased cost in PROD.

Re: Implementing variants

PostPosted: 29 Sep 2013, 22:14
by sagephoenix
Hellfish, you might want to look at this too if you haven't seen it already. It might also be keeping Commanders from existing.

viewtopic.php?f=52&t=3760&start=1845#p133820

Re: Implementing variants

PostPosted: 01 Oct 2013, 19:05
by Hellfish
I think I see the problem, but I can't fix it atm, due to time.
The AI fails to pay because it thinks the cost to pay is the original cost, not the raised one. This happens because the methods that evaluate if the AI can pay the cost is run before the spell is put on the stack. This causes the Commander cost raise to fail because it works with the wasCastFromCommand valid. The cost raise works later when the AI actually tries to play the Commander, but now with too little mana available.

Re: Implementing variants

PostPosted: 05 Oct 2013, 18:04
by Hellfish
*Finally* fixed it. :P
EDIT: God damn it...
EDIT2: There.

Re: Implementing variants

PostPosted: 27 Nov 2013, 04:21
by friarsol
Hey Hellfish,

At some point recently the all AIs stopped attacking players other than the Human in multiplayer games. Mind checking that out when you get a chance? I know you worked on Multiplayer originally, I poked around when people were first reporting it, and didn't see anything obvious.

Re: Implementing variants

PostPosted: 23 Jun 2014, 08:19
by Marek14
Looks like there's increasing number of "challenge" variants -- three challenge decks from Theros block, and now Garruk the Slayer...