Note: I checked all changes manually, so in the cases where the value *has* to be different for the card to work (e.g.Covetous Dragon), I left the values as they were. In these cases I added a comment to the card code which notes why the values need to be different, so that no one else breaks the card by "correcting" them.
Note 2: You may have noticed that I used a fixed sequence of lines for all cards. That was a byproduct of the file unification process, but I think it's also rather useful. Above the "text=" line are the lines that we need to code (abilities=, target=, auto= etc.). Below the "text=" line are the fixed values (mana=, type=, power= etc.) which we only need to touch if either the card gets errata'd, or we need to do some tricky coding (e.g. Covetous Dragon). So, in other words, everything below the "text=" line should be okay now in both files, and doesn't need to be checked when implementing or debugging a card.
Also re-enabled the cards which had their names changed to make them work. (Example: the card code for "Vorosh, the Hunter" only works if thecomma is removed from the card's name.) These cards are a maintenance hazard since they a) require changes to _cards.dat if their names are corrected later, b) disrupt translation, and c) cause problems for external tools like MTG Studio which have the correct names in their database. However, only a few cards are affected by this, and I didn't want to remove them because Dr. Solomat has invested quite some effort top make them work. I added comments to these cards in mtg.txt as well as in the respective _cards.dat files to reduce the risk of further maintenance problems for these cards. In any case changing a card's name to make it work should be considered as a makeshift solution at best, please try to prevent it when possible.
- Card Primitives system. Check Royal Assassin in RV, 10E, M10
- Please review, is sets/primitives a good directory? Should we rename MTGCard into "CardPrint"?
- Unfortunately for now it is not possible to "override" a Primitive. A card that links to a primitive but also defines new "values" will create its own data and ignore the data in the "linked" primitive for the time being. I hope to solve that at some point...