Collectible Card Game Headquarters

OK, this project is now trunked.

- Agetian

Agetian wrote:- After the match, the deck is set back to its original form. Not sure if this is actually the desired behavior or not, but 1) saving the deck from inside the game seems like a rather major hassle, 2) not sure if you'd actually want to keep the modifications to your main deck after sideboarding anyway. So I'll leave it the way it is, at least for the time being.

I'll echo Sol's sentiments here - this is indeed very much the desired behavior! Well done.

Played my first quest match, and I'm pretty sure I added my sideboard correctly. Won my first game, I get the dual list box for sideboarding, but it has my opponents deck in it (without a sideboard, since he probably doesn't actually have a sideboard). I'm not allowed to continue until I sideboard out 15 cards (since that's how many cards I actually have in my sideboard). When the game starts, I have my opponents deck (-15 cards that I sideboarded out), and my opponent has his normal deck.

Edit: I just retried this on my other machine, and the same thing happened, so I guess things aren't quite working yet.

Hmm this is very strange, I did not see that happen but I haven't tried Quest mode too much, I'll try it out in Quest mode and see what's troubling it. Can you please, in the meantime, try Constructed and see if it happens to you there as well (for me it doesn't)?

Oh, and I have a related question: are the decks stored somehow differently in Quest mode compared to Constructed? I mean, are the decks loaded somehow differently and/or accessed differently which could potentially store (and thus load) the opponent's deck from the same place from where normally it should load the player's sideboard? (I don't ever reference the opponent's deck in any way anywhere in the sideboard code, so it's very weird that it even shows the opponent's deck in Quest mode...)

- Agetian

OK here's a weird thing: if you only play Constructed (or Draft/Sealed), sideboarding works correctly every time. However, if you play a Quest match, after that sideboarding becomes broken and exhibits the behavior Sol described above (even in Constructed). I'm going to take a look at what's up, but if anyone knows of any peculiar features of the Quest mode compared to Constructed (compared to deck loading and whatnot) that might actually make things go haywire, please let me know...

EDIT: kk maybe I have an idea where it messes up, hold on...

- Agetian

Aaaand fixed. Thanks for reporting, Sol. Please try again and let me know if it goes haywire again in some case, I'll fix it!

- Agetian

Agetian wrote:Hmm this is very strange, I did not see that happen but I haven't tried Quest mode too much, I'll try it out in Quest mode and see what's troubling it. Can you please, in the meantime, try Constructed and see if it happens to you there as well (for me it doesn't)?

Seems to work just fine in Constructed. Lemme know if you want me to attach a quest file for you to test with.

Yeah, there was a problem with not checking for whether it's the human deck or some other deck before storing it in the persistent storage (and it looks like the quest mode had a different order of loading decks or something, which broke it). I was dead sure that quest mode worked because I tested it extensively before I implemented persistence, but seems like persistence broke it. Anyways, it should be fixed now with my latest commit, please update and try again and see if that resolves it.

P.S. A somewhat bigger, underlying issue that's currently dormant is that the current mechanism of deck/sideboard persistence relies on the fact that there's only one human player in the game - so, it's not quite yet network-ready. I'll work on updating it over time (will try to think of a better, more generic solution), but for now, everything should work perfectly fine in all modes (yes, it will also work correctly in multiplayer games against multiple AI opponents). Let me know if any other bugs spring up, I'll work on fixing them.

EDIT: Actually, I think I even know of a generic, network-friendly solution, I'll experiment a bit during the weekend and will likely commit a better solution that will be both a bit more elegant and will not rely on a specific deck belonging to the only human player. At least if everything works out like I imagine it should, of course.

- Agetian

I have two minor suggestions.

1) Since we aren't using a deck editor to sideboard, it would be preferable if the cards were sorted alphabetically to more quickly find cards you wanted to add/remove. I don't expect the DLB to resort while adding cards, but at least being sorted at the beginning should help.

2) I don't know if this is doable or not, but instead of always popping up the sideboard dialog, perhaps we add a sideboard button on the End Game screen (enabled if the Sideboard is greater than 0). That way if you didn't need to sideboard at all, it wouldn't (potentially) slow things down. Not a major deal, but could potentially speed things up.

