pastly / cookerpoker Goto Github PK

There are a few different error types floating around. Should probably unify them as 'real' errors which would allow us to use various error management libraries in the future.

https://github.com/pastly/cookerpoker/blob/1eb32f79ec986eab88267505d8ffcca613f0c31e/poker-server/src/endpoints/logic/game.rs#L314-317

I believe the thing card rooms do is pay the odd amount to the person in the earliest position.

Use spaces in the table name to reproduce. See attached images.

Namely,

Turns out account IDs are i32. To avoid any possible confusion with other types that are just integers but aren't interchangeable, we should do type AccountID = i32 for these things and use AccountID in place of i32.

I thought of this when working on #12.

This one variant doesn't seem to fall in line with the rest of them.

1. The HashMap, in all practical uses, will only ever have one entry when it is sent to client
2. LogItem will probably be logged, leaking the pocket to the DB/log file unless it's filtered there as well
3. The place where PocketsDelt actually is useful is the showdown, at which point the data is no longer sensitive.

There a couple ways we could change this, in no particular order:

1. Getting pocket cards is a separate endpoint. This gives us easy fine-grain control, but breaks the flow of any future async client.
2. Separate log entries for each player, and the filter just completely drops those that aren't for the correct player.
3. Leave as is and just rename as 'ShowPocket(s)' or something along the lines of the more general usage.
4. ????. I feel like there is a better option, just not grasping it.

We don't really handle any situation right now as I write this, but as I work on the code, I'm realizing I'm not going to be handling situations such as the following, so this ticket is to record this fact.

See this random poker site I found with a DDG search for "allin raise less than minraise". See the Betting Rules for All-In Situations section:

What happens if a player goes all in with a bet or a raise but it's not enough for a full raise to be completed?

There are two common rules: the "full bet" rule or the half bet rule. If the "full bet" rule is in effect, as it usually is in No-Limit games, and the amount of an all-in is less than the minimum bet or the full amount of the previous raise, it's now a "real" raise and doesn't reopen the betting. If the "half bet" rule is in play if the amount is over half the minimum bet it is a raise and reopens the action.

Example: Player 1 bets $50 into the pot and the player that acts next goes all in for $65. As the extra $15 is not enough to constitute a "full raise" on Player 1's original bet, a third player can still raise instead of call as he has not yet had the option to raise. Player 1 would then be able to call or raise the amount of Player 3's raise.

If the third player just calls, however, Player 1 can't re-raise as it would essentially be re-raising his own original bet. Player 1 can only call the extra $15 from both players and would contest an extra side pot of $30 with Player 3. The main pot would have $50 from all three players in it for a total of $150.

So the table needs to:

