I thought 0.25 and 0.25% are the same. ^-^

But I it works now thx for your help.

Hey scylla so i'm running a sim where i node lock assumptions for BU on both flop + turn, and MP's strat is to raise @ 100% frequency/using max exploit tool???

Can someone help or explain to me plz?



Issue i'm having is the numbers/EV doesn't make sense to me for flop play. Running max exploit both for flop + turn, and MP has -EV decisions OTF even with max exploit?



However, when i initially run the max exploit tool for just the flop, the EV's for MP seem to be +EV for a 100% raise frequency.

OTT we do have +EV bets for all hand combos, this photo is just avg EV's but i checked betting EV's and they were all +EV/profitable and i did node lock assumptions/deviations for BU turn play.

Hey Scylla, I made a sim on gto+ and on turn player 2's range played a mixed strat with an ev of 20.59. Then I locked this player's strat to check 100% and the ev increased to 20.67. Does this increase have to do with the error of the software (I used dEV of 0.5%).

If I understand you correctly:

1) You have run the max exploit tool for the flop, with the turn having been set as unknown
2) After that, with this same solution, you have now set a turn and run the max exploit tool again. Some of the EVs for the flop are now -EV

Just to clarify, once you have set a turn, the max exploit tool will not influence the flop play anymore. This play will be kept fixed, given that it would not be realistic to alter flop play in the full knowledge of which turn card is to come. It would of course be great to know which turn card is about to roll off, but that's just not the reality of poker. So, once a turn has been set, the max exploit tool will only influence turn+river play.

Now, the fact that certain flop cards are now -EV is not really that strange. For example, if I bet a flushdraw on the flop, then this play will most likely have been -EV in case a non-flush card rolls off on the turn. On the other hand, in the scenarios where the flush card does roll off, the flop play would have retroactively been massively +EV. The flop play as calculated by the max exploit tool when the turn is unknown is the average of all possible turn scenarios. Some are -EV, some are +EV, but as a whole, for all possible runouts of the board, the flop play was +EV. This particular scenario where a 2d rolls off was just one of the -EV ones for some of the starting hands, where other turns would have been +EV for them.

That being said, I notice that the play also continues to the river. I'm not sure if you have gone through the trouble of defining play for villain on the river as well, but it's probably a good idea to use the GTO solver here instead of the max exploit tool. In that way, any play for villain that is undefined (and it's pretty hard to define river play for ~2500 river scenarios) will be filled in for you by the solver, which should save you quite a lot of work.

I can think of a few explanations of the top of my head, but could you send a savefile to support please?
I'd just like to make sure that I understand the situation correctly.

email sent

Ok, see the screenshot below for the original situation. Due to the absence of tree based navigation in GTO+, which still needs to be added, for the moment I'm using CREV instead so that we can see an overview of what is going on.

SB checks 100% of the time for an EV of 14.31.
BB has an EV of 20.69.



In the second situation we see the edited version where BB always checks.
The EV for that decision has indeed increased to 21.38.
However, this is because SB is now no longer checking 100% of his hands.
He now only checks 77.2% of the time and bets 22.8% of the time.
In the line where SB bets BB's EV is actually 5.76, which is very low.
That makes BB's overall EV 22.8%*5.76 + 77.2%*21.38 = 17.81.
This is considerably lower than his original EV of 20.69.

The difference goes to SB, who's EV has increased from 14.31 to 17.18.



So, what has happened? Basically, BB's play in the Check line is weak. As a result, SB does not need to send his strongest cards to the Check line anymore, but can instead assign them to the Bet line, where they wreak havock on BB's position. So, overall, checking loses BB money because this passive play frees up SB's strongest hands for other opportunities.

I there are folder where all my custom ranges are saved?
I would like to make a backup of all my CREV ranges.

got it thanks

Your ranges are stored in the newdefs2.txt file.
Backing up that file is all you will need to do.

In regards to 1) and 2) yes you are correct.

So in regards to the bolded part i highlighted, maybe i'm not understanding something with the EV's but in this spot i had BU calling around 63% of the time after betting 50.9% of the time for both flop + turn why is BU still raising 100% frequency?

Also i understand how certain run outs will influence certain hand combos earlier in the hand, i'm just still confused tho in regards to the statement above i made about villain calling too much and we still raise 100%?

---

No have not node locked villain's deviations for the river... Um if i node lock on flop or OTT do i have to node lock villain's deviations for every single decision tree? <--- I've always wondered that.

In regards to the bolded part i highlighted in last paragraph... What do you mean by this use the Nash solver instead of max exploit can be more specific on the steps or show me what you mean?

???

I always get this message popping up. Tell me what you mean please when you keep saying use the nash solver.

