Legacy-effect card development

[Aswan jaguar]

Korath said:
(Actually combining effect cards from separate activations is a little harder; keep those separate, please.)

An example of what you mean please.

[Korath]

Would you like the current manalink.xls file to do the entries yourself, so you can bug check the coding at the same time?
Or would you like me to do the data entry?

Best to do the changes to both the code and the data in the same commit.

Which is the canonical source - the xls or csv? That is, do you generate the xls from the csv, the csv from the xls, or go back and forth between them interchangeably?

Korath said:
(Actually combining effect cards from separate activations is a little harder; keep those separate, please.)

An example of what you mean please.

On the easy list: Make the effect card from Kessig Wolf Run, when activated with , say "Target creature gets +4/+0 and gains trample until end of turn."

On the harder list: If you pump Steel Hellkite a second time, replace the (already-existing!) "Steel Hellkite gets +1/+0 until end of turn" effect with a "Steel Hellkite gets +2/+0 until end of turn" effect.

The first is just text replacement and telling the effect card where to find the right number. (Which is already there, but probably not in the right place for it to be seen.) The second needs to search for an effect card already attached to this card, verify that it's the same sort of effect card, either destroy it or make it invisible, and make a new effect card storing the right number. (Which isn't necessarily already there in any form.)

...this is getting a bit far afield from typos.

[Aswan jaguar]

Stassy can you make a topic "Legacy-effect card development" in development forum and transfer these there?

[stassy]

split move done

[Sonic]

Best to do the changes to both the code and the data in the same commit.

Which is the canonical source - the xls or csv? That is, do you generate the xls from the csv, the csv from the xls, or go back and forth between them interchangeably?

We tend to work exclusively on the xls files. Because, as you have previously noted in another thread, converting the csv files back to xls from the semicolon delimited csv format can lead to problems. Although, there is a way to do it successfully in Libre Office Calc – but manually restoring the xls formatting is something of a pain.

Gargaroz and I exchange the main Manalink/Ct_all.xls files between us when updating the files for a patch, and I also pass on the Manalink.xls file to stassy so he can work on the AI Base Values column.

Problem being, as we're part way through working on the next update with the addition of a new set, our current working files will be significantly different to the csv files in the magic_updater folder. All the token/special card entries will have been shifted for example. (Note: I gave Face-down Creature a fixed ID entry as requested. )

So I’m still not really sure how you want to work this? Wouldn't it be better for you to update your install to have parity with Gargaroz’s current working files and the next update? In which case you would probably be better off getting all the files from him.
I can add any corrections I've made to my manalink.xls file at a later date.

Alternatively, if you want to work on the current csv file you’re quite welcome to. If needs be, I can track the changes in the effect/legacy title and text columns and update our working xls files for the next release at a later date.
Or I could send you the xls file for the current release and the third party program and batch file I use to convert the xls files to csv to produce the dat files. I’m not sure how Gargaroz does it.

[Korath]

What we'll do is put the .xls into git and then treat it like any other source file.

(We'll probably also want to put the .csv files in, too. Usually, you don't want to have anything in version control that can be generated from other files there, but A) we'll want to have something that results in human-readable diffs, and B) only the csvs have been distributed with previous patches, so if we don't, we'll lose the history. I can add a pre-commit script that rejects changes to the .xls file unless the corresponding .csv has been updated too, so they don't get out of sync.)

[Sonic]

What we'll do is put the .xls into git and then treat it like any other source file.

(We'll probably also want to put the .csv files in, too. Usually, you don't want to have anything in version control that can be generated from other files there, but A) we'll want to have something that results in human-readable diffs, and B) only the csvs have been distributed with previous patches, so if we don't, we'll lose the history. I can add a pre-commit script that rejects changes to the .xls file unless the corresponding .csv has been updated too, so they don't get out of sync.)

Sorry Korath. I'm really not versed in the world of collaborative software development. I'll have to wait until you've got this git, or whatever, up and running and then see if I can get my head round how it works.

Which manalink.xls file do you need to make a start on the legacy cards?

[Korath]

Just the final one for the upcoming patch. (When it's final, of course.)

[Sonic]

Just the final one for the upcoming patch. (When it's final, of course.)

Only be when the next patch is released.

[Sonic]

OK, as nobody else seems to be rushing to start a list I suppose it will have to be me.

@Korath, questions:

Is it possible to address cards which would benefit from having access to the |#1, etc, codes, but wouldn't be a candidate for having eot_toughness set or |n in their legacy text?

For example: Death-Hood Cobra
: Death-Hood Cobra gains reach until end of turn. (It can block creatures with flying.)
: Death-Hood Cobra gains deathtouch until end of turn. (Any amount of damage it deals to a creature is enough to destroy it.)

Also, from your above examples (Kessig Wolf Run and Steel Hellkite), are you essentially saying that cards with in their activation cost are the simpler of the two examples to resolve?

[Korath]

Yes, splitting up Death-Hood Cobra would go on the easy list.

The choice of which |#1 |#2 etc. alternative to use happens to use the same piece of data that the number for |n does, so you can't use |# and |n on the same card. Someone labelled this piece of data "eot_toughness" long ago, but that doesn't necessarily mean it always has something to do with toughness or end of turn. I misremembered, sorry - |n is counter_toughness, not eot_toughness, so |# and |n combine fine.

Kessig Wolf Run isn't easier than Steel Hellkite because it needs to tap; it's easier because the entire effect is added in a single activation. What Aswan jaguar asked for earlier was to combine the effect cards from multiple activations into just one orange card instead of a whole column of them, like how Shivan Dragon and Frozen Shade worked under fourth edition rules. " : ThisCreature gets +1/+1 until end of turn" meant you could pay to give it +3/+3 in the same activation; a handful of exe-coded cards still work like that. Under modern rules, it's always three separate activations, and that's how most C-coded cards work.

[Aswan jaguar]

Korath wrote:
What Aswan jaguar asked for earlier was to combine the effect cards from multiple activations into just one orange card instead of a whole column of them, like how Shivan Dragon and Frozen Shade worked under fourth edition rules. " : ThisCreature gets +1/+1 until end of turn" meant you could pay to give it +3/+3 in the same activation; a handful of exe-coded cards still work like that. Under modern rules, it's always three separate activations, and that's how most C-coded cards work.

What I really meant is that there are original cards that can use one Legacy Card and pump each time compliant with modern rules,using each time a separate activation but ONLY one Legacy card in which the power/toughness gets adjusted accordingly.Look Dragon Engine,Rainbow Knights,...

[Korath]

..that's what I thought I said. Activate multiple times, end up with one orange card.

[Sonic]

@Korath - Can we do anything with the |C (color change) and |a (ability change) codes?

Should I include candidates for these?

[Korath]

No to both.

|a is hardcoded to only get replaced for Urza's Avenger, and only to the four abilities it can give itself. It wouldn't be any easier to fix it and expand it to the rest of the abilities (even just the original ones Microprose programmed) than to make the text arbitrarily replaceable in C.

If |c was ever properly replaced, it no longer is, and always falls through into drawcardlib (where it gets displayed as the Planechase chaos symbol).