Poker Hand XML

[TSchauenberg]

[ QUOTE ]

Not sure what you meant about the deals?


[/ QUOTE ]

I meant the following:
* observer mode - no dealt to's
* hero mode - one or more dealt to's depending on who actually is dealt cards

For example, sites often have omnipotent hand histories where they would have 10 dealt to's for all 10 players.
If in the High Stakes tournament both durrr and flawless_victory gave me each their copy of the same hand with a single dealt to, I would like to be able to include both dealt to's in the same single hand as a way of combining that information in an intuitive way.

[ QUOTE ]

Raising:

playerA bets $50, playerB raises to $150

<action type="bet" playerid="playerA" amount="50" />
<action type="raise" playerid="playerB" amount="150" />

I am saying that a raise should be the amount you raise to instead of the amount that is over the current bet (I think we all agreed on this I was just makign the point in the comments of the xml to be clear).

So we do the above INSTEAD of blow..

<action type="bet" playerid="playerA" amount="50" />
<action type="raise" playerid="playerB" amount="100" />


[/ QUOTE ]

Can you extend your example for player A bets $50, player B raises to $150, player A raises to $500? I just want to be clear what happens when players make multiple actions in these cases and commit money more than once.

[ QUOTE ]

I still think that returning bets should be done as an action during a round. A player who has an uncalled bet is always returned that bet on the same street that the bet is uncalled and never at showdown.


[/ QUOTE ]
My view is as follows: Sites either return uncalled chips separately and not in win events, or they leave it in the win events, or the hand does not have any chips to return and it is moot. It's easier to look for just in the summary section and it is basically like a win that isn't determined by the quality of your hand.

[Shoe Lace]

[ QUOTE ]
and those already include who wins and who looses, it'd be a simple matter of transferring that to an attribute. No calculation is done neither place.

[/ QUOTE ]

LDO, but look at the text I quoted. He said we shouldn't include who won/lost. If we didn't, then how else would we get who won without determining hand strength?

[ QUOTE ]
Now this is some funny stuff. You cannot compare iterating integers to parsing the XML file, taking care of all player actions, counting the pot together, deducting rake, jackpot amounts and so forth. The thing is that that requires some serious code to parse the XML and count the sum, there is absolutely no reason for the converting application not to do this along the way as is required anyways.

And if you think I'm talking about speed, you're dead wrong. I'm talking about code complexity.

[/ QUOTE ]

The parser (say a web converter, which would actually be reading the XML file) would be keeping track of each and every element/attribute.

In order to display:

[Flop]
Hero bets $253.58

...it obviously needs to know the "value" field of street 2 for each player (which means he knows their position, name, and action as well) no matter what. So really, yes it does just boil down to math because the info is getting parsed either way.

The hand converter would likely have this value stored in a local property of some class. If he has to go back and reparse the entire file when it comes to figuring out the pot size then he's retarded. That is the nicest way I can say it. [img]/images/graemlins/laugh.gif[/img]

[Tickner]

[ QUOTE ]
Can you extend your example for player A bets $50, player B raises to $150, player A raises to $500? I just want to be clear what happens when players make multiple actions in these cases and commit money more than once.

[/ QUOTE ]

<action type="bet" amount="50" playerid="playerA" />
<action type="raise" amount="150" playerid="playerB" />
<action type="raise" amount="500" playerid="playerA" />

In otherwords, a raise amount is always the total amount a player is raising to. That way we dont have to keep adding up the amounts each player has in the pot (although we have to do this anyway for some things).

[OrcaDK]

[ QUOTE ]
[ QUOTE ]
and those already include who wins and who looses, it'd be a simple matter of transferring that to an attribute. No calculation is done neither place.

[/ QUOTE ]

LDO, but look at the text I quoted. He said we shouldn't include who won/lost. If we didn't, then how else would we get who won without determining hand strength?

[/ QUOTE ]
Alright, I might've misunderstood you here then. So you're into us including who won the hand? If that's the case, we agree [img]/images/graemlins/smile.gif[/img]


[ QUOTE ]
[ QUOTE ]
Now this is some funny stuff. You cannot compare iterating integers to parsing the XML file, taking care of all player actions, counting the pot together, deducting rake, jackpot amounts and so forth. The thing is that that requires some serious code to parse the XML and count the sum, there is absolutely no reason for the converting application not to do this along the way as is required anyways.

And if you think I'm talking about speed, you're dead wrong. I'm talking about code complexity.

[/ QUOTE ]

The parser (say a web converter, which would actually be reading the XML file) would be keeping track of each and every element/attribute.

In order to display:

[Flop]
Hero bets $253.58

...it obviously needs to know the "value" field of street 2 for each player (which means he knows their position, name, and action as well) no matter what. So really, yes it does just boil down to math because the info is getting parsed either way.

The hand converter would likely have this value stored in a local property of some class. If he has to go back and reparse the entire file when it comes to figuring out the pot size then he's retarded. That is the nicest way I can say it. [img]/images/graemlins/laugh.gif[/img]

[/ QUOTE ]
You're not really understanding the problem I'm laying out. Yes, if we're completely parsing the hand, we will know the final pot size. But if we're simply reading the XML file, transforming it into another format, only interested in the overall summary (win/loss), it would be a great help not having to parse the complete action to get the final pot size and net win/loss.

[mikechops]

[ QUOTE ]
[ QUOTE ]
I don't see the harm in having an optional attribute for player reads. I don't think anybody is proposing making this mandatory. All rvg is saying is that he will want to add player reads/notes for some hnads and he would like to get agreement on the best way to do this. My understanding of xml is limited but if a parser is expecting :-

