More PokerStars HT SNG bugs

[cyzo]

1. Fix the payout structures for hyper turbos or see my point #3. I've started a lot of threads like these and emailed hand histories half a dozen times. It sounds like there should be a fix coming next beta version. Unfortunately, since the hyper turbos at different buyins have slightly different structures, I do not expect HEM to have a complete fix for this unless they add a feature to let us change the buyins used for EV calculations, which shouldn't be that hard to do.

2. This has also been brought up multiple times. When one player wins all of the chips (not uncommon), HEM treats the hyper turbo as a normal 6 max sng. 1st gets paid 65% and 2nd gets paid 35%. This is terribly off and affects both EV adjusted and actual winnings.

3. Just make a text file with all the prize structures so we can edit it.

4. Use the "not fast" method to calculate EV when importing hands. When you look at the EV diff for a hand and compare it to the values in the replayer, they are almost always different since you use a slightly faster and less accurate method. At least give us the option to use the more accurate calculation method.

If you need hand histories, see the most recent ones that I have already sent you.

[LotteryGuy]

3. Just make a text file with all the prize structures so we can edit it.

Text file format is too prone for errors.

We need a dialog for editing default prize structure. One should be able to right click on a tournament at Data view page, and then there would be an option: "Edit default prize structure for the tournament".

The window would show places and you could enter the prizes there.

I told already almost a year ago that the current way of doing this is insufficient. It seems that HEM people simply don't care.

[cyzo]

Text file format is too prone for errors.

We need a dialog for editing default prize structure. One should be able to right click on a tournament at Data view page, and then there would be an option: "Edit default prize structure for the tournament".

The window would show places and you could enter the prizes there.

I told already almost a year ago that the current way of doing this is insufficient. It seems that HEM people simply don't care.

Obviously the dialog would be better, but as I have also been asking for this to be fixed over a year ago, moving the stuff into a text file would be easier for the developers. Let us keep our expectations in check.

[Talking Poker]

Please just do something to address these issues. The lack of addressing this is infuriating (and frankly, I have trouble understanding why this is so difficult to fix).

PLEASE!

In addition the the above, mine are acting weirded than usual since I upgraded to 1.11.02b. Now, some 1st place finishes are showing up as $0, not the $215.70 I was used to seeing, and the EV numbers for these tourneys are even more out of whack.

:(

[morny]

Ok, well take your points on board and see what we can do, its not a simple fix when you completely change the structure of how results are entered, stored and calculated but well look into it, the next release is imminent so we wont be able to change anything in that although i believe there is some hyper turbo bug fixes in that version already so let me know if that helps in the meantime

[Talking Poker]

Ok, well take your points on board and see what we can do, its not a simple fix when you completely change the structure of how results are entered, stored and calculated but well look into it, the next release is imminent so we wont be able to change anything in that although i believe there is some hyper turbo bug fixes in that version already so let me know if that helps in the meantime

Thanks for looking into this. Perhaps I haven't researched this enough, but I don't really see what the problem is in the first place. It seems somewhere in HEM's code, it's been incorrectly told that payouts for the $88 hypers are:

1. $215.70
2. $215.70
3. $86.28

Further, it seems when 2 people are KO'd at the same time, HEM thinks it should do some sort of mathematical calculation to split the prize money, when in fact it should just pay based on the above every time, based on finishing position (in a multi-bust scenario, whoever had more chips is awarded the higher finishing position).

I would think simply correcting the logic to tell it the payouts are actually the following and to NOT do that additional prize money chop logic would correct the problem:

1. $215
2. $215
3. $87.68

I don't know if this is a problem for other buy in levels or not, but I would think it would be the same fix regardless... just getting the right numbers into the system and skipping the additional prize money chop logic.

I apologize if I am over-simplifying the problem here, but this is how it looks from a user's perspective.

[LotteryGuy]

There are two separate issues here.

1. HEM regards HT SNGs as normal 6-max tourneys with 2 top spots paid. Your solution applies to that problem.

2. PokerStars changing HT SNG payout structures slightly over time. For example, the HT SnGs to Sunday majors have had at least three different prize pool structures during their existence.

First structure had no rake, and the two latter ones changed the buy-in and 3rd place payout a little.

I see HEM has four options going forward with the support for HT SnGs:

1. HEM makes no assumptions about prize pool structure during play, the prize pool is determined from tourney summary when it is imported. This is obviously the worst option.

2. HEM staff constantly monitors all HT SnG types at PokerStars for changes in prize pools, and keeps HEM updated accordingly. This could require a faster update cycle than is currently done and would use much resources at HEM.

3. Introduce a way for users to define default prize pool structures that are used with SnG tournaments.

4. Upon importing tournament summaries for SnGs, ask user if he would like to apply that particular prize structure to all future SnGs of that type. HEM would then store this prize pool structure for later use.


The current situation which depends on user feedback to HEM staff and their interest in fixing structures simply does not work. It is actually worse than option 1, because the current model gives out the impression that data on those tournaments is correct, when it might not actually be.

[Talking Poker]

There are two separate issues here.

1. HEM regards HT SNGs as normal 6-max tourneys with 2 top spots paid. Your solution applies to that problem.

2. PokerStars changing HT SNG payout structures slightly over time. For example, the HT SnGs to Sunday majors have had at least three different prize pool structures during their existence.

First structure had no rake, and the two latter ones changed the buy-in and 3rd place payout a little.

I see HEM has four options going forward with the support for HT SnGs:

1. HEM makes no assumptions about prize pool structure during play, the prize pool is determined from tourney summary when it is imported. This is obviously the worst option.

2. HEM staff constantly monitors all HT SnG types at PokerStars for changes in prize pools, and keeps HEM updated accordingly. This could require a faster update cycle than is currently done and would use much resources at HEM.

3. Introduce a way for users to define default prize pool structures that are used with SnG tournaments.

4. Upon importing tournament summaries for SnGs, ask user if he would like to apply that particular prize structure to all future SnGs of that type. HEM would then store this prize pool structure for later use.


The current situation which depends on user feedback to HEM staff and their interest in fixing structures simply does not work. It is actually worse than option 1, because the current model gives out the impression that data on those tournaments is correct, when it might not actually be.

The current situation doesn't work because the HEM staff doesn't implement the changes after receiving the user feedback. I actually think the current model would be ideal (certainly a lot less programming that #3 and #4, which I agree are the optimal long term solutions), if they would actually update the software when multiple users tell them it needs to be updated, which would most definitely happen within 24 hours of Stars making any changes.

OK, maybe it's not the "ideal" solution, as there could still be some corrupt data getting through in between releases (mind you, ALL the data is currently corrupt, so this wold still be a huge step forward), but it's a solution that should be the easiest for the HEM staff to implement and would make most users happy.

[cyzo]

The EV calculations use the 65%,35% structure regardless of whether the data for actual winnings is correct. Check out the ICM tab of the replayer to see.

[Talking Poker]

The EV calculations use the 65%,35% structure regardless of whether the data for actual winnings is correct. Check out the ICM tab of the replayer to see.

Oh wow... I never even realized this, but I'm more concerned about the actual results than the EV stuff. I mean, fixing that at the same time would be nice, but at least for me as a player, isn't nearly as high of a priority. EV in hypers doesn't mean much anyway as tons of times the correct EV play would result in -EV on the graph.