Current Known Bugs list

[DennisBergkamp]

Yeah it would be pretty cool actually. I just hope it's easy to revert to previous versions if stuff gets messed up (but I assume it is). Another thing that would be crucial is some place to specify what changes where made exactly, and by who.

[Corwin72]

Grim Monolith does not tap for mana in the 10/07/09 update.

[DennisBergkamp]

Strange, it seems to work just fine for me.

[nantuko84]

Yeah it would be pretty cool actually. I just hope it's easy to revert to previous versions if stuff gets messed up (but I assume it is). Another thing that would be crucial is some place to specify what changes where made exactly, and by who.

yep, all these things are easy with svn.
to see the changes and theirs authors you can look into svn log (it's svn command) in your svn client or just use web access if you use google code svn repository.
try this to see the changes example:
http://code.google.com/p/cardforge/source/detail?r=21
you can commit the code to svn only if you Project committer that also allows you to comment any sumbits and give them +1 or -1.

All you need now to choose svn client or just use default one in Eclipse.
As for me, I use tortoiseSVN that integrates into Windows Explorer but this client is Windows only. Just install and use!
If you'd like to work with repository from Eclipse, then you should try this intruction:
http://www.ibm.com/developerworks/opensource/library/os-ecl-subversion/
After that use commiter url, it begins with https instead of http.
It can be found here http://code.google.com/p/cardforge/source/checkout (don't forget to login into google).
Good luck

[zerker2000]

By the way, the reason some of the land cards are not tapping for mana anymore is because of

Code: Select all

card.clearSpellAbility();

And in Card.java:

Code: Select all

public void clearSpellAbility() {spellAbility.clear(); manaAbility.clear();}

Which didn't use to have manaAbility.clear().
Not sure what's the best solution here, maybe for now I could create a clearSpellNotManaAbility() or something, which would only clear the spellAbilities, and replace the clearSpellAbility() with that method on the lands we are currently having trouble with.

Aiee!
Hmm, I guess now we need to go through all references of card.clearSpellAbility (not to mention getKeyword and clearKeyword-s) in order to prevent possible problems .

[silly freak]

just go on clearSpellAbility and click F3, that should do the searching!

[zerker2000]

Yes, however we'd still net to fix up all problematic places it (and keywords) are called. i.e., I predict a problem with Gemhide Sliver adding abilities permanently because the clearExtrinsicKeywords wouldn't do anything .

[DennisBergkamp]

I've fixed this in a few places already (the pay 2 life lands, Mox Diamond, Llanowar Elves token from Llanowar Mentor)... but true, didn't think of Gemhide Sliver yet, this would probably be trickier to fix

[DennisBergkamp]

By the way, I just created a method in Card.java to deal with the easier kind of situations:

Code: Select all

 public void clearSpellAbility() {spellAbility.clear(); manaAbility.clear();}
  public void clearSpellKeepManaAbility() { spellAbility.clear(); }

Which should be sufficient for most of our cases.
If you guys think there's a better way, let me know...

I'm not sure how to fix cases like Gemhide Sliver and Joiner Adept though.

[silly freak]

i'd like to help, but don't get what's going on any more^^

the problem is that since the last version, clearSpellAbility also contains manaAbility.clear(), and that because of the mana pool update?

[DennisBergkamp]

Well, to be honest I don't understand 100% either. The clearSpellAbility() is a small part of our problem, but the extra method I put in Card.java (which just clears the spellAbilities, not the manaAbilities) should fix most of them.
I think the main problem right now is that after the manapool update, mana abilities are actual mana abilities now (they used to be merely keywords). So in the case of cards like Gemhide Sliver, if it were to leave play, other slivers would still have the "add mana of any color" ability (before, we would just remove the keywords when it would leave play, now it's hard to determine what mana abilities where added by the Gemhide Sliver).

Maybe we could split up the manaAbilities between Intrinsic and Extrinsic somehow, so whenever Gemhide Sliver would leave play, it would clear all Extrinsic manaAbilities.

[silly freak]

that would make problems with multiple gemhide slivers, I think. wouldn't it be possible to store the mana ability at gemhide sliver, and when it leaves, not clearing the mana abilities but only removing that one?

[DennisBergkamp]

Hmm, I don't think multiple ones would be a problem... if one leaves play, the other will still be adding the ability. Currently, this is how state based abilities work anyway, it's a constant removing and adding of boosts (check GameActionUtil.java).

[silly freak]

oh, I understand. that wasn't clear to me. so basically an effect stops to apply when it isn't permanently added anymore, but the clear seems to happen after the effect was applied, so it's never seen by the game...

[DennisBergkamp]

Yes, something like that
Anyway, I'll wait to hear something from zerker before messing with this, he has a much better understanding of the manaAbilities (since he programmed them after all ).