Open anoda9 opened 9 years ago
Users should know about tappedout.net and it has a legality checker built into it.
I don't know about tappedout. Is there maybe a way to interact with that site the same way cockatrice interacts with deckstats.net to perform a legality check for yourself?
But anyway, anoda9 is talking about some kind of check that tells your opponent that you're not cheating. Or to keep it general, which formats your deck is legal in. Since that is a specific game related check I like the idea of the server offering this opportunity. Still cockatrice needs to support this kind of deck checks with the server. Not sure about traffic, but if the server does the shuffling already, he knows about all the cards?
The problem with the sideboard is a point! What if players (in network games, not local) are just allowed to load decks if the game is filled with all players? (combine with locked functionality later on? so you can start the game/start loading decks in a 4/6 player edh game as soon as the creator locks the room - if he unlocks the room, all loaded decks needs to get reloaded to avoid cheating. that should be an issue for itself if others see the need for it, too)
@ZeldaZach Yeah, I was more thinking of it as a way to make sure your opponent's deck is legal, rather than for checking your own deck.
What if players (in network games, not local) are just allowed to load decks if the game is filled with all players?
I'm not a fan of that because it would make things more tedious for whoever joined the game first. It's quite a bit easier/more convenient to be able to create a room, load your deck and then just wait for an opponent to show up, rather than having to wait for someone first and then load a deck. Also, it would mean you'd have to re-load your deck every time a new opponent joined the game, which would be kinda annoying.
An alternative temporary solution for the "unknown sideboard cards" problem might be to just display the number of sideboard cards next to the deck hash. i.e. something like (hash-15) - the "-15" on the end representing the number of sideboard cards. Players are allowed to count their opponent's sideboards in real-life tournaments (MTR 3.15), so it wouldn't be leaking information.
I don't know how much server stress an automatic deck-check function would cause (it seems like a fairly simple function, but if it has to be done thousands of times every hour it might add up?), but one option for implementation could be: only the (4-of) and (15-card sideboard) criteria are checked automatically, and the (format specific banlist) check would be available through a menu option.
I like the idea of adding the sideboard count to the hash or a special collumn.
Another possibility might be that every time a player joins a room he gets informed about already loaded decks from the server. The missed notification "xxx loads a deck with x sideboard cards" get passed to him like "xxx had loaded a deck with x sideboard cards". The problem here is that every other player gets the same message again and again as long as players keep joining and the message is written to the game chat. Not sure if it is possible to display these messages just for one player. (like the chat displays different information about morphs in the chat of your opponent and your chat, like a filter)
But yours seems the most simple since the information is already there, just displayed differently and only once (as a chat message).
Sideboard issue: #552
As I just found out, the mtgjson file provides card legality information. (#539) But as Cerxi mentioned there they don't make it to the cards.xml. So Cockatrice can't work with them to help with this issue/feature.
As an early 90's player, I didn't really keep up with all of the sets that came out over the decades. So i'm not completely up to date with the deck legalities, as far as what sets are allowed and what cards are banned.
My 2c would be to have a legality checker in game. A go/no go kind of indicator that it matches the type of game selected.
Then have a filter on the deck builder for the type of deck you want to build. I prefer to get all of the cards from oracle, so that I have everything, but if I want to build a standard deck, then i should only see the legal cards within the deck builder.
Maybe something like New Deck...then a dialog box that restricts the card list to the legal cards.
I think there should be an option when creating a room for "Standard" or "Modern" to have an "enforce" checkbox which prevents users from loading illegal decks.
That's far away. If we add it at all it'll be after a local one inside deck editor. Servatrice has no card database to do these checks with
@Daenyth ok, so Servatrice can't check for banned cards or too old editions you might use. That can be done within the deck editor to help with building and will be realized by your opponent anyway... because they should know if you play a banned card or a card from a 5 year old set in standard...
But they don't know and can't find out if you play more than 4 instances of one single card, e.g. Maybe Servatrice can check for that? It doesn't need to know the cards - just count them. That might work?
You can have more than 4 basic lands, relentless rats, limited has different legality rules, there's the vintage restricted list...
@Daenyth I see, this is more complex then expected.
Well I don't know that much about constructed. Forgot about restricted anyway. So the deck editor within cockatrice and the legality information from mtgjson (also has banned/restriced!) are the only way to make something work for the deckbuilding. I see no way to check before playing on the server.
(just to make sure: limited has no legality rules besides a minimum of 40 cards in your main deck - you can use as much copies of every spell if you are able to grab them)
You are correct on limited.
I agree about using mtgjson's values for the deck editor.
Just a note: card legality is included only in mtjson's AllSets-x.json (the version with extra data), that weights around 40MB. I suppose adding support to grab the zipped version could help people limited on bandwidth.
Card Data Only AllSets.json (11.9MB) AllSets.json.zip (2.5MB)
Card Data with Extras AllSets-x.json (40.0MB) AllSets-x.json.zip (7.3MB)
Support for the zip-Download seems reasonable anyway. But you are correct about the legality information. It's just in the version with extras.
@Sembiance what do you think of offering a sets+legality only download in addition to sets/sets-x? This would save both our users and yourself lots of bandwidth.
Added #624 for zip support
@Daenyth I have no bandwidth concerns on my side, but I can understand the bandwidth concern for cockatrice users.
If the HTTP downloading code you are using in Cockatrice supports gzip "Content-Encoding" then that alone reduces the 40MB AllSets-x.json down to just 9.8MB
You can save even more bandwidth by implementing support for the ZIP file, reducing it to just 7.3MB
You can get it even smaller by checking the 'changelog.json' file and only downloading the individual set zip files that have changed since the last change.
Those are the three ways I provide smaller file sizes for programs that use the data. Right now mtgjson has a simple and clear "regular" and "extras" format for files. I'd rather not complicate matters by adding an additional format, especially since I already provide methods to have a smaller downloads. I hope this makes sense :)
related: #215
This could be built off the data used for #1771
It feels like #528 and #215 are really the same and discussion there are going back and forth, but always coming down to:
using mtgjson's
legalities
values for filtering in the deck editor
&
the zipped extended
-x
file isn't that much bigger to be concerned of
Especially since there has been requests for foreign language support (+pictures) as well, and all the foreign card names and id's are also only part of the bigger allsets-x.json.zip
file.
Considering that, at one point there is no way around the bigger file anyway I guess? Unless we want to miss out on very helpful and demanded features...
Example data from allsets-x.json
for Abrade
:
"legalities": [
{
"format": "Amonkhet Block",
"legality": "Legal"
},
"foreignNames": [
{
"language": "German",
"name": "Aufscheuern",
"multiverseid": 430971
},
Let's just go ahead and use the -x file.
Update: with MTGJSONv4 all information is available in the default json file as there is no differentiation anymore!
(Linking https://github.com/Cockatrice/Cockatrice/issues/3406)
Having this feature within the Deck Editor only (i.e. client side) would be fine for me. We already have a list of formats defined in the schemas of Oracle, so understanding what "formats" we have access to are a simple parse job. Then we can run the cards in the deck against the formats list and pop ones that are no longer valid.
Does mtgjson also know about bans?
Yes... it knows about everything
A deck legality checker would be a good feature to have. The main criteria to check is the 4-of rule, since that is unverifiable by the opponent. Checking format specific banlists would be nice also, but that should be a lower priority, since it's easily verifiable by the opponent. (if you try and drop a mox in a legacy match, it's pretty obvious your deck is illegal). The 15 card sideboard limit is also sometimes unverifiable (if a person starts their own game and loads a deck before their opponent gets there, their opponent can't see the "player_x loaded a deck with 15 sideboard cards." message), so that would be good to check also.
I think it'd be best if the legality checker ran in parallel with starting a game, rather than being a requirement for the game to start. (i.e. you would start a game, then the server would check your decks as you played out the first few turns, rather than forcing the deck check step to be completed before the game could begin.) This would reduce lag/still let people play if the deck check function was unavailable.
Once completed, the server could mark your deck with a green checkmark, or put the hash in green text for being legal, red text for illegal.
The 4-of criteria would be disabled if the game type was "Draft/Sealed".