• who raised last (because they can't raise again without someone else raising first)
• make sure an AllIn for less than the min-raise changes current_bet but not min_raise.

I've already changed production sections of the file for our deployment. Any changes to this file in git will cause git pull to not work.

I need to be able to specify to the poker-server binary my own untracked Rocket.toml.

Side pot logic requires I know not just the overall table winner, but the entire ranking of best hand to least best.

Desired api:

pub fn best_hands(hands: HashMap<i32, [cards; 7]>) -> Vec<Vec<(i32, [cards; 5]>

i32 is the account ID and tells me who the winner is, cards is obv the cards that won. Outer vec should be ordered be best ([0]) to worst([len-1]). Ties should be flattened to the inner vec, order doesn't matter.

There's probably some public domain slow cookers/grills/etc. clipart. Grab something and use it as a logo. I'm thinking

• Return to Index button in the top left of every page
• In the README.md

I've used the unicode characters for playing cards before, and that's what I was/am initially implementing.

I want to consider (as an option?) using SVG graphics of playing cards. Here is a set in the public domain (and some backs also in the PD).

https://openclipart.org/detail/315253/full-deck-of-ornate-playing-cards-english
https://openclipart.org/detail/315254/playing-cards-back

It looks like it would be easy, but tedious, to pull each individual card out of the source image. Not too bad really.

Pros for just characters:

• Simpler
• Already implemented / have experience

Pros for SVG images:

• Better looking
• Easier to partially overlap like this but squared (in fact, this may be basically impossible with just characters)

See https://github.com/pastly/cookerpoker/blob/master/docs/client-server-api.md#action-epoch. Probably abstract GameInProgress::game_log to a type that stores, let's say, 2 full hands in 'live', private dequeue, and an 'archive' field with functions for draining by the server. State in the archive field is not reliable and should only be used (or not) by the server.

New clients will be sent the entire 'live' log, and older logs can be requested against the web server.

• Rename pot log items to pot events.
• Rework pot log to return log items as they are created as opposed to accumulate them until the end.
• Create GameEvent enum or similar name. Include as variants BetEvent ... and anything else clients would need to see to keep track of game progress. Use the existing poker-messages as a hint for some.
• Fill in GameInProgress code with events.

The above will lead to an event log suitable for an admin / someone with permission to see everything (including everyone's pocket).

Next, event filters should be added. Variants:

• Filter nothing
• Filter for single player (can see own hand, and any later revealed), but verbose (include pot events, etc. Shouldn't be used day to day. If it is, there's something wrong.)
• Filter for single player (can see own hand, and any later revealed), but regular (only things a regular client needs to see.)
• Filter for spectator, but verbose (can only see hands that are eventually revealed)
• Filter for spectator, but regular (can only see hands that are eventually revealed)

I've used mvp.css twice now (pastebin and blackjack site). I think we should grab it, change a couple colors, and use it at this point. Just so it looks significantly better, even if basic and bland still.

It should be dark (obviously :p), but if I pick this up, I should resist just copy/pasting the pastebin/bj version, thus having a 3rd site with the same color scheme.

Don't think this should go in game log, as clients will NEVER need the deck seed. Only reason server needs it is to re-build the game table, and if we're rebuilding the table we didn't have the game log anyway.

• Disable Accounts
• Change API key
• Change name

Incoming branch that demonstrates the issues.

1. Off by 1 because of the - 1. If there's one player, they should get card at index 51 and 50, but instead the function tries to give them card 51 and 51. Not possible.
2. But the bigger problem is I think the algo is just wrong. Assume there's two players and we deal from the end of the deck (we do). The cards at the end are WXYZ. First call for the first player's cards gives him ZX (assuming fix from #1 is impl). The second call gives second player Y ... and not W. Whatever is before W. Because Y and W are now next to each other at it is wrong to skip.

I believe that we should .pop() .pop() to avoid this whole thing, even though it isn't how poker hands are dealt. It shouldn't matter mathematically.

Looks like there’s one that GitHub recommends and one that shows up when you google this issue. Pick something, test that it works, and merge to master.

Imagine the scenario:

1. Small blind forced to bet 5
2. Big blind forced to bet 10
3. Dealer bets 10
4. Small blind raises to 12.
5. pot.finalize_round() is called.

The pot is not correct, and the hand should not be finalized. However, the pot currently accepts the uneven bet and will end up paying it out as if nothing were wrong.

The parent table struct should be enforcing valid bets. This does mean that the pot itself is not 'safe' by itself. The main reason this was offloaded was that the pot cannot verify the pot is valid (all non-folded players in for the same amount) without knowing which players are folded. This requires knowledge of who is seated at the table, which the pot does not have and cannot currently access.

Couple options:

1. No change, pot is not 'safe' and behaves erratically when fed bad input. Table is responsible for validating the 'pot is right'.
2. Panic on payout when notice that the final pot is not correct. Likely need to account for the last 'out' player folding, as they may have less in the pot than the winner. Not recommended.
3. Force an overflow of the final pot to a max_in of the minimum value in the pot. In theory, any final pot with more than one person in it indicates one of three things:
   a. Two or more people in the final betting round came to the same bet. Overflow would have no effect.
   b. Someone won by being the last non-folded player, meaning they are the only one capable of winning the pot anyway. Overflow would have no effect.
   c. The player who overbet would have their overage moved to a side pot only they are in. This would still mean the pot was in a bad state, but the payout is settled to the lowest common denominator.
4. finalize_hand() takes a list of players still capable of betting (fold removed, but also all_in removed as they will not have the same amount in the pot). All players who are in normal bet mode should have the same amount in the pot.

There is currently two unit tests that test this behavior. multi_winners assumes that option 1 is taken, and the pot simply doesn't behave correctly. The pot currently awards the overbets to the winner of the hand, regardless of if the pot was not correct. over_bet the third option being implemented. These are mutually exclusive and no option should fix both tests.

I'm leaning towards option 4, while being the least concrete, should cover the majority of cases this could cause an issue in an actual game. Can likely implement both 3 and 4.

Diesel is 1.0 now and full featured, but "it's a lot sometimes." Rusqlite might be a better alternative.

Look at our options and pick something to start with.

https://rocket.rs/v0.5-rc/guide/state/#databases

IETF no longer recommends X- prefix on non-standard headers.

https://stackoverflow.com/a/3561399

Host the static website generated by cargo doc somewhere.

Also include the stdlib docs. The best solution I skimmed from here is to:

$ cp -a ~/.rustup/toolchains/stable-x86_64*/share/doc/rust/html/* target/doc/
$ cargo doc

Why is CurrentBetSet and MinRaiseSet different actions when they are very coupled ideas?

I don't think we have it. We need it.

Remove/make-private stuff that is unused and likely to continue to be unused. Anything that seems bj-specific should definitely go.

Do what https://github.com/pastly/cookerpoker/blob/master/docs/game-log-plans.md#way-forward says.

This issue more or less supersedes #41 and #42.

The list of things to do, taken from that document, is as follows:

• Change GameInProgress to record logs instead of returning them immediately.
• Store live/archive logs, which supports #42 but doesn't close it because we will not implement Epochs as part of this.
• Store logs with sequence numbers.
• Replace PocketsDealt with PocketDealt.
• Change GameInProgress to store the pocket map.
• Give GameInProgress a logs_since function.
• Maybe add a reveal function to GameInProgress and the necessary Reveal log item.

There's builtin testing support in rocket.

If we want/need to reach for something larger, I have experience with Robot Framework. But honestly, it might be too heavy weight and corporate-y.

I have some experience with docker now, which might come in handy somehow?

I'm leaning towards setting something up that's bigger than Rocket's builtin testing support because I think it would be good to verify with external tools that the whole system end-to-end functions: an HTTP client can make a call to some endpoint, it returns success, and then opening the sqlite database reveals that the intended change was indeed made.

It's easy to login. It should be easy to logout. Ya know, without deleting cookies or manually editing them :)

edit: Oh I can just return to index.html to change my account. But still.

I'm writing tests in branch table-tests, and as I go, I'm documenting things here that I believe should be changed. Lmk if you think the current state is better in any of these cases.

Quick links:

• Latest test results
• Branch

Todo list:

• view_tables_nonadmin isn't finished. Any logged in person should be able to see an Open table. Augment this test to create a table, make it open, and see if a non-admin non-owner can see it.
• view_tables_admin Admins should be able to see all tables, not just their own
• get_table_settings_nonadmin Regular logged-in users should not be able to see the details page for a table that is not owned by them.
• Someone who has permission to view/edit a specific table's settings should be able to submit the form without edits. They can't. HTTP code 422 returned. An issue, maybe not the issue: table_type is being sent as as string but an int is expected. >> Form < UpdateTableSettings > data guard failed: Errors([Error { name: Some("table_type"), value: Some("Tournament"), kind: Int(ParseIntError { kind: InvalidDigit }), entity: Value }]).
• Many instances of 404 because of permissions issues should be 403 or redirect to auth page