I completely agree with both suggestions and I actually already tried a couple things for the first point you mentioned, but sadly, so far it didn't work... It looks like the dual-panel window we're using for that relies on something called UnsortedListModel, which is apparently designed to not be sorted (maybe I'm wrong, but it looks like it might be the issue). I tried calling Collections.sort on the arrays that supposedly contained the cards in question, trying to sort them by name (I even tried implementing a custom inner comparator class for that), but the results were disastrous (either cards missing, like all Forests suddenly turning into just one Forest, or no sorting taking place anyway). I'm not sure what can be done at the moment, but I'll keep thinking.

I'll also check out the end game window and see if I can add a sideboarding button there. Thanks for the idea!

- Agetian

Agetian wrote:I completely agree with both suggestions and I actually already tried a couple things for the first point you mentioned, but sadly, so far it didn't work... It looks like the dual-panel window we're using for that relies on something called UnsortedListModel, which is apparently designed to not be sorted (maybe I'm wrong, but it looks like it might be the issue).

Ahhh right, I forgot about that (and I wrote the DLB to begin with). I'll take a look at some point and see if it can be added if you haven't figured it out by then.

Ok, feel free to modify it, I'm out of ideas at the moment... I tried one more thing but it didn't work either.

- Agetian

I had a crash with the sideboard when my Huntmaster of the Fells was in a flipped state at the end of a game.

Crash Report | Open

This is a Crash Report. An error has occurred. Please save this message to a file.
Please follow the instructions at this address to submit this Crash Report, plus what you were doing at the time:
http://tinyurl.com/3zzrnyb
Reporting bugs in Forge is very important. We thank you for your time.

Asked for card 'Ravager of the Fells' from 'DKA': set found, but the card wasn't.


Version:
Forge version SVN

OS: Windows 7 Version: 6.1 Architecture: amd64

Java Version: 1.6.0_26 Vendor: Sun Microsystems Inc.

Detailed error trace:
java.util.NoSuchElementException: Asked for card 'Ravager of the Fells' from 'DKA': set found, but the card wasn't.
at forge.item.CardDb.getCard(CardDb.java:297)
at forge.item.CardDb.getCard(CardDb.java:270)
at forge.item.CardDb.getCard(CardDb.java:321)
at forge.game.GameNew.sideboardAndPrepareLibrary(GameNew.java:214)
at forge.game.GameNew.prepareSingleLibrary(GameNew.java:155)
at forge.game.GameNew.newGame(GameNew.java:294)
at forge.game.MatchController.startRound(MatchController.java:128)
at forge.gui.match.ControlWinLose.actionOnContinue(ControlWinLose.java:80)
at forge.gui.match.ControlWinLose$1.actionPerformed(ControlWinLose.java:48)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.security.AccessControlContext$1.doIntersectionPrivilege(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)

Hmmmm it looks like CardDb can only get the original, non-flipped state of the card...

EDIT: Looks like this bug should be fixed.

- Agetian

I noticed a very strange thing happening that I can't trace to its source or understand how to fix, I'm not sure if it's the sideboard code causing it but I wouldn't be surprised if it is - if you mulligan in round 1 and then concede, then sideboard, and then go on to round 2 of the match, you won't get enough cards (you can get 4 or 6 cards instead of 7 in your opening hand). Moreover, mulliganing from then on sometimes gives you more cards than necessary (sometimes you get 7 after you got 6 in your opening hand, and sometimes you get 6, 9, 15 after you got 4 in your opening hand). There's nothing in the sideboarding code itself that would directly affect the mulligan code, so I'm not sure if it's even the sideboarding code that does it, but can someone please help me with this?.. I can't understand what's causing it and how to best approach fixing it at the moment, and it's a quite significant issue...

EDIT: I applied an experimental fix but I have no idea if it worked... I thought it may have something to do with the card owner not always being set, so I put that closer to adding the card to the library. Since then I haven't seen this happen, but this problem is really, really tricky - sometimes it happens and sometimes it doesn't, so I wouldn't be surprised if it comes back... Your advice is still highly welcome.

- Agetian