[ QUOTE ]
Bugs:
1. When the hand ends early (ie no turn or river), the tool lets you continue through a blank turn and river and then gives you the results. Doesn't really break anything, but should stop at the street the hand stops at.
[/ QUOTE ]
This I know about. I am not sure how I want to handle it, and at what layer.
[ QUOTE ]
2. Looking through your example HH, the parser seems to be a bit off. There is never a player on the button. The player who is really OTB is identified as CO and the player to his/her left as SB.
[/ QUOTE ]
[img]/images/graemlins/blush.gif[/img] My technique for labeling players is faulty. I don't see anything obvious in the code. It does get the blinds right at least. I need to step through the code or come up with a new approach. The approach I have is broken for less than 5 players anyway.
[ QUOTE ]
Feature requests (already.. I know [img]/images/graemlins/grin.gif[/img])
1. At the start of the flop, turn, and river, it would be nice to see the pot size (SB for flop, BB for turn and river) to help calculate odds and that street's decision.
[/ QUOTE ]
Already on the list. Once again, not sure which layer it belongs in.
[ QUOTE ]
2. It may be helpful to also track where in the session you are. If I upload 100 hands, you could have somewhere Hand xx/100 or hand xx of 100, etc. This may be just as helpful as having the real hand number.
[/ QUOTE ]
You get a visual reference on the left hand side, but you have a point that it is pretty rough. I will keep this in mind. Not sure where the best place to display it is.
[ QUOTE ]
3. If I decide to "wash" a HH, let the user select the player to be Hero (I'm sure this is already on your list).
[/ QUOTE ]
Hmm, Actually I was pretty happy with the auto-detection of the hero. Why is picking from a list better?
[ QUOTE ]
BTW, what are your plans for other site support besides party? I understand that keeping up with changes to HHs is difficult at best. What about supporting a "common" format to upload? This
HH Converter is pretty decent and seems to be more and more commonly used. I know you have no control of how he converts hands, but it
may help with supporting multiple sites if you were to try and use his 2p2 or FTP outputs? That site also converts multiple ands so it may be a good fit.
[/ QUOTE ]
I might look at it. For some work-related reasons, all the code in this project my be original or under a set of very few, very liberal licenses. Also, I don't want the application to use the internet at all. I want people to be able to set deny it access to the internet and still have it work. (lots of people rely on that for stuff that touches thier poker stuff, and I don't blame them.)
The parser module is seperate from the display level. I need to go back and define a parser interface so I can add more parsers. But I know exactly how that will look and work. The parser architecture I have is a good blue print for cranking out more.
I did consider for a while creating parsers that would create a "neutral" XML format for hands. But it's more work than I wanted to deal with at first. With the parser I have, I could write a module on top that would XML the hands neatly. Sort of like I RTF them now.
I am hoping to solve some of the history file format churn problem by making this a sourceforge project. Then whomever is feeling the pain can provide the fix or at least log a bug and provide sample hands.
Another thing on the list is an RTF to 2p2 format converter. [img]/images/graemlins/smile.gif[/img]
-D