You have entered the board up until the river, however, in this tree there's multiple subtrees that start on the river. As a result, the solver does not know which subtree you would like to solve. To tell it this, set a checkpoint at the entry decision (press F10 and click on the decision). See the screenshot below:



In GTO+ none of this is necessary anymore though. You can just go to this part of the tree and, given that this will be the only subtree that you're looking at, it will know which part of the tree you want to re-solve. Development will still take a few months, but most GTO functionality from CREV will be carried over into GTO+, which should be very easy to use given that its interface is dedicated to this particular research.

I assume that you have calculated this flop play with the max exploit tool with the turn set as unknown? MP+2 can still profitably play 100% of his hands here, most likely due to the sub-optimal play by BU on the turn, and especially river. If you want me to take a closer look, then please send a savefile to support, but I'm fairly certain that this is why.

It can be very difficult to define play for BU on all 49 possible turn runouts and after that all possible ~2500 turn+river runouts. What you may actually prefer to do here is to leave all the play on the turn and river unlocked, set the turn as unknown and then run the solver instead of the max exploit tool. The solver will figure out how both MP+2 and Button should play on the unlocked actions of the unknown boards, so this is something you won't have to worry about; you can just focus on defining play on the flop. Should you prefer to define play on the turn though, then that is perfectly fine. Just enter play wherever you see fit in the tree, lock it and then run the solver. The solver will fill in GTO play in any action that is unlocked. So basically, when using the solver, research becomes very straightforward. Minimal input is required and the solver does most of the work. For demonstration videos on the solver, please watch the videos here: http://www.cardrunnersev.com/download.html

It's also possible to use the tree building wizard to build trees with all possible bet/check/raise/etc combinations for you. For a demonstration of the wizard, please see the first video here: http://www.cardrunnersev.com/download.html. When using the wizard, analysis becomes even more straightforward. Just build a tree, fill in any play that you see fit, lock that play and let the solver figure out the rest. The max exploit tool is not needed here.

Other than that, should you not yet be aware of it, we have recently released the first beta of our new dedicated solver GTO+. Not everything is finished yet, but you will be able to do all of this kind of research on GTO+ as well. Its interface is especially designed for GTO research, making it very easy to use. For download, a release video and more details, please go here: http://www.cardrunnersev.com/gtoplus.html

Hey Cylla,
First of all, I really enjoy your SWs and I am having a lot of fun with GTO+ Thanks.
I have one question and forgive me if you already answered it. Will be possible in the final version of GTO+ to simultaneously analyze multiple bet sizing? For exemple running a sim with both 1/2 and 2/3 pot cbets.
Once again thank you for the awesome tools you developed.

We are currently focused on development as listed on the website and no decisions have been made yet as to the exact functionality of the tree builder; this will be done at a later point. One slight reservation that I have here is that I wonder is people actually realize how big trees with multiple bet sizes are.

