eqPump (was VanillaEquipment) keyword

[mtgrares]

Some people can raise to the level of a lead programmer, others have to settle for jr. programmer.

The line, "There are no small actors, only small parts" can be applied to programming, "All programming is hard whether it is a little or alot of code."

I think you are doing a fine job. If it helps, I don't understand any of cards.txt keywords.

[Chris H.]

I think you are doing a fine job. If it helps, I don't understand any of cards.txt keywords.

`
Thank you Rares.

[Chris H.]

I think that the process of converting vanillaEquip to eqPump is now finished. The format at this time is:

eqPump {mana cost}:[p/t][/][k]

mana cost is manditory
power/toughness is optional
keywords are optional

Must contain at least the p/t boost or the keyword.

multiple keywords are separated by the "&" character.

The card description must be included in the 4th line as this keyword will not at this time build the description for us.

Here are three examples:

Bone Saw
0
Artifact Equipment
Equipped creature gets +1/+0.
eqPump 1:+1/+0

Gorgon Flail
2
Artifact Equipment
Equipped creature gets +1/+1 and has deathtouch.
eqPump 2:+1/+1/Deathtouch

Peregrine Mask
1
Artifact Equipment
Equipped creature has defender, flying, and first strike.
eqPump 2:Defender & Flying & First Strike

EDIT:

I updated the AI and the computer will now attempt to target a Loxodon Punisher if one is in play.

[Chris H.]

I would like to thank everyone for their help.

I considered turning the keyword's data inputs into SVars. I am at this time undecided. Would this make it easier for the non-programmer to understand? It is something to think about.

I also considered adding in spell and stack descriptions, but they would have to be added to the utils in CardFactoryUtils. Currently, the spell descriptions are located in the cards.txt entry and I think that we should keep it this way for the moment.

There appears to be a number of possible equips that would have to be coded as a separate card object. So, I think that we should keep the separate CardFactory_Equipment.java file in case someone wants to write the code for an additional art equip card.

I will now clean up the CardFactory_Equipment.java file. Afterwards, I will place the broom and mop back into the closet.

[Rob Cashwalker]

SVars for the keywords aren't necessary, unless and until you try to add a sentence-long keyword, as some of our keywords are.... It's perfectly legible as "k1 & k2 & kN".

[zerker2000]

There are no small actors, only small parts

Actually, I'm pretty sure you've got that backwards(or my drama teacher, who often uses it to make a point). After all, extended character development can(and should) indeed be done for any size role.

[Chris H.]

I updated the AI:

Updated AI

[DennisBergkamp]

Oops! It seems like I overwrote many more changes than I had originally thought, Chris Anyway, I think I've reverted most of them now...

EDIT: It wasn't just me though, it seems Jim also overwrote a lot of changes in R655 I guess we just have to be very careful when committing cards.txt.

[Chris H.]

Oops! It seems like I overwrote many more changes than I had originally thought, Chris Anyway, I think I've reverted most of them now...

EDIT: It wasn't just me though, it seems Jim also overwrote a lot of changes in R655 I guess we just have to be very careful when committing cards.txt.

`
That is OK, I am surprised that we do not make more mistakes.

I am terrible at trying to resolve conflicts. I guess with time we all will adapt. If anyone has some good ideas we would gladly listen and learn.

[jim]

It wasn't just me though, it seems Jim also overwrote a lot of changes in R655 I guess we just have to be very careful when committing cards.txt.

Oops. I thought I was being careful NOT to do that -- sorry, Chris.

Is there a good way to avoid this? I'm still learning SVN, but what I have thought was right was to do "Update to HEAD" before doing a commit, and then making sure to take care of the conflicting files (and cards.txt always conflicts). Do you have a better process?

[Chris H.]

Oops. I thought I was being careful NOT to do that -- sorry, Chris.

Is there a good way to avoid this? I'm still learning SVN, but what I have thought was right was to do "Update to HEAD" before doing a commit, and then making sure to take care of the conflicting files (and cards.txt always conflicts). Do you have a better process?

`
I have two work spaces. One for the SVN which I keep up to date with the new revisions. The second work space is where I do my work and run my tests. When I feel that I have a small submission ready to go I:

Switch to my SVN only workspace.

I push the Synchronize SVN (Workspace) button and I then update all incoming changes to my local copy.

I then quickly add in my few additions to my local copy and I re-Synchronize SVN (Workspace).

At this point there is usually no conflicts and I can safely commit my outgoing changes.



While I feel that my system works for me I am open to other people's ideas on how to make this easier for us all.

[Rob Cashwalker]

The best thing to do is to not commit more than one file at a time. And I nominate Chris to be the master of the SVN cards.txt.

When I add keywords, I commit the code portion, but only post the cards.txt to be added by Chris, because by the time I've finished the code, the cards.txt has been revised numerous times. (while I'm working on my code, I generally don't pull updates until I'm done)

[DennisBergkamp]

Is there a good way to avoid this? I'm still learning SVN, but what I have thought was right was to do "Update to HEAD" before doing a commit, and then making sure to take care of the conflicting files (and cards.txt always conflicts). Do you have a better process?

This is exactly how it should be done (in the Synchronize With Repository view, "Edit conflicts" - in the text compare, just make sure the left local side is correct - and hit "Mark as merged" when done). What does apparently happen though is that sometimes when a lot of changes are done on cards.txt earlier in the file, they can easily get missed. It's happened to me numerous times already, but from now on, I make sure I haven't missed a single "red difference spot" in the text compare.

I don't agree with making only one of us "master of cards.txt", because there's just too many changes that have to be done on it, all of the time. It's possible to do right, we just have to be careful.
And it's interesting, cards.txt is actually the easiest file to merge conflicts (it doesn't have Eclipse insert the weird "<<<<mine>>>>>" text parts).

[Chris H.]

The process of converting cards from code objects to implemented via keywords may be creating a challenging situation for us. A lot of cards have been changed over the last several months.

With the eqPump keyword, I moved the affected cards.txt entries up to the top of cards.txt and it looks like they survived the other merges. I kept the edited enPump and ab/spGainLife cards.txt entries at there original location and they appear to be the ones affected.

So, I guess that in the future all new cards.txt entries and all EDITED OLDER cards.txt entries should be placed at the top of cards.txt file.

[jim]

The process of converting cards from code objects to implemented via keywords may be creating a challenging situation for us. A lot of cards have been changed over the last several months.

With the eqPump keyword, I moved the affected cards.txt entries up to the top of cards.txt and it looks like they survived the other merges. I kept the edited enPump and ab/spGainLife cards.txt entries at there original location and they appear to be the ones affected.

So, I guess that in the future all new cards.txt entries and all EDITED OLDER cards.txt entries should be placed at the top of cards.txt file.

This might have helped, but in truth, I think I just needed to be more careful, especially with that file. I was in a hurry yesterday morning and didn't look all the way down. Thank you Dennis for cleaning up my mess, and I apologize again for making more work for everyone.