General tutorial for PKO MTTs in HRC:
https://www.youtube.com/watch?v=g3Wwpmk0bGk

First off, chipEV calculations in HRC deal exclusively with chips, not $ payouts of any kind, so these are not suitable for bounty games.

Option #2 is the correct one, you need to use MTT mode and generate stacks for the other tables. Ideally enter the actual payout structure and total chips, but if you can't remember then set it up as winner-takes-all with the remaining regular prize pool as first prize. If you can't remember then make a rough guess, that's still better than your other options.

Your option #1 will not have the correct ratio of bounties to regular prizes, you are playing for a regular pool of 100$ and that won't be right in relation to the pasted PKO bounties. On the other hand #3 will obviously not consider any bounties at all.

Both models will give the same results for the final table. Before the final table you need to use the MTT mode. I'd recommend you use FGS for final tables and MTT ICM for hands before the final table.

Thanks mate.

What about monte carlo (experimental)? What's the core difference in this method of calculation?

You can find an explanation of the Monte Carlo mode here:
https://www.holdemresources.net/blog...nte-carlo-mode

Thank you! So when it's only 3 players left the ante thing should simulate correctly a forced all in for all the players and then I can use it?

For 3 players it should work fine, yes.

I have a couple quick (probably simple) questions...

1. What exactly is table equity?
2. Can you explain the "Range EQdiff" (the red line) to me please?

I feel like it's quite useful but I cannot seem to figure out what it actually means. I've read the help section on it but I didn't understand what it was saying.

Thanks

1) Table equity is the total tournament equity of all players on the active table, before the start of the calculated hand. For single table calculations this equals the total remaining prizes (regular + bounties). For MTT/Bounty calculations displaying the EVs as % of table equity provides a more consistent range of EV values, compared to using the traditional display as % of regular prizes. Note that you can also display the raw $EV by moving your mouse over the EV displays.

2) Looking at e.g. x=10%, the blue line displays the EV of playing the bottom hand of a 10% range. This may be a hand like A9o, but that depends on the situation. The red line displays the cumulative EV of playing all hands of equal or better EV than that hand, ie the entire top 10%, compared to folding everything. This is actually explained with an example at Help: Help Contents: Components, if you need more details.

will we be able to change stack sizes on the fly in already opened hands in the future?

Also I'd loove to see a quiz function someday

best wishes

Regarding changing stack size: We'll introduce an option to open a new calculation based on an existing one along with the save/load functionality. Not sure about the option to actually edit a game tree though.

Hello, i just have run 2 differents basics hands without ante where i am in BTN with 9bb:

hand 1: i'm on BTN with 9bb, the SB has 1bb and the BB has 9bb. in this case HRC recommend for the BTN to push 32.1%, SB 100% and BB call the BTN's push 24%

hand 1: i'm on BTN with 9bb, the SB has 9bb and the BB has 1bb. in this case HRC recommend for the BTN to push only 26.7%, SB 100% and BB to call the BTN's push only 14.2%

In both case one player will be all-in for 1bb 100% of the time, so why the BTN have to shove more when if this player is on SB instead of BB?

The 9bb caller has different pot odds, depending on whether he is in the SB or BB. And there's differing amounts of dead money in the pot for the BU if the other 9bb stack folds.

Hi!

I have some doubts:

1) Can I say FGS 'depth' is the accuracy of calculated results in a FGS sim? if so what do you recomend 'depth 2'?

2) Might sound stupid but I always wanted to know this: when having a simulation done and a hand value is equal to lets say +0.1 Is this 0.1bb eV? so this hand has an expected ev value of 10 bb/100


Thanks in advance!

What does "Best Response" when you click on a range?

Best Response simply selects all +EV hands for the selected range to 100% played. This option will operate on a single range only. This is different from "Run Nash Calculation", that option will attempt to find an equilibrium where all unlocked ranges are in an approximate best-response state.

1) The accuracy of FGS increases with the depth, yes. Try the automatic depth selection as a starting point and maybe increase the depth slightly from there if the calculations still run fast enough.

2) ChipEV calculations show EVs in big blinds, so +0.1 would be 0.1bb, yes. ICM/FGS/MTT models show EVs as % of table equity, this is equivalent to % of remaining prizes (regular + bounties) for single table calculations. You can also display direct $EVs by moving your mouse over the hand grid.

