setStackDescription and targeting

[Chris H.]

I have noticed that the phrase that we would normally set with setStackDescription() is sometimes ignored and it fails to show up. I think that it may have to do with the targeting code replacing the stack description with it's own phrase. What we then see is this:

1. {Card Name} - targeting {Target Selected}

For example, I recently tried to add the two descriptive fields to Lightning Bolt. This spell uses Rob's updated spDamageTgt code. I modified cards.txt to this:

Code: Select all

Lightning Bolt
R
Instant
no text
spDamageTgtCP:3:*Lightning Bolt deals 3 damage to target creature or player.*:*Lightning Bolt - deals 3 damage to target creature or player.*

`
and yet when I cast this spell, I see this on the stack:

1. Lightning Bolt - targeting Computer

I thought that I found a section of code in CardFactory.java which had a comment in relation to this situation and the code may have included a work around that could be used to over-ride this built-in stack description.

And now I can't find this code section … I wish that I had saved it as a note.

[DennisBergkamp]

I think this is the way it works.... if a card is targeted, the default stackDescription that shows, like you said is: "{Card} - targeting {target}".

However, if you would do a card.setStackDescription(textString); (even to spells that are targeted)
textString would show up as the stackDescription.

I'm not sure how spDamageTgtCP is coded exactly, but I bet it merely uses setDescription(text) instead of setStackDescription(text), so changing the text right after the keyword will still yield the same result, "{Card} - targeting {target}."

[Chris H.]

However, if you would do a card.setStackDescription(textString); (even to spells that are targeted)
textString would show up as the stackDescription.

`
While studying the spDamageTgt keyword it appears to use the setStack string included with the keyword or it will build it's own if a string is not included. In essence what Rob has been working on is something like this:

Keyword:{data}:{spell description}:{stack description}

Let me take a look, OK, spDamageTgt is using this to build a stack description if one is not included:

Code: Select all

DamageTgt.setStackDescription(card.getName() + " - deals " + NumDmg[0] + " damage.");

`
So, I guess that if we change the "DamageTgt" with "card" we would no longer get the standard built targeting stack description but would get the one being built. So, I guess that the answer in these types of cases is to only use:

card.setStackDescription()

I will try it out and see how it works. Thank you for providing the answer.

[Chris H.]

However, if you would do a card.setStackDescription(textString); (even to spells that are targeted)
textString would show up as the stackDescription.

`
Hmm, I tried card.setStackDescription(String) and get the error:

The method card.setStackDescription(String) is undefined for the type Card

I looked through the CardFactory.java file and found the setText area, but there appears to no code that would do the same thing with the stack description.

I am starting to suspect that there may not be code that we currently can use to change the stack description for targeted spells. I hope that I am wrong and just have not yet figured it out.

Or I may not have tracked this down to the appropriate code section. Somewhere the targeting string is being built and then written to the stack window.

[Rob Cashwalker]

I always wondered why I never saw any of my stack descriptions...

[Chris H.]

I always wondered why I never saw any of my stack descriptions...

`
Yeah, I feel your pain. I used your keyword code as a template when I updated the loseLifeGainLife keyword to include these two fields ... at first I thought that I must have made a newbie's error.

[zerker2000]

Err, that's because the method is SpellAbility.setStackDescription, i.e. in the spDamg parsing code. In fact, a card theoretically cannot have a stack description, as the only things that can be on stack are spells and abilities, so what you're looking for would be "card.getSpellAbility()[0].setStackDescription".

[Chris H.]

I tried zerker's suggestion and it did not override the built in {Card} - targeting {Target} stack description.

I found something interesting. The spell Erratic Explosion requires you to choose a target. The stack gets the standard built in {Card} - targets {Target} but this spell also creates a small message window stating:

Erratic Explosion causes {damage} to {target}

so, this is another way to display the information. I'm not suggesting that we should standardize on this format.

I found a section of code in SpellAbility.java which creates the {Card} - targeting {Target} stack description. I considered placing the assignment statement inside of a test.

Code: Select all

if(getStackDescription().length !> 0)
  setStackDescription(getSourceCard().getName() +" - targeting " +p);

`
But… right above this we have similar code which handles morphed creatures. So, things are starting to become more complicated than I had originally imagined.

It may be best to keep things the way they are? And the Erratic Explosion spell above may reveal the name of a morphed creature. As such, it may have to be special cased to prevent revealing the morphed creature's name.

[Rob Cashwalker]

Err, that's because the method is SpellAbility.setStackDescription, i.e. in the spDamg parsing code. In fact, a card theoretically cannot have a stack description, as the only things that can be on stack are spells and abilities, so what you're looking for would be "card.getSpellAbility()[0].setStackDescription".

Yeah, we're using the setStackDescription for the abilty object before it is added to the card.
the getSpellAbility(0) would only modify the first spellAbility.. which on some cards wouldn't always be the case.

[zerker2000]

Not always the case? Isn't a(nonland) card's first SpellAbility always the corresponding Spell?

[Rob Cashwalker]

Not always the case? Isn't a(nonland) card's first SpellAbility always the corresponding Spell?

Usually for an instant or sorcery, yes. But let's say its a pump spell with Cycling, then there are two ability objects. When you select the card to be played it asks you to choose the behavior. If you choose cycling you don't want the stack description to read "target creature gets +2/+2"....
Creatures and other permanents have a default ability plus whatever ability is printed. The default ability is to actually play the card. Any additional ability objects become active once it's in play.

In the long run, I'm cool with some default stack descriptions. I was sort of debating the usefulness of the wordy descriptions I have used in my recent submissions.

[zerker2000]

Yes, so wouldn't the First one always be the spell?
I agree wordy stack descriptions are probably not needed, considering the card is visible on mouseover(think Stack in paper magic). Could that be expanded so that if the target card is moused over, it is the one displayed?

[Rob Cashwalker]

no, cycling is not the first ability on the spell, it's more likely to be second.If I play the cycling ability, why should the stack show a pump description?

[zerker2000]

I think there is a misunderstanding. If I fetch the card's first SpellAbility, and set the description for that, how would that affect the second?

[Rob Cashwalker]

It's the timing of it then.

When the cards are built in the factory, the stack descriptions for each ability are done the way we would like.

Later, when you play the abilities, the original stack description doesn't seem to appear as we would expect. Either it's being modified or it's not used when describing the action. A default "card targeting another card" description is showing.

Modifying the first ability blindly isn't going to change anything, much less the fact that the first ability may not always be the correct one needing to be modified.

I didn't want to state the obvious - just search for all points in the code where setStackDescription is called outside of a CardFactory file, and compare to calls to getStackDescription. Then cross reference with any code that puts an ability object on the stack, to see if it is tweaking the description once it's on the stack.