Collectible Card Game Headquarters

Okey dokey, I'm trying to convert Profane Command to script because it's a monster piece of code (about 500 lines) that could be taken out when I get this right. So far I've got the script (that is, each of the charm's abilities work as expected). I've also expanded Sol's work on XCantBe0 so that X has to be larger than a specified SVar or integer (my stuff id separate from the XCantBe0 stuff for now, although they could probably be merged at some stage). This allows us to actually choose a value for X other than a targeted card's cmc (or whatever else) for cards such as Postmortem Lunge or Minamo Sightbender. Not sure when you might want to, but at least you'd have the option. (Edit: I suppose if the AI were smarter and you had a permanent that could boost power, then it might add a little extra to an activation of Minamo Sightbender so that you don't pump the target's power above X. )

Anyway, this would enable Profane Command to work as a scripted card IF I could find a way to get the Targeted$CardManaCost and Targeted$Amount of the specific Charm sa. At the moment Targeted$CardManaCost return the cmc of either of the last three abilities when I only need the cmc of the card targeted by the second choice. Likewise, Targeted$Amount needs to only return the number targeted by the last ability.

Any idea's on how to do this? Ideally what I'd want is something similar to StoreSVar for targeting that lets you set a specific SVar based on a specified expression.

I think what Targeted$ is doing is gathering up every target in an SAs chain of abilities, and using all of those to base its calculation off of. We can probably check each SA that actually uses the Targeted$ format and see if any of them actually need "all" of the targets. I'm not sure if bubbling up through the SAs is necessary (once you actually find some targets). I know certain Targeted$ things do rely on looking at the parent abilities targets.

Am I right in thinking that Charm adds the selected mode/s as a subability?

moomarc wrote:Am I right in thinking that Charm adds the selected mode/s as a subability?

Yes.

In that case I think I know how to get this right. Will see in the morning if it works, but should be able to use something like CharmTargeted$CardManaCost. Then at the start of CalculateAmount, before the method starts checking what type it is, check the subabilities for a param XCountRefsThis. Pass that sa (instead of the default ability) through the rest of CalculateAmount replacing CharmTargeted with Targeted (coded a bit more generically obviously).

Does that sound plausible?

moomarc wrote:In that case I think I know how to get this right. Will see in the morning if it works, but should be able to use something like CharmTargeted$CardManaCost. Then at the start of CalculateAmount, before the method starts checking what type it is, check the subabilities for a param XCountRefsThis. Pass that sa (instead of the default ability) through the rest of CalculateAmount replacing CharmTargeted with Targeted (coded a bit more generically obviously).

Does that sound plausible?

Sounds like it would work, I'd probably use different nomenclature for this than CharmTargeted (since non-charm SAs could actually use this beneficially) but I'm not sure what I would call it.

I'll probably go with SpecifiedTargeted or just SpecTargeted. Or perhaps SpecSATargeted is more descriptive?

If that works, all I have to do then is get the XNotLessThan<var> code to take two svars and use the biggest (I can't think of any situation where we'd need to compare more than two svars).

I'm quite happy with how the code is turning out. Nice and clean (at least I think it is). Two months ago this would still have been beyond me but I've learnt enough java now to learn quickly

moomarc wrote:I'll probably go with SpecifiedTargeted or just SpecTargeted. Or perhaps SpecSATargeted is more descriptive?

If that works, all I have to do then is get the XNotLessThan<var> code to take two svars and use the biggest (I can't think of any situation where we'd need to compare more than two svars).

I'm quite happy with how the code is turning out. Nice and clean (at least I think it is). Two months ago this would still have been beyond me but I've learnt enough java now to learn quickly

SpecificTargeted works for me. I wouldn't put SA in there since it would mean something a bit different to me. Glad to see some of the most brutal hardcoded cards disappearing.

  Just not getting anywhere here. The root charm ability has no subabilities as far as I can tell. A println outputs something like this for the root sa of Profane Command:

Code: Select all

Choose two - Target player loses X life; or return target creature card with converted mana cost X or less from your graveyard to the battlefield; or target creature gets -X/-X until end of turn; or up to X target creatures gain fear until end of turn. (They can't be blocked except by artifact creatures and/or black creatures.) Target player loses X life. Target creature gets -X/-X until end of turn.

which translates to

Code: Select all

Choice1 Choice2 Choice3 Choice4 Chosen1 Chosen2

That's the output from ability.getSourceCard().getSpells().get(0), but everything I tried seemed to come to the same conclusion. Trying to get the subability of that gets a NPE so I'm not sure what else to do short of changing how Charm works (which I'm not even considering an option really). Any more ideas? Anyone? Maybe?

Post your card and your diff of whatever source you changed, I'll take a look this afternoon.

The calculateAmount bit deteriorated into a mass of println's trying to find out what was happening, and I never got around to finalizing returning the larger of two calculated amounts (seeing as I was still trying to get the amounts). So I just need to get it back into some sort of "this should have worked" state then I'll post here. Thanks for looking into it.

We do already have LimitMax for finding the larger of two values (in the count structure). It looks like Ana Sanctuary (and other APC Sanctuaries) uses them.

Edit: Ugh. These are poorly named, since LimitMax actually finds the Minimum of two values, and LimitMin finds the Maximum of two values.

It doesn't seem like anything actually uses LimitMin, but that's the one you'd want.

friarsol wrote:We do already have LimitMax for finding the larger of two values (in the count structure). It looks like Ana Sanctuary (and other APC Sanctuaries) uses them.

Edit: Ugh. These are poorly named, since LimitMax actually finds the Minimum of two values, and LimitMin finds the Maximum of two values.

It doesn't seem like anything actually uses LimitMin, but that's the one you'd want.

For my purposes it was easier to just use

Code: Select all

                for (final String xGEvar : xGESplit) {
                    int amount = AbilityFactory.calculateAmount(sa.getSourceCard(), xGEvar, sa);
                    if (amount > xGE) {
                        xGE = amount;
                    }
                }

I named em that because they Limit to a max or min value.I swear ot made sense at the time.

Hellfish wrote:I named em that because they Limit to a max or min value.I swear ot made sense at the time.

I remember it making sense within context of its use. LimitMax limits the maximum value that will be returned by an xCount, it just happens to do that by returning the min.