by ShawnieBoy » 15 Jun 2016, 15:40
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:
Eye of Yawgmoth
Rupture (The sacrifice here isn't a cost, it's an effect of the spell resolving)
Tezzeret, Agent of Bolas
Wild Mammoth (Essentially doesn't trigger if there is a draw)
by mike » 15 Jun 2016, 16:19
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?
by ShawnieBoy » 15 Jun 2016, 18:21
The upcoming cards list in my sig is updated by Melvin for cards that have been done but not released (and so submissions would be duplicates).
Being able to flag impossible cards would be useful too. I've not kept an eye on submissions via Firemind, but wouldn't be a bad thing to have.
by melvin » 16 Jun 2016, 09:26
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.
by mike » 16 Jun 2016, 09:40
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.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".
by mike » 17 Jun 2016, 06:51
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
- Code: Select all
* 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
What do you think about having this feature and doing it this way?
As a side note: Would it be useful if instead of commiting all the card submissions to magarena-csm-auto:master I created a new branch and a pull request automatically for each of them? https://developer.github.com/v3/pulls/# ... ll-request
by melvin » 18 Jun 2016, 12:37
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.mike wrote:So I've been playing around a little with the idea and came up with a prototype: https://www.firemind.ch/workspace
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
- Code: Select all
status=not supported: banding, phasing
by melvin » 18 Jun 2016, 12:38
For card submissions, committing to the repo is easier to work with than pull requests. I'd prefer to stick to the current method.mike wrote:As a side note: Would it be useful if instead of commiting all the card submissions to magarena-csm-auto:master I created a new branch and a pull request automatically for each of them?
by ShawnieBoy » 18 Jun 2016, 12:51
by mike » 20 Jun 2016, 06:16
That's cool. I wasn't expecting core devs to switch to this.I'll probably will operate on the repository directly rather than through a web interface as it is faster for me.
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.
- Code: Select all
status=not supported: banding, phasing
by melvin » 20 Jun 2016, 09:46
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: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.
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.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.
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.
by mike » 25 Jun 2016, 22:40
Ok, so I set up a new branch at https://github.com/firemind/magarena-cs ... lementablePerhaps we can trial it in the repo for the next release to get a better feel of how it works in practice.
The system will commit added or removed labels to this branch with the user that makes the changes. I tested that with the banding, phasing and suspend labels I created.
I'm updating my clone from magarena/magarena hourly and update the firemind database with all labels that are added directly via the repository.
Let me know if this works for you.
by melvin » 02 Jul 2016, 14:06
by mike » 02 Jul 2016, 14:23
Improving the search is still on my radar. It's just a bit trickier than I thought.
by ShawnieBoy » 18 Jul 2016, 16:53
Is there a list of not-supported tags available?
Who is online
Users browsing this forum: No registered users and 4 guests