Poker Hand XML

[wallenborn]

Reads are associated with players, so you don't have a referencing issue.

<metadata>
<read>Table is loose and passive</read>
<read player="bigFish">Thinks straight beats flush</read>
</metadata>

On the other hand, the <context> element has a few children like game/tournament, game/currency and such, for which you could make the same argument: that they are properties of not just the hand in question. In my daytime job (i work for a software company) we had a similar problem once, and we decided to write something like a context element that could hold all this, and make its location optional. So a container format for a whole session could hold a top level <context> element and each hand could have one, too. That way, the decision where to put the information becomes a run-time issue. It makes the code a little more complicated, though, and does create consistency/duplication issues.

[Shoe Lace]

[ QUOTE ]
By not providing the winning hand and net amount

[/ QUOTE ]

The winning hand(s) must be in. Like we said earlier, it's crazy not to include this. The problem I have is with the net and pot sizes (either total or for each street).

[ QUOTE ]
Let's take a quite rare situation, the pokersite named the wrong hand the winner. Wouldn't you want that to be preserved in the hand history? Same thing goes for pot sizes / awards.

[/ QUOTE ]

The winner(s) of the hand won't be excluded from the XML file.

As for the pot sizes I cannot see how this could be a problem.

If Jim (CO) raises to 35 preflop, and Jane calls, then the pot cannot be anything other than 85 (assume this is a 5/10 game and everyone else folded).

If for some wacky reason the actual HH shows the pot as 95 on the flop then this reason alone is enough to calculate pot sizes on the fly instead of depending on the hand history of the poker site.

[Shoe Lace]

[ QUOTE ]
I think in-hand comments are important and should be part of the hand. End users are going to want the chat recorded, and it allows us to throw away the original hand history without losing information. It makes no sense to me to put in extra data such as the won/lost of every player (which can easily be calculated or queried)

[/ QUOTE ]

100% agreed.

[OrcaDK]

[ QUOTE ]
[ QUOTE ]
By not providing the winning hand and net amount

[/ QUOTE ]

The winning hand(s) must be in. Like we said earlier, it's crazy not to include this. The problem I have is with the net and pot sizes (either total or for each street).


[/ QUOTE ]
It's primarily the total pot I'm in favor of. I would like the street pots as well, but those I'm not as stubborn with.


[ QUOTE ]
Let's take a quite rare situation, the pokersite named the wrong hand the winner. Wouldn't you want that to be preserved in the hand history? Same thing goes for pot sizes / awards.

[/ QUOTE ]

The winner(s) of the hand won't be excluded from the XML file.

As for the pot sizes I cannot see how this could be a problem.

If Jim (CO) raises to 35 preflop, and Jane calls, then the pot cannot be anything other than 85 (assume this is a 5/10 game and everyone else folded).

If for some wacky reason the actual HH shows the pot as 95 on the flop then this reason alone is enough to calculate pot sizes on the fly instead of depending on the hand history of the poker site.

[/ QUOTE ]
But this would actually be correcting the hand history, even though the site either wrote a wrong hand history - or the actual game was flawed. If we autocorrect the hand histories we're correcting symptoms and we'll never discover any real problems. Still, the only argument I see as to why we should not include the pot total and net win/loss is XML size, but my opinion is the same on that account.

/ Off to bed [img]/images/graemlins/wink.gif[/img]

[Shoe Lace]

[ QUOTE ]
But this would actually be correcting the hand history, even though the site either wrote a wrong hand history - or the actual game was flawed. If we autocorrect the hand histories we're correcting symptoms and we'll never discover any real problems.

[/ QUOTE ]

The parent app that's creating the XML file (and is reading the poker site HH) can fix the issue and know the issue without needing a potsize field. Also, since this app is the one concerned with outputting valid data it's the app's job to do this.

If the pot size ends up being $453.21 (by adding each street) but the actual pot size in the poker HH shows $449.73 then it wouldn't be difficult to see there's a problem (from the eyes of the parent app). At this point they can do whatever they need to do to fix it and notify the user in their app.

If the poker site fudged the hand up the output of the fudged hand should be identical. Btw can you paste a legit hand where this actually happened? I'm curious what it looks like.

[Tickner]

Guys,

The pot sizes are an important part of the hand (not by street though). We need to know a) how much rake is taken and b) who won what pots and how much were in those pots c) total pot size.

Excluding this information makes the XML hand much less useful.

However, I agree that the net amount of each player should not be included. Some apps will need this and they have all the info to produce it if they do.

I dont know where we would include chats, and while they are an important part of the hand that takes place and I'd like to include them I can't think of any logical way of storing them. (Should we also start including a <physical_tell> and <distraction> element for offline games?)

This kind of stuff, while important, just isn't a part of what took place. A good example of data that would be good to include is timing tells. How long did it take for playerA to call?

This is all meta information and Orca's idea of a <metadata> tag isn't a bad solution to this, since all applicatios are going to require a place to store optional extra data for aplication-to-aplication interaction that PokerHandXML won't support.

With reference to the raising situation...

I've dealt with a lot of hand history's and pretty much all of them record bets and calls as additives and raises as total. LegoPoker's parser computes this stuff every day pretty easily and its actually easier to program because there are 2 ways to looking at it.

A bets $50, B calls $50, C raises to $150, A calls $100, B raises to $450, C calls $300, A calls $300.

to find out how much A has, we cycle through every action A has made and if it is a bet or a call, add it to his total, and if it is a raise do not add it to the total, bet set it to the amount he raised to. Do this for each player.

Now if we dont do this we have

