Mine is 1.3.6, so it does not show the pop-up message on the database. But here is the screenshot.

https://ibb.co/J222mRS

In your screenshot, GTO+ is in database mode.
It says that at the time of trying to solve the tree, it required 3GB, which was not available (it's available now, but apparently not at that time).

Can you upgrade to v137 and try to process the database again?
The popup should tell you how much was required, and how much was available, at the time of solving.

https://ibb.co/vsJPv3c

You can see the estimations are inconsistent, which you may point out that it might be different between "now" and "at that time".

However, I tried to clear database (or 1 flop), and re-added, then it is running now.

Hi Scylla, I understand the meaning of the "smoothing" bet size toggle. However, would you please explain how it seems to reduce the required memory to solve significantly?

Yes, that works. That's actually the second place I looked hoping to find a more precise number.

Any idea when the next patch is coming out with this included?

It will probably be released later today.

It prevents spots where a bet puts both players almost all-in, thus removing the required number of betting actions.

Let's assume we are OOP 3B
BB 3bets vs BTN
we ran the sim and get the GTO solution
is it possible to have a feature/option to keep IP strategy the same ( without him knowing that we ( OOP 3bettor ) check full range on certain board )
i.e we play a check full range on 678 instead of checking 79.5% and betting 21.5%
or the only way is to nodelock for both players?

Then it should be more relevant if stacks are short, but it saw that it reduces the memory a lot, even at 100BB deep.

When the bet sizes are smooth, it should show the smooth sizes on the tree (instead of pre-set sizes), doesn't it?

I just want to understand and implement the strategy correctly.

You would need to nodelock for both players, and select which decisions you'd like to remain locked.

Even when stack are deep, eventually, with enough bets being made, stack will become short.
A tree with deep stacks will contain hundreds of sub-trees where the stacks are short, so the memory reduction will apply to both short and deep stacks.
And yes, the relevant sizes are displayed in the tree.

Hello Scylla,

is it possible to use GTO+ for solving post flop spots in satellites? I'd be interested especially in end game, where ICM is the huge factor.

Hi,

I'm sure it's been asked before, but is there any chance of you expanding the playing vs. solution to allow drilling of specific nodes in a database?

So I load up 50 sims in the program with the same tree and then select the node where flop is checked through, and then OOP bets 50% for example. And then I can only get faced with that decision from IP on all the sims in the database for different turn cards without having to play the flop.

As long as the number of prizes is at most 6, and the number of players is at most 10, then the Sit&Go tab should be sufficient for this.

Ok, we can consider it for future releases.

Would it be possible to write the code to make 'Lock hand for hero'->Range [choices] work with 'Play vs database' and not just 'Play vs current tree'??

I would find that quite useful. Thanks as always for a wonderful product and support!

This would unfortunately not be possible, given that different flops have different statistics.

For example, here's the stats for a monotone flop:



And here's the stats for a trip flop:



Other flops will have less expressed differences, but there as well, stats from one flop will often not apply to a different one.

Yes I understand there are going to be difficulties given how dynamic different boards can be, but cant you just write the appropriate exclusionary code for the certain parts of range or flops when they come up?

I feel like there is likely a solution, it's just how big of an ask is it to find one?

Is there a way to only lock specific combos within a strategy? I believe that is possible in Monker. For example, lets say to simplify my strategy I decide I always want to check back top set and always bet OESD at 50% on a specific flop. I would like to see how the solver reacts with the rest of the range when those combos are locked at a specific frequency. From what I can tell I can only lock the entire range.

Is there a way to force your solver to determine which bet sizing shows the most EV across the entire range on any given street (e.g. flop) and use only that bet sizing for betting on that street? Can you do that for each street?

Different flops have different stats, and it's not objectively possible to translate stats from one board to a different one.

We did initially try to add this, and it's available in CREV.
However, it turned out to be a very user unfriendly feature.
One of the problems is that the range needs to be edited twice:
Edit 1) You need to set which weight you want to use for which hand
Edit 2) You need to set which hands you actually want to lock
If there were 10 hands in a range, then this would be an achievable goal.
However, with there being hundreds of hands in a range, it's easy to lose sight of what has been selected and what has been locked.
We tried for about a month to get it to work, but eventually decided that it was better to leave this out, and keep the interface easier to work with.

When playing GTO, any bet size will perform almost exactly the same as any other bet size.
Because of this, it's not possible to determine which bet size shows the most EV; all bet sizes perform the same.
You can test this for yourself by building the same tree, but for different bet sizes.
After that, solve the trees and compare their overall EV (the EV below the table in OOP's very first decision).
As you'll notice, the overall performance remains the almost the same, regardless of the bet size.

If range stat selected = random board available
then use board

else new board


It seems like there should be a programmatic solution:
either include the board that doesnt have the stats available, without the stats
or dont include the board since it doesnt have the stat available.

I really hope you would consider finding a way to make this work. It seems there are much more board stat types that are going to be commonly available then not. And if they dont work, just dont include that board or that stat.

Would love to see this (why I press on asking )

Ok, I will consider it for future releases.