PDA

View Full Version : This needs to be implemented immediately.



green_29
10-04-2010, 03:29 PM
Currently there is no way to separate 6max hands from full ring hands in Holdem Manager. I made a thread about this before and was told that if you set the filter to "less than 7 players for 6max" and "more that 6 players" for full ring then this would be close enough. I always believed that and therefore had no problem.

But today I found that around 10% of my hands at full ring are actually played with less than 6 players at the tables. This will be a lot higher for others since people start tables and I don't.

So this means that if I set my filter to "more than 6 players" the I am going to miss about 10% of my hands. But if I filter it to "more than 5 players" then it is going to involve tens of thousands of unwanted 6max hands.

This is a big problem, 10% of hands is quite a lot to miss. I want to be able to separate 6max hands from full ring hands for obvious reasons, this is not just a usual "suggestion" (which is why I didn't post it in the suggestions thread), its actually really important for anyone playing seriously.

Not only that but surely it would be really easy to put this into the Holdem Manager software since most sites write in the hand history whether the table is 6max or full ring?

Patvs
10-05-2010, 05:18 AM
The GREAT thing about HoldemManager is... if you play a hand at a full ring table:
-with only 6 players (due to players leaving/sitting out)
-with only 2 players (because you're starting up the table)
--> HoldemManager will NOT categorize that hand as a full ring hand.


If you to to Cash Game--> Reports--> WINNINGS SUMMARY
You can see which hands are categorized as 6max (although some of them, and in my case ALL of them since I don't play 6max, are actually played at a full ring table)


Now, if you go to hud options--> additional HUD filters--> you can setup a #players filter. With this filter. It won't use the <6 #players hands, if you're playing full ring. And it won't use the >7 #players hands, when you're playing 6max.

---


I don't fully understand your post.
On the one hand you don't want to lose the 10% of your hands.
On the other hand, you don't want it to include x thousands of unwanted 6max hands when you're playing full ring.

Why would you want your opponents full ring stats to include hands, you played with only 6 players dealt in? What makes that hand so much different than a actual 6max hand?

This is exactly what HoldemManager accomplishes with the #players filter. Since you can setup something like:


http://img715.imageshack.us/img715/3200/clipboard01aa.jpg


(strict separation between HU, 6max, FR hands)


but also, something like this:

http://img245.imageshack.us/img245/7908/clipboard0188.jpg

(overlapping #players, where a 7 handed hand WILL show up in the 6max stats)

The Minder
10-05-2010, 09:05 PM
Patvs. This is a discussion that has been held on this forum many times and there seams to be two points of view.

The first viewpoint, from HM associated people, is that a players playing style is based on the number of players at a table. That they automatically adjust from FR to 6-max dependant on bums on seat (and not sitting out). Hence the filters you mention are probably a viable method of categorizing data.

The second viewpoint is that a players style determines what table they will sit at. If a player enjoys FR then they will sit at a FR and play FR style. Same same for 6-max. In this case, a player may not be likely to change his/her style just because a couple of players sit out or leave the table.

With the emphasis these days on multi-tabling where scant seconds of attention are applied to a single table, it is Hero's underlying philosophy that will shine through (he will revert to form) and he will play the table based on what it is (FR or 6-max), not bums on seats.

In this case, HM is constrained.

My comments only apply to cash games. HM is even more constrained in segregating 6-max/FR tourney data.

green_29
10-06-2010, 03:23 PM
Patvs. This is a discussion that has been held on this forum many times and there seams to be two points of view.

The first viewpoint, from HM associated people, is that a players playing style is based on the number of players at a table. That they automatically adjust from FR to 6-max dependant on bums on seat (and not sitting out). Hence the filters you mention are probably a viable method of categorizing data.

The second viewpoint is that a players style determines what table they will sit at. If a player enjoys FR then they will sit at a FR and play FR style. Same same for 6-max. In this case, a player may not be likely to change his/her style just because a couple of players sit out or leave the table.

With the emphasis these days on multi-tabling where scant seconds of attention are applied to a single table, it is Hero's underlying philosophy that will shine through (he will revert to form) and he will play the table based on what it is (FR or 6-max), not bums on seats.

In this case, HM is constrained.

My comments only apply to cash games. HM is even more constrained in segregating 6-max/FR tourney data.

Exactly.

Full ring is full of mass tablers and they dont play too differently if there are only 6 players at the tables. Possibly with 5, but DEFINITELY not with 6.

A full ring table with 6 players is not a 6max table, its a full ring table with 6 player, there is a massive difference. A - some people dont adjust (mass tablers definitely dont), B - people who play full ring are tighter than 6max players overall, even if they do adjust when the table gets 6 handed.

All of this Ive spoke about is when there are empty seats, if it doesnt count when there are people sitting out then this is a massive problem as I am 100% sure that most people dont really adjust just because some people are sitting out. I myself dont adjust that, and Im a way above average player.

This really needs to be changed, I cant see any argument for the current system that make any sense whatsoever.

green_29
10-07-2010, 11:54 AM
A poll or something should be done on this. Im telling you 99% of players would vote for what I suggested. As Ive said most people dont adjust when there are sitouts.

Patvs
10-07-2010, 01:09 PM
The current system is done precisely because of what you describe.
If you startup a fullring table and are playing headsup for a couple of hands... those headsup hands will NOT be included in your opponents full ring stats if you use the #players filter.

Just use two databases. One to which you import your Full Ring hands, and one for 6max.

green_29
10-07-2010, 02:12 PM
The current system is done precisely because of what you describe.
If you startup a fullring table and are playing headsup for a couple of hands... those headsup hands will NOT be included in your opponents full ring stats if you use the #players filter.

Just use two databases. One to which you import your Full Ring hands, and one for 6max.

I know about the stats filters, the problem is with separating in hem. How am I supposed to separate my 6max hands when they are all now in the same database and this program cannot separate hands based on what type of table you are sat at.

Like I said do a poll, I promise you everyone will vote for how I want it.

The Minder
10-07-2010, 08:08 PM
... Just use two databases. One to which you import your Full Ring hands, and one for 6max.

You are joking, right? Under this philosophy we would need at least 3 dbs. One for FR, one for 6-max and one for all data so that any of the summary reports/graphs in HM would actually make sense. And how do you propose tourney players segregate their data?

I was always under the impression that relational databases were supposed to be a central repository for all data which was then filtered to present the user with meaningful results. Not the other way around.

Ajax
10-07-2010, 10:29 PM
The current system is done precisely because of what you describe.
If you startup a fullring table and are playing headsup for a couple of hands... those headsup hands will NOT be included in your opponents full ring stats if you use the #players filter.


Yes, the current system does prevent the headsup hands from mixing in with your HUD stats when you start up a new full ring table, and that is good. Note that it happens only when you set the "Additional HUD Filters" to do that, and that is good as well. But even though that's all good, it is still not good enough.

The database needs to have a field that indicates if the table was HU, 6max, or FR (possibly even HU, 3max, 4max, ..., 10max, if that is what would be needed to support everyone).

Let's say that all you need to support everyone is to have HU, 6max, and FR. You add that filed to the database, and then you add a filter with two checkboxes for each table type, like this:
HU......[ ]Include 6max...[ ]Include FR
6max...[ ]Include HU......[ ]Include FR
FR.......[ ]Include HU......[ ]Include 6max

The way the current application works, it is as if all the boxes are checked, like this:
HU......[x]Include 6max...[x]Include FR
6max...[x]Include HU......[x]Include FR
FR.......[x]Include HU......[x]Include 6max

If the user wants the system to still behave the way it does right now, then the user can just check all of the boxes.

Everything that is in HUD Options > Additional HUD Filters you would still keep. The six checkboxes would just be added. And they would be added to the reports as well.

Ajax
10-07-2010, 10:37 PM
Right now, the database has one field, something like:
occupied_seats_at_table

But, it needs to have two fields, something like:
occupied_seats_at_table
total_seats_at_table

Then, you can start building in all the functionality around it.

Ajax
10-07-2010, 11:14 PM
I don't fully understand your post.
On the one hand you don't want to lose the 10% of your hands.
On the other hand, you don't want it to include x thousands of unwanted 6max hands when you're playing full ring.


I understand the confusion. Here is another way to explain what we want.


Currently, I have my Additional HUD Filters set up like this:
http://imgur.com/GLBiF.jpg
The way that I have it provides me with a decent amount of overlapping of # of players. But I have to adjust the numbers a bit in order to keep the tables strictly separated.


Now, this is what I REALLY want to be able to do with Additional HUD Filters:
http://imgur.com/KVzsf.jpg
I want to have PERFECT overlapping of # of players (look closely at the numbers on the left and compare them to the first image above), AND I also want to have STRICT separation of tables at the same time!

Ajax
10-07-2010, 11:26 PM
One more thing to try to make all of this clear. Let's say that I were to try to use the current system to set up the filtering exactly how I said that I wanted in my previous post. If I were to try to do it, I could not, because the system would behave like this:
http://imgur.com/ARuBw.jpg

In other words, I attempt to use PERFECT overlapping, but the system always defaults to NO table seperation.

So currently, I am forced to adjust the overlap in order to keep the tables separated.

Ajax
10-08-2010, 12:45 AM
If I keep going, I will end up writing a book. But in pursuit of clearly explaining this, here is one more example.

I currently play at a site that has HU, 6max, and FR, and so as I stated, I want to have strict table separation. But let's say that I play at some unusual site that has HU, 6max, 7max, and FR. I am not sure about this, but I think that I would most likely want to then set up my Additional HUD Filters like this:
http://imgur.com/gPgON.jpg

I would have that perfect overlapping for # of players that I like, but I no longer would be using strict table separation for everything. I would still strictly separate for HU and FR, but I would allow mixing between the 6max and 7max tables.

It is very important to notice that if I play a hand at the 7 max table when there are 7 players sitting at the table, that hand will show up at the 6max table when there are 6 players seated. However, that same hand will NOT show up at the 9max table when there are 8 players seated, even though the # players overlap indicates that it would be allowed to show up (7 to 9), because the # seats filter prevents the hand from contaminating the 9max table.

I hope all of this will help.

Ajax
10-13-2010, 08:57 PM
If anyone wants HM to recognize the number of seats at a table, you can vote for it here.
http://forums.holdemmanager.com/holdem-manager-suggestions/28256-cash-games-hm-recognise-seats.html

morny
10-15-2010, 03:59 PM
This is something we are definitely going to implement, its a big change to our database structure so it will take some time, im not 100% sure how it will work, will we be able to filter the new way only or a combination of both as both are useful but its definitely planned along with better filters.

Ajax
10-28-2010, 02:42 PM
morny,

I just read your above post about a day ago. That is great news! :) I understand though that it is a big task to change something like this, so the time requirement is very understandable.


I made a post in the link I put above (#14), but I think it would be good to cross-post the same information here. There is another change to HM that I think would be very good, but just like this change here (recognize number of seats at table), it would have far-reaching implications on much of the HM code (reports, stats, etc.), because it alters the database schema in a way similar to how # of seats would alter the schema.

The other change that I think would be good is to modify the way that HM looks at position. (I am still a bit confused on how this works in HM, but based on what I do know, it does not appear to be modeled as well as it could be.) If we are going to say that EP MP CO and BTN are the positions as defined in a 6max game, then that needs to be the same for a full-ring game; and the first three seats at a full-ring table then need to be called something like "Initial Position" or whatever.

But regardless of what the positions are called, the positions are how far off the button the player is, so that would be 0 1 2 3 at a 6max table, and 0 1 2 3 4 5 6 at a full ring table. And if we call position 3 EP (and I really do not care if we do or do not), then stats like EP_raise_first and EP_VPIP must be for that position, meaning that same distance off of the button, regardless of whether or not it is at a 6max or full ring table. And there will be that other position for full ring, "Initial Position" or whatever, and the stats for that position like IP_raise_first, will simply not be used at all by the 6max players.

For this to be implemented, my guess is that there needs to be a new column somewhere in the database, something like position_number. That column would have values similar to this:
-2
-1
0
1
2
3
4
5
6

At a 10-max table, you simply put a 7 in that column. Even at an 11-max table (if there ever were to be one), you could put an 8 in that column.

Those values would mean
-2 BB
-1 SB
0 BTN
1 CO
2 MP
3 EP
4 IP (Initial Position)
5 IP (Initial Position)
6 IP (Initial Position)

Then, all stats would be based off of that. For example, the VPIP stats would be
IP_VPIP <-- this stat would not be used by 6max players
EP_VPIP
MP_VPIP
CO_VPIP
BTN_VPIP
SB_VPIP
BB_VPIP

This would be a major change in the code, but many good things would result from it. The meaning of stats like mp_pfr and ep_raise_first would be very clear, and would also be consistent whether you are playing 6max or full-ring.

Please take some time to consider this and let me know what you guys think.

- Ajax

morny
10-29-2010, 12:47 AM
Thanks for this, its also an area that will also be revamped, we realise not everyone likes the current positioning methods and also how we define a 6max,9max,HU game but they are also areas well be revisiting. As you know these will take big modifications so it will require some time. This should probably go in the suggestions forum as when were making updates or putting new implementations in this is where the developers will be researching