The default approach always works. You can always bet 70% of the pot (combined with "get the money in smoothly" for the final bets). But using 3 bets to get the money in only applies to a certain range of stack-to-pot ratios.

The same field can apply to different scenarios. It's not always known how many bets have already gone in at a certain point. It can apply to pot=10,stack=100 as well as pot=22,stack=94, as well as pot=46,stack=82, as well as pot=98,stack=56.
The default approach with percentages (combined with "get the money in smoothly") will take care of all scenarios in a reasonably realistic way. But being forced to use 3 geometric sizes, regardless of the stack-to-pot ratio, will not work.

We do offer this for the tree editor, given that when editing a decision there, the stack-to-pot ratio is known.

The same problem exists with percentages. When I input 50% as a river bet, it will mean different sizes depending on the flop and turn action (= different stack and pot).
But I know that, and I have to take it into account when creating the tree, that's why I'm saying adding a geometric option doesn't create a new problem.

Here a concrete example of what would be ideal:
Pot = 10
Stack = 35
That means that we can get the money in by using 3 bets of 50%, or 2 bets of 91% (either flop & turn, or turn & river), or all-in.
Right now, to create that tree, I have to do this:


And then go to the tree editor to remove the unwanted branches (since I only want the 50% option on the turn to be used following a 50% flop bet, only want the 91% turn following a flop check, only want the all-in turn option following a 91% bet, etc.)

What I would want to be able to do:


So on the flop, there would not be any difference compared to if I had input 50,91.

But on the turn, GTO+ would use a different bet size for each branch of the tree.

On the branch where I check the flop, the geo2 on the turn would be replaced by 91%, and geo1 by all-in.
On the branch where I bet 50% on the flop, the geo2 on the turn would be replaced by 50%, and geo1 by all-in.
On the branch where I bet 91% on the flop, geo1 on the turn would be replaced by all-in, and geo2 would be replaced by 34% (this is the only node I would need to delete in the tree editor afterward).

Basically, GTO+ would calculate the relevant bet size while it's creating the tree, instead of having it fixed beforehand.

It would save time firstly because it would calculate the geometric sizes itself (instead of us having to do it manually), and also because it would avoid creating a bunch of useless branches we have to remove.


And now that I think of it, if we could combine it with the p,d,c options (donk, probe, cbet) we have for OOP, we could probably create the perfect tree directly without any useless branch.
By the way, could you please add similar options for the IP player (I think just a c for cbet and !c for not cbet would be enough, and not too complicated).


Hopefully my explanation was clear, thanks for considering it.

In your first example the 3 geometric bet size would be 88%, in your last example it would be 14%. The formula would still work even given extreme situations such as pot 98 and stack 56. And anyway we have the go allin if less than X% of the pot feature for exactly such scenarios as this.

This would obviously be an advanced user feature so I presume anyone using it will know what they are doing.

Hi, I see in this image that apparently you can have text files to create subsets (e.g "low connected" so i only have to write the boards one time).
1. I would like to see an example of how that text file should look
https://gyazo.com/b80a07586dded6e2b3a7c2a77ffa947d

2. I would like to know what is the easiest way to create and save ranges in GTO+ (I have 200+ charts i need to copy and doing it manually would take a lot of time). Can i do it using text files also?

Ok, I will consider it for future releases, although I'm really having trouble understanding why you would want to force the tree builder to use X bets, regardless of the stack-to-pot ratio.

You can easily create such a file by building a database with "Add X random trees" and pressing "Export flops to file". An example of the contents of such a file is the text below. The :4.000 addition is a weight for each tree; this weight is optional; without weights monotone flops are auto-weighted as 4, 2flush flops as 12, etc.

This is currently not available, but we could pretty easily create a text input feature. Is there any format for ranges/categories/subcategories/etc that you would need for this? If so, then please send a file to support. We'll write the feature and reply to you with a converted range file.

After solving a database and saving w/ basic storage, can we opt to re-save the database w/ extensive storage or would this require resolving?

Hey Scylla

I think it would be nice if there is a button that would remove all the unsolved flops in the database. Reason being is that sometimes, I split two databases and run them both at the same time. After merging these two databases back, there are a bunch of flops that weren't solved if I remove all the flop filters because I used the same subset for both of the database.

For example:

I filtered to solve A and K for 1st database
Q and J for 2nd database
After merging both these databases, I still have unsolved Q and J from the first database and unsolved A and K from the 2nd database.

Hope you get what I mean

Thank you

Ok, I think that we can pretty easily offer that.
We'll add a hint that if CTRL is pressed when clicking "Clear database", only unsolved flops are removed.

