OS:
Win 7
Cockatrice version:
dab7316 (2017-01-19)
There is a feature to allow the quick creation of tokens from cards that create them. I also notice that a morph token exists, and that a face-down card has its own custom options, but that a morph token is not among them. I think this would be a nice addition.
I don't think this fits with the way morph works. You need to play the actual morph card face down for the game to track it properly
That's what I'm talking about. The cards I was using had megamorph. I'd play them face-down but couldn't create a morph token from the card.
I think there's a bit of verbiage confusion here... You wouldn't make "morph tokens" from a face-down creature. Are you asking if we could add a feature where face-down creatures could be displayed with the morph or manifest card face, ala the Khans of Tarkir Morph token and the Fate Reforged Manifest token?
Basically, yes. But those tokens are already in cockatrice. You can play a card face down, create a morph token, exactly like that manifest card but for morph, and attach it to the face down card. I'm simply suggesting to add a function to create that token faster, as you can with other tokens
Ah, I understand now. It might make a better user experience to show that token directly on the card back, if possible.
I agree
But there are several options in that case - morph, manifest, or simply face down
I'm not sure how feasible that change would be. Given the low impact it's probably not worth much..
i think giving face-down cards the ability to produce morph and manifest tokens would be easy, since most cards produce their own tokens now.
having the cards automatically come into play with their appropriate token or having the back of the card show the appropriate token would be harder
If we just add morph/manifest/megamorph to the related cards they will see the create related cards menu!
If I recall correctly the right click options on face down or face up cards is the same... so you can play face down and right click to quickly create a morph etc. token to cover your card.
Sounds like the simplest and most convenient option at the same time.
No fancy automation needed in my opinion!
Now that I think about it, I'm wondering why we don't have that already... we also do link energy token for example.
@Psithief is there a way to expand your script to account for that? It should be phrases like Morph {2}, Morph {2}{R}, Megamorph {1}{G} or Megamorph {4}{W} in the text field of mtgjson.
For manifest, it's just the keyword...
Pictures: http://magic.wizards.com/en/articles/archive/arcana/tokens-tarkir-2014-09-10 and http://magic.wizards.com/en/articles/archive/arcana/tokens-reforged-2015-01-07
@cloomis4234 does this accomplish what you had in mind?
You can download this tokens.xml file (right click and save) and overwrite your current one to give a right click on a face-down morph/manifest card a try!
a face-down card has its own custom options
What do you mean with this statement?
A card should have the same right click menu for the real card, and the same card placed face down!
The quickest place to solve this is by adding the tokens manually to your deck. Treating morph/manifest as a token is going to cause semantic problems.
It's not a card and it's not a token. It's just a _state_ that an object is in. I included it as an option for people that want to use it, but it cannot receive the same support because Cockatrice can't do this through its token support.
But there are several options in that case - morph, manifest, or simply face down
This is the right solution, let's not try to hammer square pegs into round holes.
but it cannot receive the same support because Cockatrice can't do this through its token support
Why not? What's the problem here?
Half of trice players don't even know it's not a token and expect it to work the same. We have already support for some other non-tokens - which I really like and think is useful/important for the players! Even wizards announces them with tokens and included them into booster the same as tokens to make the confusion perfect. But that doesn't matter too much anyway.
I know that we had no reverse-related support back then in ktk (first version with support: 2016-02-03, ktk release: 2014-09-24) and I'm pretty sure otherwise the issue tracker here would have been flooded with "token" requests! 100%.
I think it's a great way to handle it the same and as @tritoch showed it can be automated as well!
To have it work properly, the card would have to essentially 'transform' like existing cards do, with the face-down card being attached to the Morph or Manifest object.
But that only happens if the card entry isn't tagged with <token>1<token>, and removing that from Morph and Manifest means they end up in the main deck if added in the deck editor.
That's introducing a bug because we don't have a separate element for Morph and Manifest.
@Psithief We basically discarded the same/a similar idea in this issue because "I'm not sure how feasible that change would be. Given the low impact it's probably not worth much.."
We just want an easy "workaround" people are used to. And it actually fits quite good to handle it like tokens. So people can chose if they want to create a "overlay" or not. Everybody used to do so (manually create TOKEN) when they got played more, so why not make it easier for them and uniform to all other related cards. (we don't call the feature related token btw ;) )
(we don't call the feature related token btw ;) )
Actually, the context menu for every card just says "token: " now. So yeah, you do. :|
If we're adding support for one new attribute in the tokens.xml file (Cockatrice/Magic-Token/pull/20), we can add another, right?
Indeed. With the new entries in the first level right click menu there pops this term up.
I was referring to the initial implementation for sure.
But nobody is saying it shouldn't be "Related card: " instead. I would like that. :)
Melt or flip/transform cards are also linked as reverse-related for a good reason... also no tokens.
If we're adding support for one new attribute in the
tokens.xmlfile (Cockatrice/Magic-Token/pull/20), we can add another, right?
We're thinking about expanding one, yes.
So what's your suggestion for a new one? How should it look and how would it help?
It's a flag. Perhaps attach=1 or simply attach. (Does XML allow attributes without values?)
If it's present, the card is created and the object that generated it is attached, i.e. the same code path used for <related> elements that point to non-tokens.
It would go on all the Morph <reverse-related> tags, but only three of the Manifest cards (Cloudform, Lightform and Rageform).
It would be better support for the cards with living weapon, too.
We have something like the attachments you described for transform and meld cards. But it's handled inside Cockatrice. So this would generalize that basically.
(btw I'm not sure if it's a good approach to have this automated attachment for meld+transform... meld "source cards" should get exiled and transform cards you might have to flip over and over again (--> werewolves) which causes problems, e.g. see below)
Worth noting is that it would be a bit weird to use, just tried it with transform again.
Since morph cards are flipped quite frequently face up it's a bit of a pain to unattach (the real card at the bottom - not the token!) to be able to remove the "overlay" again.
It also includes more automation on the battlefield, which we talked about at one point should not be included too much since we are simulating a real game on a table where you have to do things manually (and to be open for as many games!)
Since morph cards are flipped quite frequently face up it's a bit of a pain to unattach (the real card at the bottom - not the token!) to be able to remove the "overlay" again.
If you drag the Morph anywhere off the battlefield (be it graveyard, hand, exile, library or sideboard), the attached card stays behind, like all attachments do.
Cockatrice has a lot of weird things about it. You can't play face-down cards to the stack either.
If you drag the Morph anywhere off the battlefield (be it graveyard, hand, exile, library or sideboard), the attached card stays behind, like all attachments do.
This is actually pretty sweet, didn't realize that before. I hope people know about that...
Another downside is that if somebody burns your morphed card with an attached morph-overlay you can't simply destroy both. you have to "kill" them twice. First to get rid of the attachment, then remove the card.
Because of thing like that I prefer a more manual and flexible approach.
Positive thing with attached would be, that you can just double tap to declare attackers and don't need to make sure both are tapped or confuse anybody because you just tapped the overlay.
Cockatrice has a lot of weird things about it. You can't play face-down cards to the stack either.
Yeah I know, missing play face down to stack issues is filed since ages: https://github.com/Cockatrice/Cockatrice/issues/403
But that only happens if the card entry isn't tagged with
<token>1<token>, and removing that from Morph and Manifest means they end up in the main deck if added in the deck editor.
Has create related obsoleted this functionality? Why do you need to add tokens to your deck?
What's wrong with seeking to avoid breaking existing functionality? Just because we've provided a narrower alternative method? For most users, yes, it has, but not all.
Just as an example, I can think of a player with an Ixidron wanting to be able to hand out Morph tokens to players through the Create a pre-defined token menu.
As Ixidron enters the battlefield, turn all other nontoken creatures face down. (They're 2/2 creatures.) Ixidron's power and toughness are each equal to the number of face-down creatures on the battlefield.
Just as an example, I can think of a player with an Ixidron wanting to be able to hand out Morph tokens to players through the
Create a pre-definedtoken menu.
That would even be easier and faster if he can create a related card (--> Morph overlay) directly from Ixidon without the need to add it to his deck first. ;)
There are keyboard shortcuts for the first few pre-defined tokens, so preparation is still faster.
And Ixidron does not morph itself.
~@tritoch @tooomm~
~At the end of the day, I simply refuse to break Cockatrice with poorly thought-through edits to tokens.xml.~
But that only happens if the card entry isn't tagged with
<token>1<token>, and removing that from Morph and Manifest means they end up in the main deck if added in the deck editor.
How about we start using different values here for different types of tokens, and then work on having Cockatrice handle them differently? I can think of 2 major types of 'tokens' maintained by tokens.xml. Traditional tokens are your Thopters and Snakes. Non-traditional tokens are representations that aren't currently well-handled by Cockatrice: Transform, Morph, Manifest, Meld (and maybe Flip.) We could start by giving these representations a <token>2</token> and then have Cockatrice display these differently - either by immediately attaching them like Meld or just having them display instead of the original card. They would also not be considered for Create another token.
I did a check and in current clients, any value for <token> is handled the same as "1". We can extend using that key.
So if we adopt these proposals the XML looks a bit like this:
<card>
<name>Germ</name>
<set picURL="http://media.wizards.com/2016/bn8f9t2zc_C16/byg00olvZx_EN.png">C16</set>
<set picURL="http://media.wizards.com/2015/c15_9dsm28ccakCDSk2/en_UF6tUBntoI.png">C15</set>
<set picURL="http://media.wizards.com/2015/mm2_9vgauji43t9a/en_dKOkeEXQ9V.png">MM2</set>
<set picURL="http://magiccards.info/extras/token/commander-2014/germ.jpg">C14</set>
<set picURL="http://magiccards.info/extras/token/mirrodin-besieged/germ.jpg">MBS</set>
<color>B</color>
<manacost></manacost>
<type>Token Creature — Germ</type>
<pt>0/0</pt>
<tablerow>2</tablerow>
<text></text>
<token>1</token>
<reverse-related attach="attach">Batterskull</reverse-related>
<reverse-related attach="attach">Bonehoard</reverse-related>
<reverse-related attach="attach">Flayer Husk</reverse-related>
<reverse-related>Grip of Phyresis</reverse-related>
<reverse-related attach="attach">Lashwrithe</reverse-related>
<reverse-related attach="attach">Mortarpod</reverse-related>
<reverse-related attach="attach">Necropouncer</reverse-related>
<reverse-related attach="attach">Scytheclaw</reverse-related>
<reverse-related attach="attach">Sickleslicer</reverse-related>
<reverse-related attach="attach">Skinwing</reverse-related>
<reverse-related attach="attach">Strandwalker</reverse-related>
</card>
<card>
<name>Manifest</name>
<set picURL="http://magiccards.info/extras/token/fate-reforged/manifest.jpg">FRF</set>
<manacost></manacost>
<type>Creature</type>
<pt>2/2</pt>
<tablerow>2</tablerow>
<text>(You can cover a face-down manifested creature with this reminder card.
A manifested creature card can be turned face up any time for its mana cost. A face-down card can also be turned face up for its morph cost.)</text>
<token>2</token>
<reverse-related>…</reverse-related><!-- Most of the manifest cards -->
<reverse-related attach="attach">Cloudform</reverse-related>
<reverse-related attach="attach">Lightform</reverse-related>
<reverse-related attach="attach">Rageform</reverse-related>
</card>
<card>
<name>Morph</name>
<set picURL="http://magiccards.info/extras/token/dragons-of-tarkir/morph.jpg">DTK</set>
<set picURL="http://magiccards.info/extras/token/khans-of-tarkir/morph.jpg">KTK</set>
<manacost></manacost>
<type>Creature</type>
<pt>2/2</pt>
<tablerow>2</tablerow>
<text>(You can cover a face-down creature with this reminder card.
A card with morph can be turned face up any time for its morph cost.)</text>
<token>2</token>
<reverse-related attach="attach">…</reverse-related><!-- Most of the morph cards -->
<reverse-related>Ixidron</reverse-related>
</card>
Can you explain a bit more the actual things that could change with this changes?
<token>2</token>
<reverse-related attach="attach">…</reverse-related><!-- Most of the morph cards -->
<reverse-related>Ixidron</reverse-related>
So we have other numbers than token=1 for "non-tokens"?
Better go with a more boolean and maybe easier and more self explaining approach here?
token yes: 1
token no: 0
I did a check and in current clients, any value for
is handled the same as "1". We can extend using that key.
So we could also change to use yes/no?
This is not a protocol, people still work with it from time to time. We don't want to need a documentation for all codes to use it. ;)
The reverse related extension with attach="attach" would trigger a behavior like for transform now?
Why not <reverse-related attach="yes"> or <reverse-related handling="attach">...? Do I miss something here?
So we could also change to use yes/no?
Setting <token>foo</token> actually does add tokens to maindeck in deck editor. <token>0</token> does the desired "add to Tokens section" functionality.
attach="attach"
I think this is the correct way. Making it yes/no prevents us from modifying it for future cards that, for example, create and 'attach' TWO tokens (attach="doubleattach") or our things like Meld. Using a more generic handling="attach" wouldn't make it any easier to add additional handling steps in the future.
Why not
<reverse-related attach="yes">or<reverse-related handling="attach">...? Do I miss something here?
Unlike HTML, XML does not allow attributes without values. When we write the attribute x="x" what it means is that x is just a boolean. It's present or it's not. The value is not meant to carry information, so it's the same as the attribute name.
So we have other numbers than token=1 for "non-tokens"?
Better go with a more boolean and maybe easier and more self explaining approach here?
token yes: 1
token no: 0
Actually, no. Let's back up. There's some unwanted behaviour with auto-attaching objects through <related>. We were working with the assumption that it was token related, but it's not. It also happens with any transform card, and those certainly don't point to cards with <token> elements.
Anything <related> is included in "All tokens", which is not always appropriate, token or not.

Any temporary object is considered the last token for Create another token, which is more unintended behaviour.

We currently can't get Morph or Manifest to have the attach behaviour if they are marked as <token>s, but the attach behaviour is still problematic.
The more general solution, then, is to enhance the <related> element meaning and have more functionality (whether it attaches) check that. We further imply that objects that attach can't be used to 'create another token', or 'create all tokens' (if the card has more than one token).
But if we're changing behaviour around "create all tokens" we would want to enhance that to include #2262 (create multiple tokens) as well. That interaction is difficult enough - avoiding creating emblems and tokens at the same time, for example.
So it's a bit complicated. It's why I'm trying to compile Cockatrice - to make a design that addresses these all of these additions.
Quite some variables involved here. If you have any news for us or we can help - let us know!
Most helpful comment
Unlike HTML, XML does not allow attributes without values. When we write the attribute
x="x"what it means is that x is just a boolean. It's present or it's not. The value is not meant to carry information, so it's the same as the attribute name.Actually, no. Let's back up. There's some unwanted behaviour with auto-attaching objects through
<related>. We were working with the assumption that it was token related, but it's not. It also happens with any transform card, and those certainly don't point to cards with<token>elements.Anything

<related>is included in "All tokens", which is not always appropriate, token or not.Any temporary object is considered the last token for

Create another token, which is more unintended behaviour.We currently can't get Morph or Manifest to have the attach behaviour if they are marked as
<token>s, but the attach behaviour is still problematic.The more general solution, then, is to enhance the
<related>element meaning and have more functionality (whether it attaches) check that. We further imply that objects that attach can't be used to 'create another token', or 'create all tokens' (if the card has more than one token).But if we're changing behaviour around "create all tokens" we would want to enhance that to include #2262 (create multiple tokens) as well. That interaction is difficult enough - avoiding creating emblems and tokens at the same time, for example.
So it's a bit complicated. It's why I'm trying to compile Cockatrice - to make a design that addresses these all of these additions.