#1
|
|||
|
|||
respective limit only scan
If a player sits at ie a PLO 400 and PLO 600 table, it would be nice if the scanner only uses hands from the respective limit.
Is this feature already there? Same would be nice for fullring/6max/HU |
#2
|
|||
|
|||
Yes, both of these are in Database > Database Filters. But there is an issue, which is that if the same player is seen sitting at two different stakes, TableScan will only store the data from the last stake he was scanned at. So it will work correctly on the initial scan, but if you use the list filters to refresh the list, it will just use the data from the last stake the player was scanned at, for all stakes. It's one of my top priorities to fix it, but it's kind of a difficult problem
|
#3
|
|||
|
|||
I select the filter first and not gonna change it. So it is good enough for me.
What are the defaults for "filter database results by table size"? |
#4
|
|||
|
|||
For HU, its 2-2, for 6max, it's 3-6, for Full Ring, it's 7-10
|
#5
|
|||
|
|||
would be nice to have the chance to switch between "filter by stakes" from the database filter menu in the players list instead. the reason why is that you are going to miss players if you dont have enough hands on that limit.
The scan would take longer of course to have th data ready but I would trade that. |
#6
|
|||
|
|||
Could you elaborate on this one, I don't quite understand what you're saying
|
#7
|
|||
|
|||
sure
assume you have a player "DONK" DONK plays at 3 different limits, PLO 200, 400, 600 from DONK you have 2000 hands at PLO 200, 3000 hands at PLO 400, but none at PLO 600 as players change behaviour at different limits you decided to check the "filter database results by stake". this makes the results more accurate for the respective limit but, as the example shows, you will miss DONK at PLO 600 because you dont have a single hand of him at this limit. One way to avoid such a situation would be to specify a minimum number of hands required (at a limit) to perform a "limit only" scan and otherwise just use all hands. An indicator would be needed at the players list to show which method had been used. Another way could be to switch back and forth the 2 methods in any result list. But the first way seems more elegant to me. |
#8
|
|||
|
|||
Ok, I understand, it's an interesting idea, i'll keep it in mind, it would be pretty difficult I think either way
|
#9
|
|||
|
|||
I dont think its hard to implement. you just pull both (overall and current limit) datasets and use the one that fits the # of hands condition. an indicator (like a triangle or background color) would be nice but not a must.
|
#10
|
|||
|
|||
Right now as I said above TableScan just stores one set of stats for each player. So that causes problems with the database filtering if a player is sitting at more than one stake/tabletype that you're scanning. I've been thinking about how to fix it for months but haven't come up with a way I like yet, I don't want to make it any less efficient for everyone using it, and it'll take a lot of work. But it's definitely something I'm going to do, and when I do i'll remember your suggestion
|
|
|