delete doDrawBack?

[Sloth]

I converted Dream Cache to newer style drawback and I think it was the last card to use the old function. Can we delete doDrawBack in CardFactoryUtil?

[slapshot5]

I say yes. Sol and I were converting a bunch of these a month ago or so. This was one of two leftovers that couldn't be done then. (The other has since been converted I think.)

Sol may have a comment, but my guess is he'd be all for removing that code. It's not like there's AI in there we need to keep.

-slapshot5

[friarsol]

Yea Dream Cache was the only thing left on the list. So nuke away. As far as AFs goes, we can change the last few lines of Resolve() from (generally)

Code: Select all

if (af.hasSubAbility()){
   Ability_Sub abSub = sa.getSubAbility();
   if (abSub != null){
      abSub.resolve();
   }
   else
      CardFactoryUtil.doDrawBack(DrawBack, 0, card.getController(), card.getController().getOpponent(), card.getController(), card, tgtCards.get(0), sa);
}


to

Code: Select all

AbilityFactory.resolveSubAbility(sa);

[Rob Cashwalker]

{sniff} so sad to see it go...

[friarsol]

{sniff} so sad to see it go...

One of these days Rob is going to be yelling at us to get off his lawn.

[slapshot5]

{sniff} so sad to see it go...

One of these days Rob is going to be yelling at us to get off his lawn.

I wish I could just click "Like" on this post.

[Sloth]

Can't we do something like a super resolve function now, to not repeat so much code. It should do just the following things:

1. check condition (and maybe fizzling and unless costs)
1a. if true let it resolve (in the corresponding AF).

2. go to super resolve of next subability.

[friarsol]

Can't we do something like a super resolve function now, to not repeat so much code. It should do just the following things:

1. check condition (and maybe fizzling and unless costs)
1a. if true let it resolve (in the corresponding AF).

2. go to super resolve of next subability.

Yea it's definitely a good idea to go through and simplify as much as the common resolution code as possible.

[Rob Cashwalker]

I

{sniff} so sad to see it go...

One of these days Rob is going to be yelling at us to get off his lawn.

I don't get it...

[Sloth]

Can't we do something like a super resolve function now, to not repeat so much code. It should do just the following things:

1. check condition (and maybe fizzling and unless costs)
1a. if true let it resolve (in the corresponding AF).

2. go to super resolve of next subability.

Yea it's definitely a good idea to go through and simplify as much as the common resolution code as possible.

After taking a look at the structure, I think I have to pass implementing this. I can't find a way to add something before the resolve without detroying the nice structure of the ability factory. I just can't code so elegantly. Unless someone gives me a hint or batch of code I can start from I'm gonna drop this.

[friarsol]

After taking a look at the structure, I think I have to pass implementing this. I can't find a way to add something before the resolve without detroying the nice structure of the ability factory. I just can't code so elegantly. Unless someone gives me a hint or batch of code I can start from I'm gonna drop this.

The hooks need to happen on the MagicStack side, instead of calling sa.resolve() there we would call need to be a call to a AF.resolve(sa) which would do as you suggest, pulling out the appropriate conditional checks, as well as looping through each of the subAbilities afterwards and resolving those. If the SpellAbility didn't have an attached AF, then no need to do any of the AF specific things, and we could just call sa.resolve() straight up from there.

[Sloth]

After taking a look at the structure, I think I have to pass implementing this. I can't find a way to add something before the resolve without detroying the nice structure of the ability factory. I just can't code so elegantly. Unless someone gives me a hint or batch of code I can start from I'm gonna drop this.

The hooks need to happen on the MagicStack side, instead of calling sa.resolve() there we would call need to be a call to a AF.resolve(sa) which would do as you suggest, pulling out the appropriate conditional checks, as well as looping through each of the subAbilities afterwards and resolving those. If the SpellAbility didn't have an attached AF, then no need to do any of the AF specific things, and we could just call sa.resolve() straight up from there.

Thanks Sol. I commited the change. It was really easy with your help.

[friarsol]

Thanks Sol. I commited the change. It was really easy with your help.

Wow that took no time at all. Little things like this will keep our structure clean and the copy-pasted code to a minimum.

[Sloth]

My next plan is to add unless costs to this resolve function. The only difference in the existing unless cost mechanic in AF counters is, that the unless cost is checked for each target of the counterspell. There is no counter ability that allows multiple targeted/defined spells and has an unless cost (and the prompt for the human isn't really worked out to support this).
Is it ok to pull out the unless cost from AF counterspell and put an all or nothing unless cost in front of sa.resolve() (like a Condition)? Subabilities would still resolve (for cards like Offering to Asha).

[friarsol]

My next plan is to add unless costs to this resolve function. The only difference in the existing unless cost mechanic in AF counters is, that the unless cost is checked for each target of the counterspell. There is no counter ability that allows multiple targeted/defined spells and has an unless cost (and the prompt for the human isn't really worked out to support this).
Is it ok to pull out the unless cost from AF counterspell and put an all or nothing unless cost in front of sa.resolve() (like a Condition)? Subabilities would still resolve (for cards like Offering to Asha).