Hi scylla, big fan. Long time listener, first time caller.

Is there a way to manually edit a tree and then update all boards within the database to use that new tree? Specifically, I am looking to run a database of boards with no flop checks and multiple bet sizes. I have a database of ~30 boards and I'm looking to find EV loss and range differences with and without a flop check back. Is there a way of updating all trees in the database after using the "edit tree" function to this effect?

Thanks.

Solved.

Nvm, I was able to do it by exporting flops to a .txt file and then when I imported them they all copied the original database.

Love you.

Yes, this is indeed done by clearing the database, and rebuilding it from the edited tree.

I can't build a tree when assigning player 1 this range :
AdKd,AdQd,AdJd,AdTd,Ad9d,Ad8d,Ad7d,Ad6d,AdKh,AdKc, AdKs,KhQh,AdQh,AdQc,AdQs,KhQc,KhQs,AdJh,AdJc,AdJs, AdTh,AdTc,AdTs,Ad9h,Ad9c,Ad9s,Ad8h,Ad8c,Ad8s


I guess I would have the same message for P2

The problem is that if the turn is Ad and the river is Kh (or vice versa), then the player has no range. To get around this, just add a tiny fraction of another combo. So, for example, the following range should work, due to the addition [0.01]2d2s[/0.01]:

AdKd,AdQd,AdJd,AdTd,Ad9d,Ad8d,Ad7d,Ad6d,AdKh,AdKc, AdKs,KhQh,AdQh,AdQc,AdQs,KhQc,KhQs,AdJh,AdJc,AdJs, AdTh,AdTc,AdTs,Ad9h,Ad9c,Ad9s,Ad8h,Ad8c,Ad8s,[0.01]2d2s[/0.01]

I didn't understand you answer as the board is set till the river already.
Anyways, I updated the range, but still get the same message for P1.

My apologies; I think that I misread the board.
Can you please try the range below?

AdKd,AdQd,AdJd,AdTd,Ad9d,Ad8d,Ad7d,Ad6d,AdKh,AdKc, AdKs,KhQh,AdQh,AdQc,AdQs,KhQc,KhQs,AdJh,AdJc,AdJs, AdTh,AdTc,AdTs,Ad9h,Ad9c,Ad9s,Ad8h,Ad8c,Ad8s,[0.01]5d5s[/0.01]

ha, it works now (I didn't even see the board conflict, lol).
Strangely, I could then build a tree when removing the 55 combo.
Ty

Unreal solution in this 1 street toy game where OOP has a betting range of nut flushes as value, and A high nut flush blockers as bluffs.

- why does IP call 75% of the time with his A high Flushes (nuts) ? (why not 100% ?)
- because of OOP betting range, how can IP even call with non existent hands ?

OOP has :
AdKd,AdQd,AdJd,AdTd,Ad9d,Ad8d,Ad7d,Ad6d,AdKh,AdKc, AdKs,KcQc,AdQh,AdQc,AdQs,KhQc,KhQs,AdJh,AdJc,AdJs, AdTh,AdTc,AdTs,Ad9h,Ad9c,Ad9s,Ad8h,Ad8c,Ad8s

IP has :
JJ-99,77,AdQd,AdJd,AdTd,Ad9d,Ad8d,Ad7d,Ad6d

Board : 3d 3h 2d 4d 4s
Pot 100, Stack 50
dEv : 0
Card removal is on => is it working ??

Link to solution :
https://drive.google.com/file/d/1gUG...ew?usp=sharing

I get a different solution over here.
Are you using v134, or perhaps an older version?

v134 too.
no rake.

I wonder what other factor I could have left out.

Ok, I sort of see the problem.
Basically, OOP is exclusively betting Ad hands.
So with his entire betting range, he's locking out the Ad part of IP's range.
Because of IP's Ad range being locked out, it should not even be displayed.

There's however 1/millionth of a combo of KQ in OOP's betting range as well.
Because roughly 1 in a million hands being KQ, IP's Ax range is now displayed.
For some reason there's a fold in there.

So it's some exotic scenario that has no effect on the calculations overall.
This basically never happens.
Almost without exception, when OOP bets, he has an Ad, so that IP can not have an Ad himself.

I can't immediately see why there's a fold, but I will take a look in the engine on Monday.

Hello scylla, is it possible to edit tree on turn on aggregated trees. Ect i solve 111 flops. and i want to have same inputs on flop, but have different bet size on turn. I m looking which bet size is better on turn based on turn cards. I figure out how to do on one flop at time.

First and foremost, thank you very much for this amazing tool Scylla!

Is there any Chance that there will be the same "Database distribtutions" Overview for Player 2 like for Player 1?

For Example Button vs EP 3BET - we can only see Player 1 Perspective and not from player 2, when it comes to betting frequencies. Will there be anytime an update?

Thanks a lot!

A navigator was added in v129.
It can be used to navigate to Player 2's decision.
See the screenshot below.

A requirement for the navigator is that:
1) All trees in the database are identical (same bets, pot, ranges)
2) The preflop ranges are suit symmetrical (So AA,AhKh is not symmetrical, because there's AhKh, but not AcKc,AdKd,AsKs)
3) The database was solved with v129 or higher