Trees that have two bet sizes already require 5 to 10GB of memory and trees with 3 bet sizes throughout the flop+turn+river probably require something along the lines of 50GB (admittedly though I haven't checked this particular case). This is not a limitation on our end, it's just the size that is required to store those trees in any software. Solving times will most likely be of a similar magnitude.

If you look at it from a different perspective, if player 1 has two bet sizes, then, in the first decision the tree will split in 3 scenarios. If after that player 2 has two bet sizes as well, the tree will split into 9 different scenarios. And 27 after that. And any point where a new turn rolls off the tree splits into 49 different scenarios again. And for every river there’s 2352 runouts of the board. You will very quickly get to a spot where I don't think there's much point to performing any level of analysis anymore. You will never even look at more than 0.0001% of these scenarios anyhow.

Our solver is capable of handling multiple bet sizes, and so is our new interface, however, I really have some reservations here. The human brain does not work like a computer and requires data to be organized and simplified. At the very least, speaking for myself, that's how it works for me.

To me it seems a lot more productive to focus on single decisions and, for example, give those 5 different bet sizes to see what the approximate ideal bet size is in a certain spot. There’s probably a lot to be learned as to the ideal bet size on certain boards, or the development of the ideal bet size throughout the flop, turn and river. More importantly, such information would be relatively easy to remember and be applied in real-life situations.

So, to summarize, we haven’t made any decisions here yet, although we likely will offer this, simply because apparently some people really want this, but, if only speaking for myself, I think that I would personally learn much more from focussed research (see the above paragraph from an example).

One of the reasons it's common to use 2 or 3 bet sizes on turns and rivers are that you use different bet sizes on different runouts and in different lines, and adding multiple bet sizes has been the easiest way to get an appropriate bet size in all spots with current software. The elite HU and 6max cash players seems use around 1-2 bet sizes on the flop and turn and 2-3 bet sizes on the river. I tend to agree with the approach you mention for players that is not elite of picking one bet size that works well for most hands in your range and only add in a second in some river spots that it's unlikely you'll get raised often enough to keep all the nutted hands in the same line.

A feature I've seen requested in the past and I've not seen implemented yet is a script for the solver to try to find the optimal bet size for a spot.

Another reason multiple bet sizes are useful is in spots where villains use unorthodox bet sizing. For example, if I want to review a hand where villain went all-in on the flop (a massive overbet) it is not particularly useful to solve the entire hand using just that one bet size across the entire tree. Instead, I set up the tree to use standard bet sizes across all streets and then add the all-in to villains options on the flop. Obviously the solver will generally use the smaller bet size for the majority of villains hands but it still allows you to see how you should play against the all-in, in the case that it does happen.

It's extremely important to have multiple river bet sizes. For flop and turn it doesn't matter that much, but on the river you absolutely need multiple betsizes or you lose a lot of ev.

I think an option for 1 flop, 2 turn, 3 river in regards to betsize would be close to perfect and because the flop is kept at 1 betsize the tree size should remain manageable. Or even 1 flop, 1 turn, 3 river would still be a huge improvement over only 1 size throughout.

Scylla, am I doing something wrong or tree building wizard does not work properly with bet sizing?



Look at sizing in tree wizard and actually in the built tree

If I understand you correctly, then the reason to use multiple bet sizes on the turn/river would be because the software was asked to make bets in terms of the pot (for example, if possible, always bet 50% and 70% of the pot) without having any consideration for the stack-to-pot ratio. So basically in this approach bet sizes are randomly+blindly thrown around in the hopes that one of the lines makes sense.

An approach that I belief is preferable is to let the software figure out for itself which bet size makes sense for the situation. We are already doing this for the tree builder where, if you enter effective stacks and a pot, it will figure out for each number of bets which % of pot is necessary to smoothly get the money in and select the one closest to 60% of the pot. In this menu the user can just select which number of bets he would like, after which the software shows how big these bets will end up being if the money goes in smoothly:



By approaching it like this, you are no longer making 2 or 3 random bet sizes, but instead a single targeted bet size that actually applies to the situation. A multi-bet variation here would be to provide a range of %, for example 40% until 100% and let the software use multiple bet sizes. So, for example, in the same situation, if you were to use 3 bets instead of two, then this will result in bets slightly over 40% of the pot. So the tree builder would create 2 different lines, one for getting the money in bets of ~70% and one for getting the money in in bets of ~40%. To me, this would be a much more realistic approach to simulating river play, given that even the worst of players will take stack-to-pot ratio into account once they are close to being all-in. Using multiple bet sizes that don't apply to the situation in the hopes that one of them makes sense simply does not achieve this, as well as requiring considerably more resources.




GTO+ is still in beta.
You should be able to do this in the alpha.

No, that looks correct to me.

The first bet is 2.75 into a pot of 5.5, which is indeed 50%.

The second bet is (11.11-2.75)=8.36 into a pot of 5.5+2*2.75=11, which is indeed 8.36/11=76% of the pot.

And the third bet is (31-11.11)=19.89 into a pot of 11+2*8.36=27.72, which is indeed 19.89/27.72=72%.

The bet sizes as shown in the wizard of 2.75,11.11,31,100 are intended for the bet-raise-raise-raise. If there's a call anywhere, where play continues to the next phase, then the bets will continue as the given % of the pot.

We haven't created the tree editor+navigator yet, however, adding an all-in line at any point of the tree, or if you prefer, an additional bet line somewhere will definitely be part of its array of features.

We are not too far away from beginning work on the tree navigator/builder/editor, so at this point we're just gathering information on what people's thoughts on that are. From what I can tell so far, I really prefer to let the software itself finish up play beyond that point that the user is focussing on, which will mean that it will itself select bet sizes for all relevant spots where the user has not defined it. An option that will allow for a range of bet sizes (for example, use any solution for X bets that results in a bet % of 40%-100% of the pot) would be part of this.

I realize that people are currently used to defining bets solely as a % of the pot, but I really believe that once you have gone past the part of the tree that you would like to focus on for whichever research you're doing, it's important to let the software create play so that the bet sizes make practical sense to the situation. Please let me know if I'm overlooking something, but the alternative of making two or three fixed bet sizes in the hopes of hitting a line that makes sense seems to me an approach that has potential for improvement.

ok, I understood (thought it was bet flop/bet turn/ bet river)
I can't lock hand strength by right click mouse in raise, call, fold tabs

Also sometimes I see selected hands in raise section with such combos 0/1/0 raise/call/fold but displayed in hand matrix.
Does it mean that quantity of combos less than 0.001 and cant be displayed therefore I see this hand in card matrix but it has weight 0?