rbtying
requirement-decomposition is insufficiently strict when longer-tuples are protected
This issue is when 7 people playing with 4 decks of cards. "Longer tuple (triple) is protected from shorter (pair)" setting is on.
When a tractor is getting played ([7, 7, 8, 8]), if the next person to go has a [4, 4, 4] and a [10, 10], he should be forced to play the [10, 10] pair, but the game allows him to just play the [4, 4, 4].
Interesting. I don't think I would normally consider this is a bug? If the player chooses to break their three-of-a-kind, that's up to them. After all, they're allowed to play the [4, 4] to lead a trick, even if it's probably bad strategy to do so.
Ah okay - I think I should clarify the problem, I didn't explain it fully. Say person A and B are currently playing in the same trick: Person A plays a [7, 7, 8, 8]. Person B has a [4, 4, 4, 10, 10] in their hand.
The game is currently letting person B play [4, 4, 4, {random}], when in reality person B must play the pair of 10s (to match person A's pairs). Person B technically can play the 4s if they want, but they must play the 10s because they have that pair. (Maybe the game is interpreting the hand [4, 4, 4, X]) as 2 pairs already? [(4, 4), 4, X], and [4, (4, 4), X]?)
Ah, I see. What's happening here is this:
1/ from the perspective of the game, B doesn't hold two pairs. They hold a pair and a triple. 2/ the "play legality" is defined by the current requirements (which decompose to less-strict requirements) and by whether an alternate selection of cards can be played by the player to also meet the requirements.
So, a play is illegal if the player's hand can meet requirements that the player's play cannot.
However, [4,4,4,10,10] can't meet either the [7,7,8,8] or the [7,7],[8,8] requirements, since [4,4,4] can't be forced to break. So, the requirements that the player is actually being validated against for play-legality is [7,7],[8],[8], which doesn't require a pair for the second half.
Fixing this will require some thinking about how whether there should be backtracking in the requirement-decomposition logic -- I haven't put in the time for that, because I don't personally play with the protect-triples setting(s). Reproducing this in a test should be easy though!