<seat id="7" name="koraaf" stack="359.8" active="true" ante="0"/>

it should not break if it gets:-

<seat id="7" name="koraaf" stack="359.8" active="true" ante="0" read = "85/40/0.1 DONKEY!"/>

The advantage of specifying at this point how reads should be stored, is that anyone writing an application using rvg's reads will also be able to take advantage of anybody else's app that exported reads in the same standard.

Like I said I don't know much about xml and if we would have to include a blank field for players with no read data, then I withdraw everything I just said.


[/ QUOTE ]
If we are to do this, then it must not be via an attribute, that leaves us far too few options as we can't even allow CDATA in there. I propose that we add a <metadata> element to the hand of type CDATA. This metadata section could then include any number of XML structures, delimited text or whatever, containing the reads, meta instructions and so forth. That'll be an optional element and any parsers can simply ignore that element unless they have a reason not to.


[/ QUOTE ]

Sorry I didn't understand this. What is the problem with including an attribute for the reads?

[TSchauenberg]

[ QUOTE ]
[ QUOTE ]
Can you extend your example for player A bets $50, player B raises to $150, player A raises to $500? I just want to be clear what happens when players make multiple actions in these cases and commit money more than once.

[/ QUOTE ]

<action type="bet" amount="50" playerid="playerA" />
<action type="raise" amount="150" playerid="playerB" />
<action type="raise" amount="500" playerid="playerA" />

In otherwords, a raise amount is always the total amount a player is raising to. That way we dont have to keep adding up the amounts each player has in the pot (although we have to do this anyway for some things).

[/ QUOTE ]
I guess this implies that for sites which do not use "raises to" notation that you find it reasonable to push the complexity of figuring out this information into the site to PokerHandXML converter?

These types of conversions have to be done somewhere, but at this point I do not have a good reason for arguing one way over the other at which step of the conversion they should be done. I just wanted to point out this implication explicitly and see yours and others thoughts on it.

[Shoe Lace]

[ QUOTE ]
Alright, I might've misunderstood you here then. So you're into us including who won the hand? If that's the case, we agree

[/ QUOTE ]

Of course, go back a couple pages. I have a win/loss action for each player in the showdown.

[ QUOTE ]
You're not really understanding the problem I'm laying out. Yes, if we're completely parsing the hand, we will know the final pot size. But if we're simply reading the XML file, transforming it into another format, only interested in the overall summary (win/loss), it would be a great help not having to parse the complete action to get the final pot size and net win/loss.

[/ QUOTE ]

I think we have to look at the bigger picture though. A format that rules supreme for the majority of applications using the format.

It doesn't seem logical to make the file size of each hand ~15% larger just to make "hand summary applications" happy.

[mikechops]

[ QUOTE ]
[ QUOTE ]
Can you extend your example for player A bets $50, player B raises to $150, player A raises to $500? I just want to be clear what happens when players make multiple actions in these cases and commit money more than once.

[/ QUOTE ]

<action type="bet" amount="50" playerid="playerA" />
<action type="raise" amount="150" playerid="playerB" />
<action type="raise" amount="500" playerid="playerA" />

In otherwords, a raise amount is always the total amount a player is raising to. That way we dont have to keep adding up the amounts each player has in the pot (although we have to do this anyway for some things).

[/ QUOTE ]

I don't really have a position on the "raise to $x" or "raises putting in an additional $x" debate. However if we are going with "raise to", I think we should be making calls, "call to"

So the action would be:-

<action type="bet" amount="50" playerid="playerA" />
<action type="raise" amount="150" playerid="playerB" />
<action type="raise" amount="500" playerid="playerA" />
<action type="call" amount="500" playerid="playerB" />

It just seems more logical to me to have the size of the bet/call/raise always be either the additional chips for that action, or the total amount of chips a player has put in so far this round. Mixing them up for different actions doesn't make sense - to me at least!

[wallenborn]

[ QUOTE ]
It just seems more logical to me to have the size of the bet/call/raise always be either the additional chips for that action, or the total amount of chips a player has put in so far this round. Mixing them up for different actions doesn't make sense - to me at least!

[/ QUOTE ]

QFT

Let's keep an eye on implementation, too. How would a programmer implement a routine that calculates the pot size at a given point in the hand? If the action-amounts always denote the amount the player put in with that action, it's very simple: just add up all amounts from all actions. If they denote the amount a player raised to or called to, it's a little more complicated: find the last action for each player in each round, and add these. But if the notation treats bets, calls and raises differently, things could get very messy.

[OrcaDK]

[ QUOTE ]
[ QUOTE ]
Alright, I might've misunderstood you here then. So you're into us including who won the hand? If that's the case, we agree

[/ QUOTE ]

Of course, go back a couple pages. I have a win/loss action for each player in the showdown.

[ QUOTE ]
You're not really understanding the problem I'm laying out. Yes, if we're completely parsing the hand, we will know the final pot size. But if we're simply reading the XML file, transforming it into another format, only interested in the overall summary (win/loss), it would be a great help not having to parse the complete action to get the final pot size and net win/loss.

[/ QUOTE ]

I think we have to look at the bigger picture though. A format that rules supreme for the majority of applications using the format.

It doesn't seem logical to make the file size of each hand ~15% larger just to make "hand summary applications" happy.

[/ QUOTE ]
Where do you get the 15% from? If you look back just a short way someone proposed that we include this in the players section, the section where we already note the players starting stacks, name and so forth. We could simply add the net win/loss and hand win/loss status here, that would take up very very little space.