pyfpdb/RushNotesReadMe.txt

   1 aux to write fpdb data to player notes on Full Tilt
   2 ---------------------------------------------------
   3
   4 by Gimick 30th Dec 2010
   5
   6 RushNotesAux - auxillary processed attached to the full tilt hud
   7                 builds up fpdb notes "queue" for each villain met while the autoimport is running
   8                 uses HUD aggregation stats to do this
   9
  10 RushNotesMerge - stand alone process to merge the existing ftp notes, together with queue
  11                  produced by Aux.
  12                 the output file can then be renamed to become the new ftp notes file
  13
  14 Important info:
  15 The Merge process can only be run when ftp client is shutdown
  16  - otherwise ftp overwrites the xml on exit.
  17
  18 Existing ftp notes _SHOULD_ be preserved, but this isn't guaranteed,
  19  you have been warned!
  20
  21 Existing colour codings should be preserved,
  22  this process does not change or set colourcodings.
  23
  24 Copies of the live ftp notes file should be preserved everytime
  25   RushNotesAux (i.e. the HUD is started).  If you play at different
  26   rush tables, the backup will be created several times.
  27
  28 The AW is hard-coded with just the table names of Micro Rush Poker,
  29   and should ignore all other hands.
  30
  31 What might not work?
  32 --------------------
  33
  34 This should work with windows sourcecode version, but will not work with the exe download.
  35 Hasn't been tested for co-existance with other sites, feedback welcome.
  36 Whenever FTP change their notes file format, this will all break rather spectacularly,
  37     you have been warned!
  38
  39 Getting started:
  40 ---------------
  41
  42 1. Set the Hero aggregation to alltime.  hero_stat_range="A"
  43  This overcomes a sqlite "bug" which has nothing to do with auxillary windows
  44   not doing this will slow processing down to about 1 hand per minute.
  45
  46 2. Set the site_path to be the folder containing the FTP notes xml file
  47 (on wine this is normally site_path="/home/blah/.wine/Program Files/Full Tilt Poker/")
  48
  49
  50 Wire-up the aux process:
  51 -----------------------
  52
  53 <aw class="RushNotes" module="RushNotesAux" name="Rush1"> </aw>
  54 <game aux="Rush1" cols="3" db="fpdb" game_name="holdem" rows="3">
  55
  56 or whatever works for you.
  57
  58
  59 Play some poker
  60 ---------------
  61
  62 Start Autoimport, and rearrange the on-screen stats out of the way
  63     (the full HUD must run, killing the HUD kills the AW updates)
  64
  65 Play whatever you want
  66
  67 Stop the autoimport
  68
  69 Exit the Full tilt poker client (ensure it has fully stopped with ps -A)
  70
  71 execute the following:
  72
  73 ./pyfpdb/RushNotesMerge.py "/home/foo/.wine/drive_c/Program Files/Full Tilt Poker/myname.xml"
  74
  75 A revised notes file (blah.merge) should automagically appear in the full tilt root directory.
  76 If you are happy with it, replace the existing (myname.xml file) and delete the .queue file.
  77
  78
  79 Since the updates aren't real time, it would be ok to play the rush
  80     session with fpdb inactive, but before quitting any of the tables,
  81     start the HUD and wait for it to catch-up processing all the hands played.
  82
  83
  84 Summary
  85 -------
  86
  87 This is very rough and ready, but it does what I set-out to achieve.
  88
  89 All feedback welcome, and if this is useful as a basis for general notes
  90  processing in future, then thats great.
  91
  92 As I find bugs and make improvements, I will push to git.
  93
  94
  95 Much more information below:
  96 ----------------------------
  97
  98 Background
  99 ----------
 100
 101 When playing rush poker, some sort of rudimentary HUD would answer simple questions
 102 like "is this allin overbet being made by a nit, or a maniac".  Although some
 103 notes may have been made previously, some statistics would help to backup the decision.
 104
 105 Currently fpdb cannot support rush because the HUD is always 1 hand or more
 106 behind the current action.
 107
 108 The only way to do this at the moment is to switch to GuiPlayerStats and make a quick
 109 enquiry by player name.  However, this effectively times you out of all other
 110 action if multitabling.
 111
 112 Full Tilt situation
 113 -------------------
 114
 115 Full Tilt notes are stored in xml format ("hero.xml").  Previously these could
 116 be updated while the game was in progress, however, FullTilt now cache the
 117 notes and write them out when the application exits.  This makes it impossible
 118 to use the notes as a real-time HUD, and therefore real-time huds are now
 119 forced to screen-scrape or poke around in the client memory.
 120
 121 Accepting this a limitation, this implementation updates the notes only once
 122 the FullTilt client has been closed.  Obviously, the villain HUD stats are only
 123 as at the end of the last session, however, it is hoped this is significantly
 124 better than having nothing at all.  As the hero's hand history increases, the
 125 notes should progressively mature in accuracy.
 126
 127 Preamble
 128 --------
 129
 130 Note that this implementation was written purely to be "good enough" to work
 131 for the author, and is not intended as package or production quality.  It
 132 is contributed as a starting point for others, or for experimental use.
 133
 134 Thanks to Ray Barker who gave a great deal of help throughout.
 135
 136
 137 The implementation
 138 -------------------
 139
 140 RushNotesAux is an fpdb auxilliary process, and is called for every hand
 141 processed by autoimport.  Each villain has a note prepared based on the current
 142 fpdb data, and this note (in XML format) is stored in a queue file.
 143
 144 Auxilliary windows were chosen because
 145 a) the author has limited fpdb and programming skill
 146 b) the auxillary windows handler is well documented and supported
 147 c) any code created has access to the full range of stats with little or no extra work
 148 d) runs within the HUD, so the aggregation parameters are already available
 149
 150
 151 Limitations
 152 -----------
 153
 154 The notes are only regenerated if a hand is played against the villain.  The
 155 process does not "bulk load" notes based upon all the player stats in FPDB.
 156
 157 It is hoped that due to the relatively large hand volume and relatively small
 158  player pools, this limitation will be largely overcome after a few sessions
 159 although there will obviously be a number of players with no fpdb note.
 160
 161 The aggregation parameters used for the notes are based upon the HUD parameters.
 162  (with the exception of the hand-ranges, which uses its' own criteria (see source)
 163
 164 Stopping and starting the HUD will erase the previously created notes queue file.
 165
 166 The HUD must run, so the individual player popups need to be manually relocated.
 167
 168 Although hard-coded for micro RUSH tablenames, the auxilliary window  could
 169 probably happily update notes of all cash and tournament players.
 170
 171 Process overview
 172 ----------------
 173
 174 1/ The HUD process is started.
 175 1.1/ when the first hand is received, a queue file is created if not already there, and
 176 a copy of the current live xml note file is created as a security backup.
 177 2/ For every hand played, the auxillary window is called
 178 3/ Based upon the players in the hand, fpdb will be interrogated
 179 and key stats are formatted in xml-style and written out to a holding file.
 180 4/ At the end of the session, the HUD is stopped and the poker client closed
 181
 182 5/ The user can then review the contents of the holding file.
 183 6/ A process is begun to "merge" the holding file into the existing player notes
 184 7/ A new "merged" file is created.  The process attempts to preserve any
 185 existing notes, but this cannot be guaranteed.
 186 8/ The user can review this merged file, and if they are happy,
 187 they replace the existing note file.
 188 9/ Note that this process never updates the live notes file in situ, but
 189 there is a risk that something goes wrong, and that existing notes could be destroyed.
 190 10/ the queue file can be deleted to reduce re-processing next time.