It has been mentioned before that it can be tricky to find new cards to add to Magarena, taking into account AI and other restrictions.

I usually have an ongoing list of cards to consider (which I normally then misplace) while looking through Card Explorer. I thought it would be handy for everyone (and a safe place to put my list) if I posted it here for others to have a look over.

I'll try and keep this up to date with submissions through Firemind and on the main repo, to try not to have multiple people doing the same cards (although this can be helpful for tricky ones.)

As Mirrodin Besieged and Nemesis have now joined the 80% complete club, these are what I've looked at so far - some more tricky than others, but should be worth looking at:

This reminds me that I've been meaning to implement something like this as part of firemind for ages.

Some way to track what cards are implemented in HEAD that are not part of the last release, see what cards could be added and which ones are currently impossible (by flagging them with the reason they are not doable). Maybe even allow users to say what cards they are currently working on. Basically anything to make the scripters life easier and make the request cards feature actually useful.

I guess my question is: Would anyone even use it? And if so what features would you like to have?

Wow, I just thinking about similar things as well. How to make it easier to find scriptable cards by separating the unsupported cards from the scriptable ones.

My idea is to use the cards already in the release folder, now all under scripts_missing. I'm thinking to create two sub directories, perhaps a "scriptable" and "unsupported". The generic scripts_missing contains uncategorized cards, then over time as we analyze each one, we move them to the appropriate subdirectories.

My idea is to use the cards already in the release folder, now all under scripts_missing. I'm thinking to create two sub directories, perhaps a "scriptable" and "unsupported".

Some of the cards that are currently unsupported could become supported in the future as the game engine improves right? Having all of them in one folder might become cumbersome to keep up to date especially if not everyone maintaining it is sure about why a card was marked as unsupported originally. Which is why I thought about a tagging system where you could have an unsupported tag name like "Suspend" with a description of why suspend is not currently supported. If it later becomes supported it would be easy to find the cards that are now scriptable. Admittedly this isn't as much of a problem if the reason is an unsupported keyword for which people can search but if the reason is something like the "multiple mana problem" it might be useful to have the cards tagged.

It lets you find cards to script, create card script submissions directly and see the status of your submissions. Users who have been given access may also create "Not Implementable Reasons" and tag cards with them. I did that for Banding, Suspend, Phasing and the" multiple choices on modal spells"-problem.

What's missing is the integration with the magarena git repository. Here's my proposal for doing that:

* I create a new branch on https://github.com/firemind/magarena-csm-auto which I regularly update from magarena/magarena master* Cards that are present in that branches release/Magarena/scripts directory but not in the last magarena release will be flagged as "upcoming" and excluded from the "Find card to work on search" by default* If a card gets tagged with a reason for not being implementable it gets moved to scripts/missing/unsupported on my branch if it's not already there* The reason(s) get added as the last line of the script file. Something like

* The changes in my branch are commited as the user who performed them and pushed. Just like the card script submissions work currently* If the unsupported tagging happens manually on the master branch my sync will update the firemind database accordingly* If tags are removed on either side I'll update the other side

Thanks, mike, I just gave it a spin. Looks pretty handy, though I'll probably will operate on the repository directly rather than through a web interface as it is faster for me.

The idea of using a property in the card script is a good one. It is more flexible than using directories and keeps track of the reason as well. Though one issue may be problems with card-builder, as we sometimes will regenerate the missing scripts when card-builder is updated. @ShawnieBoy what do you think?

Assuming a property in the card script is the way to go, we also want to track groovy scriptable cards vs cards that have not been analyzed. I'd like to propose the following format

With regards to the scriptsbuilder, there needs to be a manual oversee of the card values and images, so wouldn't have that much extra impact. It could even be possible to take the results of the ParsedCards output and assign the "uknown abilty" errors etc to the statuses.

I'll probably will operate on the repository directly rather than through a web interface as it is faster for me.

That's cool. I wasn't expecting core devs to switch to this.

I see the main audience in people who occasionally want to work on a card or are just starting to get into card scripting. This is supposed to lower the barrier of entry by communicating clearly to people what cards can and cannot be worked on which should help prevent frustration. In addition I'd like to implement some advanced search to help find similar cards that already have a card script to serve as a base for new scripts.

mike wrote:In addition I'd like to implement some advanced search to help find similar cards that already have a card script to serve as a base for new scripts.

Finding a similar groovy script to based a new script on would be an extremely helpful feature. I'm currently using grep for this. A more sophisticated groovy search feature would come in handy.

mike wrote:Alright, is that the syntax that works best for everyone? If so I'll add a check box for the "needs groovy"-status and get to work on the sync.

Perhaps we can trial it in the repo for the next release to get a better feel of how it works in practice. Note that the directory structure remains unchanged, there will be no new subdirectories.

One short coming I realized is that "needs groovy" doesn't give enough details as to which ability needs to be written in groovy. There are some cards where two out of the three abilities works as it in card script and one of them needs to be implemented in groovy. Perhaps we can create a stub groovy file that has the oracle text in comments.