A bets $50, B calls $50, C raises $100, A calls $100, B raises $350, C calls $250, A calls $250.

I got the math wrong in that because its so confusing as to whats going on and what the current bet is. "Raise to" is definitely the standard and "raise $x" just makes everything confusing.

Also, call needs to be how much the player is CALLING not the total amount he has in the pot. Again, its hard to read and figure out what going and on theres no need to make this confusing.

[Phil153]

[ QUOTE ]
The pot sizes are an important part of the hand (not by street though). We need to know a) how much rake is taken and b) who won what pots and how much were in those pots c) total pot size.

[/ QUOTE ]
The trouble is that some sites don't include them, and there is no way to calculate them without knowing the rate of rake. Having a standard that can't be fulfilled on all items is a bad idea.

[ QUOTE ]
I dont know where we would include chats, and while they are an important part of the hand that takes place and I'd like to include them I can't think of any logical way of storing them.

[/ QUOTE ]
That's a negative for this XML format then. Chats are often an important part of hand to the end user and need to be inserted at the correct spot, for example in replayers.

[ QUOTE ]
(Should we also start including a <physical_tell> and <distraction> element for offline games?)

[/ QUOTE ]
These are completely different things. Chat is a part of hand histories, users want it, the sites include it, and leaving it out is destroying information. That doesn't matter if your goal isn't to be a storage standard, but if it is, destruction of information seems bad.

[ QUOTE ]
I've dealt with a lot of hand history's and pretty much all of them record bets and calls as additives and raises as total. LegoPoker's parser computes this stuff every day pretty easily and its actually easier to program because there are 2 ways to looking at it.

[/ QUOTE ]
I guess that's a just a preference then. I know Party does it the [amount put in] way. Most of my parsing has been related to replaying a hand, and the amount put in is more valuable than having to reconstruct the player amounts. You simply step through the amounts to get the pot size for the street, or the total wagered of a player for that hand, or the pot size for that street. Very easy. I guess most of you work has been related to displaying a hand in a forum, where you need the "to" amount, so it appears easier from your perspective.

[ QUOTE ]
"Raise to" is definitely the standard and "raise $x" just makes everything confusing.

[/ QUOTE ]
Party uses the amount put in, as do old Tribecca hands I have, as does iPoker. I think the Everest xml uses that as well. "Pretty much the all sites" is wrong. I guess Stars is the standard these days though since most Americans play there. What I like most about the [amount put in] is that it's agnostic to the description of the action, whereas your way requires reading the action description and interpreting it.

[ QUOTE ]
Also, call needs to be how much the player is CALLING not the total amount he has in the pot.

[/ QUOTE ]
Of course, but that appears somewhat inconsistent with your raising scheme.

[wallenborn]

[ QUOTE ]
This is all meta information and Orca's idea of a <metadata> tag isn't a bad solution to this, since all applicatios are going to require a place to store optional extra data for aplication-to-aplication interaction that PokerHandXML won't support.

[/ QUOTE ]

I think chat is part of the hand. And comments should be possible, too. Think of the weekly session review pairings. It would be nice if the same application that is used to review the hand could be used to view the review. Popopop replayer can do this and i like that feature, but to do this, comments and annotations have to be stored.

Putting that into a metadata element is one solution. But it creates referencing issues. You have to include reference labels or ids at places in the hand comments refer to. If you do that, you can include the comment right away. Semantically, it's the same.

BTW, we should resist the temptation to start delegating controversial issues to <metadata>. I'm not saying we're already doing that, but i sense the danger.

[ QUOTE ]

I've dealt with a lot of hand history's and pretty much all of them record bets and calls as additives and raises as total.

[/ QUOTE ]

The way this information is obtained is not unimportant. There's three issues: 1. input parsing, 2. legibility of the stored data, and 3. output parsing. Making 3. easy is important, but not if the cost for 1. and 2. get prohibitively large

[ QUOTE ]
A bets $50, B calls $50, C raises to $150, A calls $100, B raises to $450, C calls $300, A calls $300.

to find out how much A has, we cycle through every action A has made and if it is a bet or a call, add it to his total, and if it is a raise do not add it to the total, bet set it to the amount he raised to. Do this for each player.

[/ QUOTE ]

So that's: last bet/raise plus all following calls. Thats non-trivial in some languages. In XSL i think that's ten to twenty lines. Doable, but non-trivial.

The alternatives are:

A bets $50, B calls $50, C raises $150, A calls $100, B raises $400, C calls $300, A calls $300.

or

A bets $50, B calls $50, C raises to $150, A calls to $150, B raises to $450, C calls to $450, A calls to $450.

How do they sound?

[APerfect10]

Scratch that....I'll address this in the morning when I'm not tired.

[chipwiz]

[ QUOTE ]

I think chat is part of the hand. And comments should be possible, too.

[/ QUOTE ]

I think that it is not terribly important but including the chat is so easy to implement that I think we should. It just a matter of having <chat></chat> tags between the actions.


[ QUOTE ]

A bets $50, B calls $50, C raises $150, A calls $100, B raises $400, C calls $300, A calls $300.

or

A bets $50, B calls $50, C raises to $150, A calls to $150, B raises to $450, C calls to $450, A calls to $450.


[/ QUOTE ]

At first I thought second alternative was nicer but say you want to implement a hand-replayer, then you want to know how much of the players stack goes into the pot in each action, then the raise-to/call-to can be a bit tricky (you need to keep track of how much the player has put in the pot already). I also think the format should represent the actual hand history as close as possible, i.e. as little processing of the information (such as calculating raise-to amount) as possible, that is my thoughts on this.