It's possible to edit all trees in a database.
For this, clear the database and rebuild it from the edited tree.

Bet sizing may however not be something to spend too much time on.
For a perfect player, any bet size will perform nearly exactly the same as any other bet size.

Testing bet sizes
You can test this for yourself by building two trees; one for each bet size. Then, solve the trees and compare their overall performance. The overall performance is OOP's EV below the table in his very first decision. See the screenshot below. As you'll find, the overall EV will be nearly identical, not matter which bet sizes are being compared.

Multiple bet sizes vs single bet sizes
Even moreso, there does not seem to be much additional value to using multiple bet sizes. To check this, first build a tree with multiple bet sizes for OOP (or IP) throughout the tree. Compare this with the same tree, only now with this player using only 75% bets (or any other bet size that you'd like to use). The player's performance will drop a bit, but only by a small amount, when using only a single bet size.

The importance of quality of play
Finally, take any tree, navigate to any decision (OOP's or IP's first decision would be easiest), click on "Lock+edit solution", and just enter any strategy that you see fit (for example, betting top pair or better, and checking everything else). Now again solve the tree, and compare the overall EV to the original unlocked tree. Most likely, there will be a large drop in EV.

Basically, the importance of quality of play outweighs the importance of bet sizing by several orders of magnitude.
Bet sizing has almost no influence on performance whatsoever.
As long as you play perfectly, and bet size will work just as well as any other size.

In summary of the above, you can use any bet size that you see fit.
They all perform nearly the same.
Quality of play is what is most important.

Note:
The above applies to non-zero-sum spots in cash games with rake 0%.
Spots that are not zero-sum are more difficult to analyse because there's an infinite number of solutions within any given dEV.

I m testing turn bet size, not flop. there is huge difference in some spots. even 2bb. so i need same input on flop. if i solve for different bet sizes on turn, solver adjust flop play.

Thats nice. Ill try it out asap =)

Thanks for your quick response Scylla. Very well appreciated!

Ok, I see. We don't have a method for doing this automatically for an entire database, but I'll see if we can fit this in for v135.

Hi scylla,
Is it applicable to add in the stats interface for each action the amount of EV we lose against GTO opponent when playing this action 100% of the time AKA EV regret? very useful stat which is hard to get by nodelocking every single action.
Thanks!

The only way of obtaining this information is by comparing two trees; one with the original decision, and one where there's only the intended action. This information can not be obtained by just looking at the original tree. After all, you can't compare a spot where an action is used by only some of the range, with a situation where it contains the entire range; in the latter spot, villain will play differently (after all, you have a different range), and the EVs will change.

That being said, the advantage of using multiple bet sizes over a single action are minimal.
When playing perfectly, using only a single bet size will perform almost exactly the same as when using multiple bet sizes.

Hey Scylla, had an issue saving a DB, think it crashed, and now when I try to open it I get an "Unexpected file format." error, any way to save this? Or do I just need to resolve?

V135 will be able to restore files up to the point where the crash occurs. We're trying to work in some recent feature requests, but hopefully it can be released soon. For the moment, with v134, you would need to resolve. So, if the database is very large, and takes a long time to calculate, then waiting for v135 may be your best option.

As for processing large databases, it may be better to export them into their individual trees, solve those trees, and only in the end merge the trees together again into a database. Go here for more detailed instructions: https://www.gtoplus.com/processingdatabase/

I wanted to experiment with using a bunch (5+) of different flop sizes just to see how it effects the strategy.

Problem is I only have RAM for about 3 flop sizes.

But I just solved a hand (with 1 flop size), and then edited the tree, and added another 4 sizes. I was then able to solve the hand with no issues.

So why could I solve with 5 sizes that way, but not when I add them during the initial Advanced Settings?

Hope that makes sense.

Most likely, there's a difference between the trees somewhere.
If you want me to take a closer look, then please send both savefiles to support.