Add Card Type Weighting as option to the Random Deck Generator.
Closed this issue · 6 comments
Unsure if I can post this here, but I will anyways because I do feel it's a good suggestion.
Make some options in the Random Deck Tool.
- Follow Banlist / Don't Follow Banlist.
- Modify Weight of Cards Pulled.
Thanks for the suggestion! This is the right place :)
I think currently the banlist selected in the drop-down is also used for the generation of random decks, but I need to double check this.
Which weight of cards do you mean exactly? Currently there is an hard-coded weighting for monster/spell/trap, which could be made configurable.
Yeah, you are right about the ban list for Drop Down, it does use that. Does it by default ignore banned cards when making a random deck or should that not matter?
For weight of cards, it always does 38/16/6 mostly for highlander. If anything, I want there to be an option to make it so there's a possibility to get 40 trap cards and 0 spell cards for chance, like pure randomness with nothing weighing in on factors.
Also, an option where generating a random deck, you can choose the amount of cards that get generated from 0 - 60 for the main deck and 0-15 for the extra deck.
Yeah, you are right about the ban list for Drop Down, it does use that. Does it by default ignore banned cards when making a random deck or should that not matter?
It should apply the limits/banned status of a card, so banned cards for the current format should not show up
For weight of cards, it always does 38/16/6 mostly for highlander. If anything, I want there to be an option to make it so there's a possibility to get 40 trap cards and 0 spell cards for chance, like pure randomness with nothing weighing in on factors.
Ok, thanks for clarifying! That should be doable, I'll see when I get around to implementing it
Also, an option where generating a random deck, you can choose the amount of cards that get generated from 0 - 60 for the main deck and 0-15 for the extra deck.
Good point, that would make sense. The programming logic for this also exists already, but it needs to be configurable in the UI
Split to #112.
Internal implementation done, postponing UI for it until updating/migrating UI library.