Fix for Flowstone Giant suicide

[Rob Cashwalker]

What's the difference between Ability and Ability_Activated? When to use one over the other? When should it be used as the declared type and not just the constructor?

ie:

Code: Select all

SpellAbility ab1 = new Ability()

vs

Ability ab2 = new Ability()


Why the inconsistency in mana costs - "0" vs ""?

I'm trying to implement a targeted pump ability keyword. But such abilities are sometimes (rarely) mana-only, sometimes mana + tap, and sometimes tap-only. So I've decided to allow the keyword to include a "T" at the end of the cost (or the only cost) and replace it before passing the rest of the mana cost. But that leaves me at having an if block with the exact same logic for each ability, however the abilities have to be declared differently. And eclipse is throwing all sorts of syntax errors at me trying to do this. I'd rather not devise three different sets of keywords for each type of cost....

TgtMKPump - Targeted Mana-only Keyword Pump
TgtTKPump - Targeted Tap-only Keyword Pump
TgtMTKPump - Targeted Mana+Tap Keyword Pump

TgtMPTPump - Targeted Mana-only P/T Pump
etc.....

However I've been working in my head how I could revise the KPump, PTPump and PTKPump to use a single keyword, so that in the end there would only be one form of pump keyword for each type of cost... but this is still not quite what I had in mind. Any thoughts?

[mtgrares]

What's the difference between Ability and Ability_Activated?

None really, I probably created Ability first and then Ability_Activated later. Conceptually I was thinking that Ability would be different than Ability_Activated, since not all abilities are activated, but it doesn't matter since Ability isn't used for cards like Thieving Magpie.

Code: Select all

SpellAbility ab1 = new Ability()

vs

Ability ab2 = new Ability()

Are both the same as far as I'm concerned. As long as the superclass is SpellAbility, it is fine. Ability, Ability_Actviated, and the others were created to make things clearly conceptually and to reuse the same code for different cards, but you could just extend SpellAbility to do the same thing.

Why the inconsistency in mana costs - "0" vs ""?

It is just an inconsistency, all of the code probably needs to be changed to one way or the other.

However I've been working in my head how I could revise the KPump, PTPump and PTKPump to use a single keyword.

I can't think of any way of combining them. I think it is fine to create 5 or more keywords for pumping, that way each keyword does one thing and does it clearly, instead of an uber-keyword that is hard to parse correctly.

[DennisBergkamp]

None really, I probably created Ability first and then Ability_Activated later. Conceptually I was thinking that Ability would be different than Ability_Activated, since not all abilities are activated, but it doesn't matter since Ability isn't used for cards like Thieving Magpie.

I'm confused, because I did use Ability for Thieving Magpie

Code: Select all

final String player = c.getController();
   
     if (c.getAttack() > 0)
     {
        Ability ability2 = new Ability(c, "0")
        {
           public void resolve()
           {
           
              AllZone.GameAction.drawCard(player);   
           }
        };//ability2
         
        ability2.setStackDescription(c.getName() + " - " + player + " draws a card.");
        AllZone.Stack.add(ability2);
     }

[GandoTheBard]

Ok without having looked at any of the pump code here is my humble suggestion for making Pump a single Keyword.

Use subkeywords as parameters.

Pump (string keyword, int numTo, int numPo) {code goes here.}

[Rob Cashwalker]

I can't think of any way of combining them. I think it is fine to create 5 or more keywords for pumping, that way each keyword does one thing and does it clearly, instead of an uber-keyword that is hard to parse correctly.

It's actually quite simple - After splitting the keyword by the ":", the first half is the keyword and mana cost, the second half (p/t/k), the second half is split by the "/". Then count the resulting elements in the string array. If there's only one element, then it's a keyword pump. If there are 2 elements, then it's a P/T pump. If there are 3 elements, then it's a P/T/K pump.

This can be done with pretty much a single set of code for the self-pumpers because they all basically have the same fundamental code. Also, a self-pumper is rarely a tap ability. If it was, the computer couldn't use it, because it only makes sense to use the ability during combat, after declare blockers step, the creature can tap or become tapped and combat damage still goes as normal.

While the targeted pump ability will share the same basic functions between the different pumps, the AI changes drastically. A keyword-only pump chooses the best creature that doesn't already have the keyword. The P/T-only pump would choose the best creature, with preference to ones with keywords. I guess the P/T/K pump would probably be same as the keyword-only pump....
(Which just got me thinking, I know Lifelink was just added... does it stack? Lifelink + Lifelink = Rhox War Monk when exalted by Battlegrace Angel, resulting in double the life gain. It's not critical, it's still amazing it got added....)

Ok without having looked at any of the pump code here is my humble suggestion for making Pump a single Keyword.

Use subkeywords as parameters.

Pump (string keyword, int numTo, int numPo) {code goes here.}

In theory, that makes perfect sense. In practice, the code gets very messy very quickly with a lot of if blocks that span so many lines it gets hard to keep track of which condition you're working the code for. And I'm not sure how variable scope is maintained, because eclipse has been pestering me claiming that variables that I've declared and "finalized" a couple if blocks up "can't be resolved". The self pumping code seems to not have any issues, and the only glaring difference is the nesting of if blocks to handle the different keyword modifiers (in my simple case, the mana cost containing a "T" and the possibility of not having any actual mana cost).

I should probably maintain as much model code as possible without trying to optimize the size of the code. Instead of trying to define the three variant abilities and then apply it to the card after the if blocks, at the end, I should apply the ability in the same if block as the ability is defined. Instead of trying to use a single EOT command, I should replicate the EOT command code inside of each ability.

[DennisBergkamp]

(Which just got me thinking, I know Lifelink was just added... does it stack? Lifelink + Lifelink = Rhox War Monk when exalted by Battlegrace Angel, resulting in double the life gain. It's not critical, it's still amazing it got added....)

No it doesn't, but it's on my TODO list
I don't even think it's too difficult to do, just gotta use a for loop instead of the if.

[Rob Cashwalker]

See, the presence of that one keyword disrupts everything - that would be the only instance where the AI should want to double-keyword-pump a creature.... Probably with very few others.... Probably not worth making an exception case for it though....

[DennisBergkamp]

But, are there any lifelink KPumps out there? I don't think so, although maybe there will be in the future...

By the way, last night I added the functionality of gaining another x life if multiple instances of Lifelink exist on a card.
Testing this was interesting, I figured I could just edit Brion Stoutarm to look like this temporarily in cards.txt:

Brion Stoutarm
2 R W
Legendary Creature Giant Warrior
no text
4/4
Lifelink
Lifelink

This, however, did not do the trick. Brion still had a single instance of lifelink in game.
So, I just implemented Battlegrace Angel to test out the functionality. It was fun, I had 4 Battlegrace Angels in play, which gave me an 8/8 flyer with quadruple lifelink, giving me 32 life per turn!! I will also test this with Rafiq of the Many, to see if I will really get 72 life per attack with him added