search

ctm / mb2-doc

Mb2, poker software
https://devctm.com
7 stars 2 forks source link

Make high/low games set options.high_low appropriately (i.e., no longer have high/low be implied merely by the subtype) #1413

Closed ctm closed 1 month ago

ctm commented 1 month ago

Make all the GameInfoBuilder<_> statics set options.high_low if the game is high/low, rather than relying on implicit behavior (both in the game's textual description as well as how winning hands are determined).

Currently, at least two games (BIG_O and TWO_OR_FIVE_O8) have options.high_low set—by default—to HighOnly, with both their names and the pot-awarding behavior being high/low8 due to recognition of their subtypes (BigO and TwoOrFive). That worked fine, until it didn't (#1412). It's an obviously error-prone way of doing things and should be fixed.

FWIW, I didn't fix this aspect of the problem when I fixed #1412, because I didn't want to take the time to poke around in the hand_winning definitions for each of the games, since, IMO, that's problem (encompassed by this GitHub issue) is separate, albeit highly related (IOW, I'm lazy).

This issue is only for implicit high/low, not implicit high-only, or on Binglaha, or split-pot games where the pot splitting is implicit but not simply "high/low (with or without a qualifier)" (e.g., Dramaha 49). Most likely, as I work on this issue, I'll create one or more other issues for those. My reasoning being that implicit high/low happened by accident and has a trivial fix, whereas those other implicits are slightly more nuanced.

ctm commented 1 month ago

I largely changed my thinking on this. Eventually it will be a non-issue, because sub-types will not have a HighLow or other enum that is irrelevant / misldeading (#944). I did, however make a tiny change and I'm deploying now.