How to see Cards added in SVN version ?

[whismer]

Since the primitive way was started recently now when you add cards in the svn version, we can't see the change in the cards.dat and don't know wich cards was added.

It said file was too big and you can just see a raw version without the green parts for the addition.

Can you list them when some cards are added (I know that in some case, it will be a boring work but I think it's can be cool for us and stop people like me to annoying you with future addition(

Whismer

[wololo]

Hmmm, you're right...
The issue is that new cards are now added in one single file, but the web interface of google says it's too big to show diffs...
http://code.google.com/p/wagic/source/b ... es/mtg.txt

My only suggestion would be that you use a svn client such as tortoise svn and use its own diff mechanism to see the results by yourself. I'm assuming you already have it installed if you have interest in the cards from the SVN, so just right click on Res/sets/primitives/mtg.txt, then "tortoiseSVN" menu, then "diff with previous revision" or something like that.

[bcdiscman]

This may be the same question, but I noticed cards in _card.dat such as "primitive=Berserk" now I know Berserk is not currently working in Wagic and when I look in the MTG.txt in the primitives folder - there is no Berserk coded.... Soooo how the heck can anyone tell which cards in which sets have actually been coded or not???

[wololo]

Same answer: by looking at primitives/mtg.txt
if a card is not in there, it's not coded yet.
the new "_cards.dat" files are not useful for that purpose anymore. They just give an exhaustive list of what cards are in which set, independently of them being handled by wagic or not.

[Psyringe]

Regarding the "diff" feature: If many people miss it, and can't use the diff feature of an SVN client, then we can split the file mtg.txt into smaller files. Onthe other hand, having all card code in one file is neat too (easy for maintenance). I'm still undecided on that one, so let your opinions be known. (I'll also have to discuss this with the other devs of course).

Regarding how to look up whether a card is implemented: As wololo already said, you do this in primitives/mtg.txt now. This should make the lookup actually easier, because previously you had to know which set a card belonged to, only then you knew in which file you could look it up. Now, all cards are coded in mtg.txt, so you can always check just this file - no need to find out the specific sets first.

[bcdiscman]

On the other hand, having all card code in one file is neat too (easy for maintenance). I'm still undecided on that one, so let your opinions be known

I actually like having all coded cards in one file (I keep a master _card.dat that has all coded cards from all sets already - it made it much easier to find cards as well as to find examples for card coding). I'm not sure how I feel about having cards that are not yet coded in the _card.dat's (seems to me that they should stay in the todo.dat files so people can work on getting them coded into wagic, in the new system, it seems more likely that they will be forgotten).

[wololo]

in the new system, it seems more likely that they will be forgotten).

actually it's the other way around. we still have a todo, it's called Res/sets/mtg_todo.dat and contains all the missing cards.
With this new system, whenever we add a new card, we have the guarantee that it will immediately be added to all sets that should have it

[bcdiscman]

actually it's the other way around. we still have a todo, it's called Res/sets/mtg_todo.dat and contains all the missing cards.
With this new system, whenever we add a new card, we have the guarantee that it will immediately be added to all sets that should have it

That's is a great idea, I just found the mtg_todo.dat and I totally agree that having master todo list is a smarter way of doing things.

[wololo]

You can thank psyringe for that, I was against that idea for a long time

[Psyringe]

You can thank psyringe for that, I was against that idea for a long time

... but for perfectly valid reasons, so no need to blush.

bcdiscman: I should update the documentation (on miki) to reflect the new file and data structure, but haven't found the time for that yet (sorry for that). In the meantime, if you have questions or run into problems, just ask.