The names are stored in UTF-8, so simply converting the name from UTF-8
to Configuration.LOCALE_ENCODING before putting the string in tooltip is
enough. Neat.
The names are stored in UTF-8, so simply converting the name from UTF-8
to Configuration.LOCALE_ENCODING before putting the string in tooltip is
enough. Neat.
The names are stored in UTF-8, so simply converting the name from UTF-8
to Configuration.LOCALE_ENCODING before putting the string in tooltip is
enough. Neat.
All conversions from Grigorij
street0_3BChance
street0_3BDone
street0_4BChance
street0_4BDone
stealAttemptChance
stealAttempted
foldBbToStealChance
foldBbToStealChance
foldSbToStealChance
foldedSbToSteal
foldedBbToSteal
3Bet, 4Bet in Stud does appear to work.
Unable to test steal in Stud games, all example hands in micros do not have a chance (I believe)
All conversions from Grigorij
street0_3BChance
street0_3BDone
street0_4BChance
street0_4BDone
stealAttemptChance
stealAttempted
foldBbToStealChance
foldBbToStealChance
foldSbToStealChance
foldedSbToSteal
foldedBbToSteal
3Bet, 4Bet in Stud does appear to work.
Unable to test steal in Stud games, all example hands in micros do not have a chance (I believe)
The names should be always in UTF-8 encoding. At least for PostgreSQL
the encdoding of the database comes from the time of running 'initdb'
(which is different from 'createdb') and if the encoding was selected or
set to something else at that time, the following error will occur:
File ".../pyfpdb/Database.py", line 1630, in <lambda>
self.pcache = LambdaDict(lambda key:self.insertPlayer(key, siteid))
File ".../pyfpdb/Database.py", line 1661, in insertPlayer
c.execute (q, (site_id, _name))
File "/usr/lib/python2.5/encodings/iso8859_15.py", line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode character u'\u2122' in
position 10: character maps to <undefined>
This happens because 'name' is a regular string as opposed to a valid
unicode object. By forcing the string to unicode and encoding it in
UTF-8 the error goes away. In my case the database encoding was
ISO-8859-15 (latin9) but any other "wrong" encoding would trigger the
same problem.
This is a relatively common problem in python.
It would appear that all-in pre-flop doesn't flag sawShowdown.
Also modified the query to select street0Aggr, as that appears to be wrong at the moment
Copied some of Grigorij's code verbatim for calculating additional stats, still needs adapting.
Also reorder some functions so the corresponding files are more mergeable in future.
Fix from Neko on 2+2
http://forumserver.twoplustwo.com/showpost.php?p=15495528&postcount=2374
"Finally got around to checking this out. Seems great so far. I had issues with some of my party hands that were on No Disconnect protect tables but adding the No DP regex in the PartyToFpdb hand converter seems to have fixed it for me."
PokerStars support can provide a HH archive. The format is similar but not the same as a a standard hh format as it contains an additional line "Hand #X" between each hand.
Patch adds an option -s to GuiBulkImport, which when specified will strip these lines out and continue parsing.
PokerStars support can provide a HH archive. The format is similar but not the same as a a standard hh format as it contains an additional line "Hand #X" between each hand.
Patch adds an option -s to GuiBulkImport, which when specified will strip these lines out and continue parsing.
hhc.readHandInfo(self)
hhc.readPlayerStacks(self)
hhc.compilePlayerRegexs(self)
hhc.markStreets(self)
Is the order, the first correctly failing regex is markStreets
hhc.readHandInfo(self)
hhc.readPlayerStacks(self)
hhc.compilePlayerRegexs(self)
hhc.markStreets(self)
Is the order, the first correctly failing regex is markStreets
Was returning the player name instead of id in the case where the player exists in the database, but wasn't cached already
Removing some merge gunge too
