Hey scylla, I'm asking about what will happen in this situation on CREV.

1. I solve a flop tree (e.g. 553)
2. I fill in the turn and river and then calculate to see the solution ( 553 9 Ac rainbow)
3. I edit the solution on the river for the Ac.
4. What will the solver calculate if I solve the tree from the turn? Will it lock the ranges for the Ac and nothing else?

thanks for the new solutions/products, I dreamed about them for quite a while

Are you asking about CREV or GTO+? CREV doesn't really allow to edit separate turn/river cards, so it sounds like possibly you're referring to GTO+? If not, then, particularly when working with the solver, please consider switching to GTO+. It's to a large extent CREV2, has an interface dedicated to GTO and offers many additional new features in that area.

OK, assuming this is the case, how do I accurately measure the EV difference of having fewer turn sizings, since (if I am understanding you correctly) the EV displayed at this decision point doesn't tell the full story of the overall effect of removing the turn size.

Hi Scylla,

Impressive updates to GTO+ and Flopzilla. You added the type of stuff I felt was needed to make GTO+ and Flopzilla as useful as possible. I have a couple of suggestions or questions for some small things.

I had some crashes when loading a saved tree where I edited turn/river bets without resolving from flop.

The RAM check feature seems to take into account the RAM the tree running is using and have stopped a couple of sims in progress when I have like 12gb RAM available. As a workaround I can maybe just set it to like 2x the RAM I have? That would effectively just disable it.
Edit: Actually what happened was that after running the sim had ran for 15min GTO+ started to use 2x the amount of RAM. Does it dynamically change compression?

Is there an easy way to add custom filter for A-high, K-high etc in flopzilla? K-high is really nice to have for HUNL in GTO+ too but I don't know how useful it is for tighter formats. Maybe if you could filter for highest rank/kicker or something in filter could be a way to implement it:


I find these kinds of graphs you had in CREV really nice and I find them very useful for understanding ranges better and could be useful to have in flopzilla too:

Ok, I will look into it.
It's not unthinkable that we overlooked something here.


Yes, artificially setting a higher amount of RAM will be a sufficient workaround. Please do note though that issues may arise on your system if 100% of your RAM is in use.


When ranges are narrow it's possible for the solver not to converge. In this case the solver will require double the originally stated memory. In any regular use this should not be an issue, given that tight ranges typically mean that the trees don't use too much memory. It is however possible to build huge enough trees so that still more than half of your memory is needed for the solve. In this case the solver will be stopped. Should this be an issue for you, then please consider just using single bet sizes on the turn/river. The quality of your solution will not significantly be affected, while making your tree smaller, solve faster, and with the solution being easier to interpret.


Ok, I will consider it for later releases.

You need to look at OOP's EV below the table in the very first decision of tree.

Flopzillapro has a beautiful interface, well done.
Request, flopzilla has the cumulative/absolute option to see the hands that are equal to or better than top pair. Could you add this option in flopzillapro?

This would tell us the EV loss of removing a turn bet size, but across all turns, right? How do I check the EV loss on a specific turn?

This did not help, the problem persisted. At the same time, when roll back to 1.18 version, everything fine. But it’s worth installing 1.21 the matrix turns into hell of shades -

Since FlopzillaPro is now out, will original Flopzilla/HoldEQ continue to receive updates and support moving forward? Just curious.

This will be added in a later release. We decided to first release the beta, and to take care of some of the final details later. The alternative would have been to push back the release by about a month.

They will definitely receive support.
As for updates, we may add those if there's a need.

I don't see why there would be any difference. Can you perhaps send an e-mail to support with the /config subdirectory for both versions? I'll check over here what the difference could be.

It won't be necessary to add the /config/backups directory though.
It's probably better to delete that, so that the files remain smaller.

I think actually, given that v120 now maintains the flop solution when just editing the turn, that you can just look at the very first turn decision for OOP.

Wow this last update is sick.

Thanks.

Thanks for the great update.

I use your subsets.
In the 55 pcs subset T85rbow is in twice.

Is there particular reason for that?
Are these subsets weighed, like the ones in Piosolver?

Furthermore I would like to see more aggregated stats for IP as well, and if subsets are not weighed I would like to see that too ( so one can solve couple tree to see what postflop betting frequencies / stats should be.)

Thank you.

OK great! Thanks. One more question: If I run 50 flops in database mode, click on a completed flop, can I edit the turn tree? without re running?

Yes, I think that should work.
Please do re-solve the turn after editing though, so that it's solution is updated.

Actually one is 2flush, while the other is rainbow.


Yes, they are weighted.
And we outperform pio by about 20%.
Go here for more information: https://www.gtoplus.com/subsets/


If OOP has multiple actions, then there will also be multiple spots where IP gets to act. So for example, if OOP either bets or checks then IP's actions would need to be displayed separately for each scenario by OOP. And each data point will have been measured for a different range and frequency for OOP. This means that this data for IP is essentially not suitable for being displayed in a table/graph. We can decide to ignore this, and plot it anyhow for later releases, but right at this moment it has been left out for this reason.

After working with FZPro and GTO+ more and more, I need to take it to the next level now: I keep seeing people - using both PIO and GTO+ - talking about what the solver suggests as the best bet sizing in different situations. How can I get the solver to suggest bet sizings? As is now, I just see how to add in the two ranges pot % bet size on each street prior to running the solver.

Editing turn/river tree while keeping the flop solution the same can only be done with the tree editor? Is it possible to use the "build tree" advanced tab?

I suppose we can consider this for later releases, but right at this moment edits need to be made with the editor.

There's not really such thing as an optimal bet size. When playing GTO, any bet size will perform almost exactly the same as any other bet size. There's a very persistent belief that, when multiple bet sizes are used, the bet size with the highest frequency will be the optimal bet size. This is however incorrect. You can test this for yourself by building the same tree, but with different bet sizes. After that, solve the tree and look at the overall performance. This is OOP's EV below the table for the very first decision in the tree (see pic below). As you will find, all bet sizes lead to approximately the same overall EV.