Collectible Card Game Headquarters

elcnesh wrote:I'm working on refactoring block declarations, but in order to do everything correctly, I need the field Card::mustBlock to become a multiset (it needs to count the nr of requirements on each creature to block). However, it uses the new property tracking system which I don't quite fully understand yet. Is there a simple way to convert this?

Are you talking about converting the Card class or the CardView class (or both)?

Basically, there needs to be a enum value in TrackableProperty for the property you want to add, and a corresponding TrackableType derived class defining the property type. You can re-use one of the existing classes that derive from TrackableType if possible. If there isn't one for the type you need, you just need to create a new class, likely by copying one of the ones with TODOs in it and just tweaking the name and the generic type.

I'm getting the following compilation error as of r28336. Can you please help?

Code: Select all

COMPILATION ERROR :
-------------------------------------------------------------
forge/game/mana/ManaCostBeingPaidTest.java:[3,23] package junit.framework does not exist
forge/game/mana/ManaCostBeingPaidTest.java:[9,44] cannot find symbol
  symbol: class TestCase
forge/game/mana/ManaCostBeingPaidTest.java:[20,13] cannot find symbol
  symbol:   method assertEquals(java.lang.String,java.lang.String)
  location: class forge.game.mana.ManaCostBeingPaidTest
forge/game/mana/ManaCostBeingPaidTest.java:[23,9] cannot find symbol
  symbol:   method assertEquals(java.lang.String,java.lang.String)
  location: class forge.game.mana.ManaCostBeingPaidTest
4 errors
-------------------------------------------------------------


EDIT: Tried to fix it (r28337), hope this is what was supposed to be done.

- Agetian

So I've been offline for a while (vacation and stuff), but I'm back! And I've done some testing about an issue posted in the bug tracker; try the following game state:

Code: Select all

HumanCardsInPlay=Mycosynth Lattice; March of the Machines; Darksteel Ingot
ActivePlayer=Human
ActivePhase=Main1


Somehow all cards get toughness 0 and die (confirmed by commenting out that state-based action). When I comment out the line that calls TrackableObject.freeze() in GameAction, this doesn't happen... What worries me is that the trackable objects are supposed to be related to view classes, yet somehow manage to interfere with the actual game.

It gets a bit weirder when leaving the aforementioned state-based action commented out. Everytime you play a land, none of the permanents turn into a creature, and everytime you tap one for mana, suddenly the game knows what to do and produces the correct game state. In fact, that game state doesn't even allow you to tap those lands for mana since they have summoning sickness...

Who maintains the bugtracker right now? I have commented on a few older tickets that should probably be closed/removed since they are either already resolved or not applicable anymore. Maybe I could get permission to modify tickets, at the moment I am just a reporter.

oskarolw wrote:Who maintains the bugtracker right now? I have commented on a few older tickets that should probably be closed/removed since they are either already resolved or not applicable anymore. Maybe I could get permission to modify tickets, at the moment I am just a reporter.

Nobody does, we tried using it for a little while, but it fell out of favor pretty quickly. Occassionally Sloth or I will go on there, but we've been too busy to do anything with it.

I can grant you more permissions later on.

Maybe it's an idea to completely clear it? There may be some useful reports on there, but it's drowned in all kinds of things that have already been fixed or are no longer relevant. It'd allow us to correctly tag any new reports and keep it up-to-date. I could do it, but I don't have any rights there (how do I get them...?).

Sure we can try it again and see how it works out this time.

I can raise people's privileges on there, oskarolw what account do you have on there? I don't see a matching handle from your slightlymagic boards one?

friarsol wrote:Sure we can try it again and see how it works out this time.

I can raise people's privileges on there, oskarolw what account do you have on there? I don't see a matching handle from your slightlymagic boards one?

On there I got Gorgonzola.

elcnesh wrote:So I've been offline for a while (vacation and stuff), but I'm back! And I've done some testing about an issue posted in the bug tracker; try the following game state:

Code: Select all

HumanCardsInPlay=Mycosynth Lattice; March of the Machines; Darksteel Ingot
ActivePlayer=Human
ActivePhase=Main1


Somehow all cards get toughness 0 and die (confirmed by commenting out that state-based action). When I comment out the line that calls TrackableObject.freeze() in GameAction, this doesn't happen... What worries me is that the trackable objects are supposed to be related to view classes, yet somehow manage to interfere with the actual game.

It gets a bit weirder when leaving the aforementioned state-based action commented out. Everytime you play a land, none of the permanents turn into a creature, and everytime you tap one for mana, suddenly the game knows what to do and produces the correct game state. In fact, that game state doesn't even allow you to tap those lands for mana since they have summoning sickness...

So it turns out the issue was with Card.getType() relying on the CardView object's type having been updated in the case of having changedTypes, which it wasn't if TrackableObject's are frozen. As having the game object's property depending on the view's property is a bad idea, I fixed the issue by just returning currentState.getType().getTypeWithChanges(changedCardTypes) directly from this property. The fix is committed in r28666.

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.

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'

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'

Sounds reasonable to me. As long as everything continues to work and perform well, I have no objections.

I was looking at CountersRemoveEffect.java today (for AB RemoveCounter) and I got a bit concerned by what it's trying to do:

Code: Select all

if (rememberRemoved) {
    for (int i = 0; i < chosenAmount; i++) {
        card.addRemembered(chosenType);
    }
}


Remembered objects in Card.java are of type Set, so only one can be stored at a time, so that code above (repeated twice in CountersRemoveEffect) effectively achieves nothing as far as remembering multiple counters goes - it only stores the information about the remembered counter once.
Why this is a problem is because certain cards rely on this effect, such as e.g. the Take portion of Give // Take, which will remove all counters correctly but which will only draw 1 card (because there's only one instance of the counter remembered). I don't know how many things are actually affected by this (probably not too many), but it is a bit worrying nonetheless.
Does anyone know what a good enough solution for this would be? Obviously, changing the type of remembered objects from Set to List will make this work, but will likely break other things because it will enable the possibility of remembering the same card multiple times. So, probably a bad idea. Does anyone have a good enough idea to suggest here?

- Agetian

Is there anything that relies explicitly on the type of counter stored? Otherwise you could just store the total number of counters.

elcnesh wrote:Is there anything that relies explicitly on the type of counter stored? Otherwise you could just store the total number of counters.

This card in particular, for instance (Give // Take) refers specifically to the +1/+1 counters by type in addition to by number... I don't know if more complex interactions are possible.

- Agetian