HM to define seat positions better

[Ajax]

This new request will work well with another request that is already getting a ton of support: http://forums.holdemmanager.com/hold...ise-seats.html

Request is to have the seat-positions defined in a consistent way, whether playing 6max or full-ring. Define the positions of all seats based on how far off the button the player is. (I am still a bit confused on how this works in HM right now, 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

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.

If anyone who plays full-ring wants to have each position separated out in a report, or for a custom stat, etc., then they could do it with this design, because every position would have its own number in the database. So if you are a full-ring player but do not like having the first three positions mixed together, then you can create reports and stats with each position. For example, you can have IP1_VPIP, IP2_VPIP, and IP3_VPIP.

[The Minder]

Ajax,

Surprisingly, I find myself agreeing with you. To my way of thinking there are only 3 positions that need to be identified by characters, SB, BB and Btn. If the other positions are numbered anti-clockwise from the button, then the positions just become numeric and are the same no matter how many seats (not bums) are at the table. Forget all about Ep and MP etc and just say that position 5 did such and such. It's up to the user then to determine (or filter) for FR, 8-max, 6-max etc.

A word of caution tho. Your suggestion is only usable if Loki's suggestion gets up.

Anyway, you got my vote... not that I think it counts.

[Witz17]

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 much better.
And if I understand it well in your last passage, that it would also be possible to let even IP1 to IP3 appear in a HUD Popup, then this would even be perfect! Hope this is implemented soon!

One additional comment:
There are still many platforms where you have 10-seat tables so we would need 4 initial positions IP1 to IP4

[Ajax]

I woke up this morning and this was the first thing I checked. Thank you for the votes The Minder and Witz17.

Witz17, you are correct, every position would now work however you wanted to see it. We could even have a table with 15 players and it still would work. The 10th player at a table would simply have 7 in that column, the 11th would have an 8, etc. So if you wanted to make all of those stats for a 15-player table, then you could have positional stats for IP1 to IP9!

The next issue would end up being when the HM development team creates positional stats, how many should they define? My guess is that it will be 7 stats for each positional stat, like I wrote in my first post (so the first four positions would be lumped together into IP_VPIP, IP_PFR, IP_Raise_First, etc.). But if full-ring players want more detail, then they could request it, and the information would be in the database to support it.

So HM development will likely make pre-created positional stats that lump the first four positions at a 10-player table together like this
4 IP_pfr
5 IP_pfr
6 IP_pfr
7 IP_pfr

However, they could give more detail by mixing only three positions together, like this
4 IP1_pfr
5 IP234_pfr
6 IP234_pfr
7 IP234_pfr

Or, they could give even more detail than that by mixing only two positions together
4 IP1_pfr
5 IP2_pfr
6 IP34_pfr
7 IP34_pfr

Or, they could keep all four of them separated, AND have a fifth stat that mixes them together as well, like this
4 IP_pfr
5 IP_pfr
6 IP_pfr
7 IP_pfr
4 IP1_pfr
5 IP2_pfr
6 IP3_pfr
7 IP4_pfr

In that last example, positions 4 through 7 are used twice for the PFR stat; once for mixing them together, and once for separating them.

And as far as reports go, the sky is the limit. With the position-numbers in the database, and if you know how to write SQL, then you could make a positional report that stands on its head and does back-flips with the information.

[Ajax]

A word of caution tho. Your suggestion is only usable if Loki's suggestion gets up.

From what I understand, they like Loki's suggestion and want to do it. But it is going to be a lot of work for development. This thread here is worth a read (post number 3 is actually from you The Minder):
http://forums.holdemmanager.com/mana...mediately.html

When you read that thread, pay close attention to what morny says in posts #15 and #17. Basically, he is saying that they want to do this stuff, but it will take time.

HM DEVELOPERS: Please read all of the thread at the link that I posted directly above.

I would like to end with a shameless plug for a HUD feature (not a stat) that has not yet gotten much support, but I really hope some of you will back it: http://forums.holdemmanager.com/hud-...sizes-hud.html It will show the sample sizes when you double-click with the right mouse (or some other way).

[Ajax]

In this post, I am going to describe how two of the enhancement requests will work together. Here are the two requests:

• HM to recognize # of seats
• HM to define seat positions better

In this example, it is a nine-player table, and Greg is on the button. Here are all of the players:
Joe
Bill
Mike
Greg <-- on the button
Mary
Bob
Shelly
Kim
David

If all of the players at the table are dealt cards, then two things will happen. First, the positional stats for the players will be defined based on the position_number assigned to each player, like this:
6 Joe <-- IP
-2 Bill <-- big blind
-1 Mike <-- small blind
0 Greg <-- on the button
1 Mary <-- CO
2 Bob <-- MP
3 Shelly <-- EP
4 Kim <-- IP
5 David <-- IP

So bill would get BB positional stats, and Mary would get CO positional stats, and Kim David and Joe would get IP positional stats.

The second thing that will happen is that all players will get a number_of_seats_at_table = 9.

Now, lets say that for some reason three of the players sit out, and this time Bob is on the button. The table would now look like this:
* Joe
3 Bill
* Mike
-2 Greg
-1 Mary
0 Bob <-- on the button
1 Shelly
* Kim
2 David

This might look like a 6max table, but it is still a 9max table. So all of the players in the hand will still get number_of_seats_at_table = 9. And the positional stats would be generated for the six players seated at the table, but those stats would never show up at a 6max table unless the user filtered for it to be that way. For example, if Bill openend with a raise, his EP_VPIP stat would go up for full-ring, but it would remain unchanged for 6max (unless the user specifically filtered for it to show up at 6max). In other words, even though only 6 players worth of stats are collected, those stats would all be assigned to a 9-player table, and would not show up at a 6max table unless the user set the filters up specifically to allow that to happen (you can get more detail on those types of filters by looking at this thread here http://forums.holdemmanager.com/mana...mediately.html ).

[Ajax]

Another way to describe how positions could work better is to show how they work now, and then show the difference. Here is how they work now:



(I must give credit for that above image to a poster from another thread here: http://forums.holdemmanager.com/mana...tml#post183941 )

Here is what is wrong in the image:


So the problem we currently have is that MP and EP change based on how many players are at the table.

We can correct the problem like this:


Also, even though I put IP in all four of the earliest positions, they really are all different, because the database will have them separated by storing a 4 5 6 or 7 for each one. That way, even the first four positions at a full-ring table can be looked at closely if someone wants to do that.

[Witz17]

Ajax, I like your way of continuing on finding new ways to explain your point

I just hope that enough users will read this here and vote for this suggestion and of course that the HM developers will give this implementation a higher priority.

[Ajax]

Here is one more!

[IkeB]

I would really like to see the Hijack position specifically to gain a little more clarity into players stealing tendencies. Cutoff is absolutely necessary, but other than cutoff, you're looking at stats that read 'middle position', but in a 9 or 10 handed game, this can be misleading when you look at stats. Some people like to steal blinds, but some people value stealing position from the cutoff and button with less than stellar hands. I do anyway.

As of now, there isn't really any good way of determining if someone's raising from the hijack more than HJ-1,-2. It seems like HEM's design was specifically geared toward 6-max cash games.