Hi!

What is the best way to study if my shoves will be profitable after someone before me has raised/limped?

I assume this is through the advanced hand feature, but what betting options do you recommend I allow?

This is done via the "Advanced Hand" feature, correct.

For raises, simply enter the raise size in the "Open" line, e.g. "2.5bb" and leave everything else empty/unchecked. Similarly for limps, only check the left checkbox in the Limp line to allow a single limp, leave everything else empty/unchecked.

Be careful when using limps or flat calls, as these can lead to non-all-in Postflop pots and these are calculated as simple check-downs in HRC. For more information check the "Advanced Hand" section of Help: Help Contents.

Thank you for the help and for the quick response!

Also if I have run a nash calculation, but I think my opponent will deviate from this range what is the best way to continue? Do you recommend the "best response" feature or should I lock their range and continue the nash calculation?

Typically you'd want to lock their range and use the Nash Calculation.

Hi prob been answered before but haven't been able to find.
Wondering if HRC has a function to identify icm in large field mtts. I know we can select up to 180 players. Is there a way to say input the avg bubble factor in a 5000 man tourney with 50 players left. I have seen this function on other calculators. Cheers.

There is no restriction regarding the # of players/prizes for MTT calculations, simply enter the prize structure and generate stacks for the other tables, that works just fine even for fields with thousands remaining.

The MTT ICM calculations in HRC are actually very accurate, even for large fields:
https://www.holdemresources.net/blog...uracy-mtt-icm/

OK thanks I see so we just input the entire prize structure and the total chips. But there's no way to get structure for say 2000 tournament typical payout without inputting those numbers yourself ?

You only need to enter the pay jumps, you can skip repeated prizes. Even with a few hundred spots paid, that's rarely more than 20-30 pay jumps to input.

Hi plexiq,

I'm loving your software and I also loved reading your thesis - I think I've read it about six times at this point! I have a few short questions which I was hoping you could answer for me.

(1) ICMIZER just introduced FGS in their multitable ICM simulations. Any chance such a feature will also be included in HRC at some point?

(2) What does the feature 'Full optimization beyond the first level' mean in the FGS preferences? It notes that "if checked, the above settings [using ICM estimates for split pots] only apply to the first level", which to me sounds like a negative thing, and yet it is a recommended option. What does this option do in terms of accuracy and speed?

(3) Data question: does your software collect/store simulations done through your software and/or website?

(4) And, lastly, more out of curiosity, did you ever run extensions of your Master's thesis (like six player games, or larger stack averages), and, if you did, at what point did reasonable FGS depths start deviating substantially from equilibrium?

Thanks a lot!

Glad to hear you found it interesting

MTT FGS is relatively trivial to add, assuming we leave stacks from the other tables static over the course of the calculation. But leaving other tables static seems problematic for spots that are most interesting, e.g. bubble situations, that's why we haven't enabled it.

If you run a bubble spot with e.g. FGS-3 and static MTT stacks then you are essentially calculating ranges under the assumption that no player will bust on other tables within the next 3 hands. This may easily be worse than just using regular ICM for that situation.

Does ICMIZER use static stacks for MTT FGS or do they simulate play on other tables as well?

If you check this option, all of the other optimizations will be active from level 2 forward. This means slightly lower accuracy / higher speed if you leave the depth constant, but it may allow you to run higher depth for increased accuracy overall.

The split pot options should essentially always be checked, you'd need to carefully craft scenarios where split pots make any significant difference to the EQPosts. Splits frequently matter for individual hands, but that's not relevant for the FGS equity calculations. (We may actually just get rid of the split options and always enable the optimizations.)

The general 3-way option is more of a judgement call, if 3-way all-ins happen fairly frequently in your calculated hand then you may want to leave this optimization disabled.

The only user-calculations we store on our end are hands that are explicitly uploaded via "Hand: Share Hand". Results from website calculations are temporarily cached in-memory to improve performance, but not on permanent storage.

We did "full tournament" bounty solves with the thesis framework back when the bounty models were initially added to HRC, to decide on an appropriate bounty model. Didn't run anything with 6+ players or larger stacks though, no.

But I've actually started to dust off the old thesis code recently to get it ready for new runs, especially with PKO.