Within regular use the maximum is 32 threads.
You can however go up to 128 threads with the code XXoverride.
So, for example, for 64 threads use the code 64override.

Thank you anyway!

that sounds useful if possible

Silly Q maybe but do i have to change the colours with the colour numeric? or is there a more intuitive way?

The bug the crashes solvers of Intermediate storage when looking at the Turn Report-Specific Hand is really frustrating! I have so many databases solved with the intermediate storage and I cannot use the specific hand turn report action on any of them as it crashes every time.

I thought I had asked this already? and I'll ask again to please address this soon!

Intermediate storage was phased out since v120 roughly 18 months ago.
By the request of some users, we added it back later again as an easter egg.

Savefiles from before v120 will still work.
Actually I have just checked, and files calculated with v128 and earlier will still work.

The problem is that since v129 we have added a navigator to the turn/river reports, and the Intermediate storage method does not mix with that particular approach. In retrospect we should have noticed this and removed the easter egg in that version. Given that it had already been gone for so long, we overlooked checking for it in the debugging stage. I will now remove it for v134, but unfortunately I don't think there's any way to make v134 read files that were calculated in intermediate storage that were created with v129 or later.

At the moment, you can google for "rgb colour codes" and use an online colour picker.
For example this one: https://htmlcolorcodes.com/
I will consider adding a colour picker to the internal interface though.

Hi, is there a way to avoid having to rebuild the tree after changing preflop ranges?

Do you mean that you want to use the exact same tree, only with different ranges? For this, go to "Build tree", select the "Rebuild" tab and click on "Rebuild with current settings".

Thank you!

Ok that makes sense but is frustrating nonetheless since intermediate is so valuable. Thanks regardless for your amazing software!

I am not able to create the tree with proper river sizings for some reason, and I was wondering what that might be.
Maybe I am doing something wrong.



As you can see in the black circle (bottom right, bet size on the river), I want In position to push on the river; yet the software keeps putting in this odd 26.98 BB size as the river bet (top left). It seems to do so in that node no matter what percentage I input in the bottom right. Even when I put in 10%, so a really small river bet, it still ends up betting 26.98.



I have noticed an oddity; this happens in the tree after two turn sizings, after the 30% and after the 65% turn bet.
And it ends up with the same river bet size in both of those nodes, to make it even more weird.

However, when I navigate the tree and select the turn 120% node, then the river pushes all in (again, regardless of the river betsize percentage selected).



I can manually change that in the tree, by editing the river actions; I am, however, wondering why this problem happens, and how I might avoid it and have the tree set up correctly.

I initially noticed the issue when I had set up the Tree Builder to create two river sizings, 50% and 999% (ie all in), and then saw only one being created.

What might I be missing? (Other than not correcting starting stacks to reflect the preflop action, which does not matter here )
The "use custom settings for river" toggle is on at all times.

Extensive storage is the same as intermediate storage. Except for the fact that its savefiles are larger, and it also contains turn info. So if the larger savefiles are not an issue for you, then please consider using Extensive storage instead.

Can you try turning OFF "With only 2 bets left, get the money in smoothly"?

That did it!

I have one more question; about saving solutions of a database.

Is it possible to create a database of 50 flops, solve a particular tree for all 50 (Run Solver - Process database), and then once the software completes the operations save all 50 solutions somehow?

I did not run into the description of such a process in the videos, and yet my intuition tells me it's there somewhere.

You can create a savefile with "File->Save as ...".

Or do you mean that you want the software to automatically save the file after finishing?
It's possible to place all files that you want to solve into a single directory.
After that, go to the "Folder" icon and process all files in that directory.
A savefile will automatically be created after every solved tree.

Hello,

I recently solved a massive 163 flop subset for a 3bet pot situation using extensive storage. When I look at the database statistics, it appears the averages at the bottom of the table are gone. Also the action selector at the top, where you can select check, bet etc and see the next action is also gone. I tried closing and reopening the file but nothing has changed. Am I doing something wrong?

I posted a picture here:
https://imgur.com/gallery/qcTWafZ

There's a few requirements for being able to display the averages:
- The file must have been solved with one of the more recent versions of GTO+ (v129 or higher I believe)
- All trees must have the exact same bets/stacks/pot/rake/etc. Trees that are different can not be summed together.
- The preflop ranges must be suit symmetrical. So a range like AA,AhKh will not be symmetrical, because there's more hearts than spade/diamond/club. The preflop ranges can only be of the type AA,AKs. The problem is that otherwise it's not possible to translate a flop like AhKhQh to its spade/diamond/club counterparts.

ah thanks a lot- this made me realize one of the flops was solved separately and then added into the database.

When we edit/create ranges in the starting range editor screen (in an untitled document) is there a way to save these ranges or do we have to save the untitled file?

To store your range, click on "Add range".
Your range will be added to the predef menu.

The predef ranges are stored in /config/newdefs3.txt. So if you ever want to backup your ranges, or copy them to another computer, then just make a copy of this file.

I would like a way to use geometric sizing in the advanced tree builder. For example I could write "geo3" in the bet box and it would get the money in from that node onward with 3 geometric bets. I know there's the "get the money in smoothly" option but it's too restrictive for my needs, especially in short SPR situations.

The challenge there is that different stack-to-pot ratios may apply to a single field. Although a "geo3" input might apply to some of the ratios, it would be inadequate for others. So such a feature would not be entirely straightforward.

But that problem already exists with inputs as percentages, so it's not like it's creating a new problem.

Personally I use these formulas to calculate the geometric sizings:
geo3 = ((2*effectiveStack/pot+1)^(1/3)-1)/2
geo2 = ((2*effectiveStack/pot+1)^(1/2)-1)/2

And then I put the result of those as a percentage in GTO+. It would be great if I could just write geo3 or geo2 in GTO+, and it would do the calculation for me. It's really just a quality of life improvement.


EDIT: if someone is interested in a general formula: geoX = ((2*effectiveStack/pot+1)^(1/X)-1)/2
(X being the number of streets to bet, so 3 for the flop and 2 for the turn)
This gives you a decimal number, multiply it by 100 if you want a percentage.

Yes that's exactly what I am requesting. I can already do this by manually calculating what the bet size % is for however many geometric bets I want, then I have to manually edit the tree. This would just make advanced tree building much faster.

I don't understand why that would be a problem. The effective stack size is already a variable in the geometric bet formula. Say I want to use geo3 on the turn. If say we get to the turn in the check raise node then the 3 geometric bet size would be a smaller % of the pot than if we got to the turn in the check check node, but the formula would still work fine across all different SPRs.