We do intend to offer the reverse in v134, namely that trees with "Extensive" storage can be stored as "Basic". It's however not possible to convert "Basic" trees to "Extensive", given that the turn data can not be reproduced retro-actively.

Anytime where you have a polarized range (nuts and bluffs playing vs bluffcatchers), geometric sizing is the best way to maximize EV.
Your nutty hands want to put the maximum amount of money in the pot (all-in by the river), and if Villain defends according to MDF correctly (which a GTO solver does), geometric sizings are the sizings that make Villain put the most amount of money in the pot on average (as you can see here for a turn pot of 1000 and stack of 1500, taken from this great Run It Once video from Quin Yang).

That's why we want the option to use geometric sizing.
Your "With only 2 bets left, get the money in smoothly" is a great first step, but it only works in specific situations where the bets are around 70% pot, and it removes the other sizings from the tree. It seems a bit too restrictive for something in an advanced tree builder.
I want to be able to give the solver the option to use geometric sizing, even if it means 2 massive overbets (because as I said, in some situations, that's the best way to maximize EV), without removing the other sizing options from the tree (which is what currently happens with the "2 bets left" option, or when editing the tree using "followed by basic play, geometric sizing".

Anyway, hopefully that helps you understand why we want this. As getmeoffcompletely said, this would be an advanced user feature so you can expect people using it to know what they are doing.

Thanks again for considering it.

Is there a way to select certain solved flops from database 1 and add them to database 2?

Is there a way to delete certain flops from a database?

I'm not completely convinced here, but I'll consider it, given that it's not difficult to add. One question though. If input like geo3 is reached for OOP, will this also mean that IP's followup bet sizes are geometric as well? Or does it just affect this single bet for OOP?

For this, use CTRL+right-click.

First we'll need to isolate the flops that you want to use.

Isolate the target flops
There's several ways to isolate flops from a database.

The first is to delete all other flops (with Ctrl+right-click).

The second is to load a flop that you want to use (double-click it), and delete the database (with "Clear database"). Only the loaded flop will remain.

The third is to export the entire database into its separate trees (see the first step here: https://www.gtoplus.com/processingdatabase/). Then just copy the individual files that you want to use.

Merge the files
Using these methods, you will now have one or multiple files with the flops that you want to use. You can now merge the files together with the option "MERGE". For this, place the files into a single directory, enter the code MERGE after "Import flops from file", and enter the directory. See the final step here for a more detailed explanation: https://www.gtoplus.com/processingdatabase/

This would just affect this single bet. As I said in my detailed example, it would just replace geo3 by the percentage it corresponds to, on this node only. If the user wants to follow up with another geometric sizing, it will input geo2 as the next bet size. That seems the most straightforward approach, the user has direct control of every node.

One of the ideas is to be able to use geometric sizes alongside other sizes, so I can have [33, 72, geo3] on the flop, and [33, 72, geo2] on the turn, and [33, 72, geo1] on the river. Every flop sizing can be followed by every turn sizing, geometric or not. Using a geometric size on the flop shouldn't force only a geometric size on the turn, or for the other player. But geo2 will mean a different percentage on every turn branch, and that's what GTO+ needs to calculate.

And I just realized I keep using geo1 as a way to mean all-in, which I guess is nice since we don't currently have a way to do that (other than inputting 999).


And since you haven't mentioned it, what are your thoughts on this:
Thanks!
And btw, feel free to reach out if you need someone to beta-test this feature

There will be a problem here if a users adds geoX everywhere in every field.
The tree will basically go on indefinitely, with ever decreasing bet sizes.
Wouldn't it be far better to have some sort of script that attaches stack-to-pot ratios to a certain geo option?

Oh, I hadn't thought possible infinite loops.
Attaching it to stack-to-pot ratio seems too restrictive to me. As I said, I'd like to be able to use it no matter if it means 70% or big overbets.

But actually, I don't think infinite trees are possible, since we can only input raise sizes up to 6bet.

If I create the tree with pot=10, stack=1000, and input the smallest betsize possible of 10:


The resulting tree defaults back to using the default sizing starting at the 7bet:


So I think no matter the geoX used, after the 7th bet, the tree will always go back to using the default sizing to finish the tree. You just have to make sure we can't use geoX as a default sizing.

Wouldn't it be much more convenient to use geo50 instead?
This would mean, to pick whichever geometric size is closest to 50%.

But that doesn't solve the problem I'm trying to solve. The whole idea is that I don't know what the sizing will be when I'm creating the tree, I want GTO+ to calculate it for me.

Example:
Pot=10, stack=100.
2 bet sizes on the flop, 50% and 100%.

If I put geo2 as a size on the turn. That would mean:
- on the branch where I bet 50% on the flop, a bet of 112% on the turn
- on the branch where I bet 100% on the flop, a bet of 82% on the turn

Using geo2 means that the turn bet size changes automatically on each branch depending on the current stack-to-pot ratio (= the flop action).


Your solution doesn't allow that. I would have to put both geo80 and geo110 as turn inputs, and that would create 2 branches after each flop bet instead of only the one with the correct sizing.

I can consider it, but is there any chance that a slightly different approach would work better? A fixed number of bets for geometric input will only work well for a specific range of the stack-to-pot ratio. Also, it would seem far more manageable if reaching geo3 input would finalize play for both OOP and IP. Particularly the latter seems very important. Without that property, getting the money in with geometric sizing becomes a task that requires filling out dozens of fields instead of a single field.

You keep saying this, but I don't understand how. If I put geo2 as an input, it will make sure that the sizing is perfect to get all-in in 2 bets, no matter what the stack-to-pot ratio is. It works for every stack-to-pot ratio, not only specific ones.

I think you are overthinking it. If I write geo2 as an input, I just want GTO+ to replace it with the percentage it corresponds to on that node of the tree. Nothing more, nothing less. If the user is using this feature, you can expect them to know what the tree will look like and make sure their inputs make sense. I think you are trying too hard to make an advanced feature easy to use.

Finalizing the play for both players geometrically is already what we can do when editing the tree and selecting the "followed by" option. But the problem with this is that if you use a geometric sizing on one node, it forces every following node to also be geometric. I want to able to start with a geometric sizing on the turn, but still have multiple sizings on the river for example.

Having to fill dozens of fields instead of one isn't the problem, it's the solution I'd love it if filling out every field in the advanced tree builder meant that when I click "Build tree" I instantly have the perfect tree. Right now, I always have to spend a lot of time editing the tree afterward, because the inputs aren't specific enough (mainly I have to remove some branches).


I've been playing around with different ideas, and I'm not claiming that this one is perfect. But it seems the simplest. I write geo2, GTO+ replaces it by the percentages it corresponds to on that node. It avoids having to write all the different sizing geo2 would correspond to depending on the action on the previous street, creating extra branches that I have to remove after.


As I said, expect the user to know what they are doing if they use advanced features.
You can also start with this feature, and see what the users think. If you start having reports from people saying that's it's confusing, then consider changing it. But starting with this as a simple starting point doesn't seem like a bad idea to me.


EDIT: I also want to point out that this feature is mainly here to save time when creating the tree. I don't know what other features you are planning for the next release, but the features I had asked for in this post would definitely be higher priority, as they add things that are simply not possible right now. Thanks <3

hi. there is that feature which allows you to copy-paste to excel some data from solved database which is vere helpful (pic below)
but it seems like it allows u to take only limited amount of data.
for example, i solved BvB SRP and i can take OOP flop strategy (bet, check) but what if want to have same data for IP player, such as bet and checkback vs missed cbet, or check-raise frequencies for OOP
same thing for BUvBB SRP situation. OOP doesn't have any donks OTF, but i still can't get that data for IP player like cbet frequencies for different boards etc
is it possible to do this? will it be implemented in the next versions?
https://ibb.co/Mk7mhk9

+1 for the geometric bet size, just put it working like in pio and will be good

Options to drill a specific node in different boards would be cool too, all other trainers that I know offeer this today but they are much more expensive

Option to choose between buttons or a bar slider in play against solution would be nice too

Just to be clear, what we're being asked for here is input like geo3. This will create a bet corresponding to getting the money in geometrically in 3 bets. And this will only affect the current bet, and not the following ones?

The problem that I personally see with this feature is that some users will spam the entire tree building menu with it, resulting in trees that will make no sense. My counter-offer is to create geo50 input. This would mean that whichever geometric size is closest to 50% will be used. The advantage is that it's not possible to make mistakes with this function, and it will always lead to realistic play.

We're happy to offer both (it's just coded input, and it's not difficult to write), but it seems to me that geo3 input may result in all sorts of issues, and will be difficult to provide support for.

It will be possible to offer this for databases that were solved with "Extensive" storage, but I think that it would be best to disable this for "Basic" storage (provided that the turn/river is reached), given that otherwise there will be annoying loading times between hands due to recalculations.

Ok, I will take it into consideration.

If the database was solved with one of the later versions (v128 or later I believe) then a navigator should be present in the menu. See the screenshot below. A requirement for this navigator will be that all trees must be identical (same ranges, bets, pot, etc). A second requirement is that the preflop ranges must be symmetrical (so AA,AhKh will not be allowed, given that there's more h than c,d,s).