Collectible Card Game Headquarters

friarsol wrote:Uba Mask should probably only be granting the static trigger to the card that it remembers exactly, including timestamp. I think this is where the main issue is. It just remembers the card by ID since IDs don't change when moving zones.

Yes, I agree that this should help Uba Mask properly remember/forget the cards that are exiled with it. I still can't understand the mystery of clearing the (already empty) triggers on the exiled card in order to make the card castable again from the exile - is it also because the timestamp changes but the ID of the card remains the same?..

- Agetian

Are you sure it's not the "getCurrentState()" that's causing this effect?

friarsol wrote:Are you sure it's not the "getCurrentState()" that's causing this effect?

I tested this assumption and came to a conclusion that it's not the case... it's indeed the trigger-clearing call that produces the effect.

By the way, one more related observation: I noticed that without any tweaks like the one mentioned above, if you try casting a spell from the exile, then cancel it, it disappears from Uba Mask's remembered list (and that's why it becomes uncastable). Making the clear triggers call tweak above seems to fully recreate Uba Mask's list, adding even cards that should theoretically no longer be on that list (already played, for example).

- Agetian

Marek14 wrote:

elcnesh wrote:Dan, I'm planning some changes to the structure of the Trackable objects, namely getting rid of the static part and delegating that responsibility to a Tracker object associated to a single Game. This is necessary for a single computer to run multiple Games simultaneously, which hopefully can be done sometime in the future. Do you know a priori of anything that might break? So far everything seems to work just fine in my tests, but I thought I'd just quickly check it with you.

Oh, that might allow to implement Ass Whuppin'

BTW, more seriously, could this also allow for Shahrazad?

Well theoretically, yes, although I'd like to give the card a Chaos Orb treatment... Just imagine the number of bugs we'd get just to implement a card that no-one really likes (or at least, a lot of players hate)

elcnesh wrote:Well theoretically, yes, although I'd like to give the card a Chaos Orb treatment... Just imagine the number of bugs we'd get just to implement a card that no-one really likes (or at least, a lot of players hate)

What are you talking about, CHAOS ORB IS AWESOME.

http://archive.wizards.com/Magic/magazi ... arcana/348

By the way, here's a bug that's been there ever since I started playing with Forge. When I get mana-screwed, and am left with more than 7 cards in my hand, I can keep them until the next turn (i.e., skip the discard at the End Turn phase) if I press Enter continuously. Did anyone else notice that? It's very easily reproducible, just don't play any land and keep your cards.

I don't know why it happens in terms of the code, but I imagine several keystrokes are being enqueued and resolved at the same time, and there must be some synchronization missing between the gameplay and the gui. I'm happy to learn about that part of the code and help fixing it, I imagine it may not be so simple though...

elcnesh wrote:swordshine, in r28689 you changed the way ZoneChange Triggers work. I believe this has caused some bugs with triggers running twice or not at all (see viewtopic.php?f=26&t=16670#p171880), which is probably related to the fact that ZC Triggers do not have a specified TriggerZone, since the triggering object is the LKI of the one leaving its zone. I'm not entirely sure how this code behaves or should behave, but I do believe its related to this commit.

Those ZCTriggers I changed in r28689 are actually commands (they didn't use the stack). I didn't change ZoneChange Triggers.
Edit: Actually, when I tested some FRF cards during the spoiler season, I encountered the same bugs occasionally (Whisperwood Elemental).

swordshine wrote:

elcnesh wrote:swordshine, in r28689 you changed the way ZoneChange Triggers work. I believe this has caused some bugs with triggers running twice or not at all (see viewtopic.php?f=26&t=16670#p171880), which is probably related to the fact that ZC Triggers do not have a specified TriggerZone, since the triggering object is the LKI of the one leaving its zone. I'm not entirely sure how this code behaves or should behave, but I do believe its related to this commit.

Those ZCTriggers I changed in r28689 are actually commands (they didn't use the stack). I didn't change ZoneChange Triggers.
Edit: Actually, when I tested some FRF cards during the spoiler season, I encountered the same bugs occasionally (Whisperwood Elemental).

Ok, good to know.

Dan, I think you're still compiling the Android version against an old Forge version... The changes you made in r28816 actually cause a compile error for me, since I added the new Tracker argument to the CardView constructor (although admittedly a constructor not requiring one would be cleaner than passing it null all the time...)

Sorry about that. Feel free to fix it and I'll be sure to update the module versions before making further changes.

Dan, isn't it tricky to compare Replacement effects and Triggers by toString for determining whether to ask for ordering them? I'm not sure if there can be a situation where the strings are the same, but for example the sources of the effects are different, and the order can still matter...

(Although I'm definitely in favour of this change if there's no difference, can save a lot of clicks!)

elcnesh wrote:Dan, isn't it tricky to compare Replacement effects and Triggers by toString for determining whether to ask for ordering them? I'm not sure if there can be a situation where the strings are the same, but for example the sources of the effects are different, and the order can still matter...

(Although I'm definitely in favour of this change if there's no difference, can save a lot of clicks!)

I can't think of any case where the string value would be the same and they wouldn't function the same. We use the string value of triggered abilities for auto-yields as well so that auto-yielding one auto-yields all with the same string value. I see this as being no different.

Besides, all you have to go by to decide the order manually is the string value, so if they're all the same, there's nothing useful you can really do to differentiate your picks. So the system might as well do it for you at that point.

I don't think this is working as intended when multiple exalted triggers going on the stack.

squee1968 wrote:I don't think this is working as intended when multiple exalted triggers going on the stack.

Is the text of all the triggers the same? If even a single trigger is different, you'll have to order them all.

@Dan, r29237: you added a lot of switch-case statements to RandomDeckGenerator that my IDE picks out because they're all falling through, ie. no breaks. Is this supposed to happen? Judging from the code I'd say no...

@Sol, 29256: sorry about that throw in RepeatEachEffect, not quite sure why I added it. I think my IDE found that an NPE was going to be thrown and I sought to prevent it, but should definitely have tested before committing. Also, preventing one exception by throwing another isn't really helping a lot