Developing Bugs

[Max mtg]

It looks so. I am sorry

Will we release a patch for 3.1.12 to fix this one and all the concurrent modification exceptions?
(Deploy only the jarfile and tell people to replace the old one with it)

[Chris H.]

It looks so. I am sorry

Will we release a patch for 3.1.12 to fix this one and all the concurrent modification exceptions?
(Deploy only the jarfile and tell people to replace the old one with it)

 
I think that it might be best to post a link to the snapshot build.

[Max mtg]

I think that it might be best to post a link to the snapshot build.

Will be great, especially if it's easy enough for everyone to understand how to patch their installation.

I think it will be of help, if you also update the topmost message of the 3.12 announcement.

[Chris H.]

Will be great, especially if it's easy enough for everyone to understand how to patch their installation.

I think it will be of help, if you also update the topmost message of the 3.12 announcement.

 
Yes, downloading a snapshot with a direct link to it's URL is probably easiest for the user base.

I made your URLs a little more user friendly and I also added them to the first message.

[Sloth]

This bug has been reported for 1.3.14, but is still there:

Description: I pressed cancel when prompted to sacrifice creatures for Phyrexian Dreadnought 's triggered ability.

RuntimeException | Open

Code: Select all

Forge Version:    1.3.14-r21289
Operating System: Windows 7 6.1 amd64
Java Version:     1.7.0_07 Oracle Corporation

java.lang.RuntimeException: Trying to unlock input which is not locked! Do check when your threads terminate!
   at forge.control.input.InputControl.unlock(InputControl.java:208)
   at forge.FThreads$1.run(FThreads.java:114)
   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   at java.lang.Thread.run(Unknown Source)


[Max mtg]

removed that excessive call in latest commit - r21396.

The very commit is hugely changing how match and UI interact.
[*] new MatchController is now created each time game is started.
[*] UI is considered to attach to a match and thus become able to display it. At the moment UI is attached to a match before the game starts, no guarantees it would correctly join at a different moment - but this can be improved, as well as UI can be made detacheable.
[*] Match is started completelly from EDT thread - that means no more black screens on game start. If anything is wrong user should see an exception. However, this should work even in a different way:
1. new MatchController(...) - no matter the thread.
2. currentGame = new GameState(...) - preferrably from nonEDT
3. attachToUi - called from EDT
4. GameNew.newGame - from non-EDT
--- but this is for a later time.
[*] Match is no longer avaliable in FModel class. So that this class retains only card/edition databases and assets like decks and quest -- that could become user account data once... Match instance is now found in FControl, meaning 'the match where gui player plays'. There could potentially exist more than one instances of MatchController (held in some collection somewhere near Lobby), but it is another future problem.

PS: I switched to Java 7 runtime (and still using jdk 6 to develop) - the ingame animations runs way smoother, so consider updating runtimes if you haven't done so yet.

[Sloth]

@Max: getColorByProminence is broken (r21442), it always return Red and Green.

[Max mtg]

@Max: getColorByProminence is broken (r21442), it always return Red and Green.

That's a regretable miss,
I've written a different method body for the r21451. UW deck has just received correct colors

[Sloth]

Description: AI had triggered an encoded Hands of Binding and two spell cast triggers went on the stack as well. The game continued normally.

ConcurrentModificationException | Open

Code: Select all

Forge Version:    SVN
Operating System: Windows 7 6.1 amd64
Java Version:     1.6.0_38 Sun Microsystems Inc.

java.util.ConcurrentModificationException
   at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
   at java.util.AbstractList$Itr.next(Unknown Source)
   at forge.gui.match.views.VStack.updateStack(VStack.java:140)
   at forge.gui.match.controllers.CStack$1.run(CStack.java:45)
   at java.awt.event.InvocationEvent.dispatch(Unknown Source)
   at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
   at java.awt.EventQueue.access$400(Unknown Source)
   at java.awt.EventQueue$2.run(Unknown Source)
   at java.awt.EventQueue$2.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)


[RedDeckWins]

xPaid seems to be broken in some cases. Not working for Crypt Rats at least.

EDIT:
Actually it may be the inputting of X that is broken.

[Max mtg]

xPaid seems to be broken in some cases. Not working for Crypt Rats at least.

EDIT:
Actually it may be the inputting of X that is broken.

That was the very input-related problem. Fixed in r21475.

Description: AI had triggered an encoded Hands of Binding and two spell cast triggers went on the stack as well. The game continued normally.

Won't happen after 21472

[swordshine]

r21474, I tried four cards and none of them work correctly.
Emrakul, the Aeons Torn: the "time walk" trigger triggers twice.
Mosswort Bridge: I activated the "Play" ability and the card came into play under my opponent's control.
Isochron Scepter's "Play" ability is also broken, just nothing happened.
Panoptic Mirror cannot imprint a card from my hand.

[RedDeckWins]

I found a weird bug while implementing War Tax today. The following call stack happens when the War Tax ability resolves:

Code: Select all

     at forge.card.spellability.SpellAbility.setActivatingPlayer(SpellAbility.java:287)
     at forge.game.ai.AiController.getPossibleETBCounters(AiController.java:151)
     at forge.game.ai.AiController.getSpellAbilityToPlay(AiController.java:99)
     at forge.game.ai.AiController.playSpellAbilities(AiController.java:875)
     at forge.game.ai.AiController.onPriorityRecieved(AiController.java:796)
     at forge.game.ai.AiInputCommon$1.run(AiInputCommon.java:74)
     at forge.FThreads$1.run(FThreads.java:115)
     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
     at java.lang.Thread.run(Thread.java:722)


This sets the activating player to non-human. Then, EffectEffect.resolve(), line 100 is hit, and the activating player is still the the non-human.

Obviously a lot of stuff happens in between, but it seems like a bug to me. I was able to work around it by declaring the EffectOwner as the SourceController this time.

[Max mtg]

@RDW, looks like you've cut the most interesting part with exception name and possiblly the head of trace.

@swordshine, Mosswort bridge, Panoptic Mirror and hopefully are no longer bugged. (Haven't tested the rest, but hope these work as well)

[RedDeckWins]

Sorry, to clarify, there is no exception:

The bug is that the effect is put into the command zone of the wrong player when it resolves. There is no exception. The pasted callstack just a little insight into how/where the activating player is being set incorrectly before the EffectEffect resolves.