GTO+/CardRunnersEV?
This is the support thread for CardRunnersEV, which is hand EV analysis software.
Is it possible to apply some of the features in the special options menu to multiple flops at once, or to an entire database, without having to manually lock each flop? This would be particularly useful for the incentives and rounding features.
As it is for now, if i get it right, to have a rounded solution we need to solve a tree twice. One time unlocked, and once again then with rounding applied. Is not it possible to set rounding constraint beforehand and get the same with one pass?
Is it possible to apply some of the features in the special options menu to multiple flops at once, or to an entire database, without having to manually lock each flop? This would be particularly useful for the incentives and rounding features.
Yes, we can consider adding this as an option.
As it is for now, if i get it right, to have a rounded solution we need to solve a tree twice. One time unlocked, and once again then with rounding applied. Is not it possible to set rounding constraint beforehand and get the same with one pass?
It's not possible to round while solving; when doing so, the solver will not converge.
The solver can be forced to use an inaccuracy, but this inaccuracy needs to be fixed; it can not shift between different configurations during solving.
It's not possible to round while solving; when doing so, the solver will not converge.
The solver can be forced to use an inaccuracy, but this inaccuracy needs to be fixed; it can not shift between different configurations during solving.
Can't the process be like, begin with unlocked state, and at the point there frequencies are changing enough slightly, then round and freeze them?
Can't the process be like, begin with unlocked state, and at the point there frequencies are changing enough slightly, then round and freeze them?
This would mean that in the middle of a solve, the strategy for a player would suddenly dramatically change.
And the ranges in the lines that follow the decision would suddenly be entirely different.
After that, both OOP and IP would need to re-adjust their strategies in the following lines.
And as a result, the optimal solution in the target decision would change as well.
is it possible to delete call/fold actions? if not, this is a feature request 😉
You can use the editor to remove a "Call/Check" action.
For this, press CTRL, and click where the red X would usually be.
See the screenshot below.
You can't delete a "Fold" action, but if you want to leave it out, then you can just set a very large negative incentive.
If you need an explanation for how to use incentives, then go here: www.gtoplus.com/special-menu
Incentives are described at the bottom of the page.
![](https://s3.amazonaws.com/twoplustwo-actually-definitely-helping-stud/userimages/Z1FRtMP.png)
Hi Scylla,
Filtering for small pocket pairs or 4th pair is still not not possible? Is it planned for later releases or should I give up on this idea for good?
Hi Scylla,
Filtering for small pocket pairs or 4th pair is still not not possible? Is it planned for later releases or should I give up on this idea for good?
We can see if we can offer more customization.
The problem/challenge is that in some spots, there will be too many stats to display everything properly.
How do you see chances that it is going to be implemented in later releases? High or rather low?
We have requests for all sorts of features, and all of these features take up space in the interface.
What you're asking for isn't technically difficult, but it means having to deny other feature requests.
So, in the end, choices need to be made.
Hey, I didn't have time to take a screenshot but I got a window pop up with the "The instruction at 0x0000..... reference memory... Memory could not be read. Click OK to terminate the program".
Do you know if this is an issue that could just happen with GTO+ at times or pointing that there is some issue with my hardware? Never had it happen before I think.
Thanks!
Hey, I didn't have time to take a screenshot but I got a window pop up with the "The instruction at 0x0000..... reference memory... Memory could not be read. Click OK to terminate the program".
Do you know if this is an issue that could just happen with GTO+ at times or pointing that there is some issue with my hardware? Never had it happen before I think.
Thanks!
I'm not familiar with this issue (outside of development).
Does it happen at startup, during solving, etc?
And does it happen consistently, or was this a one-time occurence?
And are you using the latest version, v164/v168, or some other version?
Other than that, you may want to check if your RAM is working properly.
Go here for instructions: https://www.howtogeek.com/260813/how-to-...
Of the two methods on this website, the second is the most reliable.
HI, Is it possible to adjust frequencies for turn spots, I can see the frequencies at the top, but not when I click on the special features
Ok, it appears that in some cases in the beta, the new "Special options" menu did not function properly.
Can you update to v169, and try again?
Go here for download: https://www.gtoplus.com/download/
Ok, it appears that in some cases in the beta, the new "Special options" menu did not function properly.
Can you update to v169, and try again?
Go here for download: https://www.gtoplus.com/download/
Yes looks good now with v169
Hi Scylla,
Is there a function to go all-in based on stack size instead of pot size? If there isn't can you consider adding this function?
Thanks
pokerboy1606
Hi Scylla,
Is there a function to go all-in based on stack size instead of pot size? If there isn't can you consider adding this function?
Thanks
pokerboy1606
If I understand you correctly, then these two values can be converted into one another.
The value in the tree builder is "Go all-in if push is less than X % of the pot".
So, for example, the starting pot is 10, and your starting stack is 90.
You want to push all-in if your stack is 60.
That would mean that the pot at this point would be 10+30+30=70.
And you want to push if your bet is less than 60/70 = 86% of the pot.
Let's call the starting pot P.
The starting stacks S.
And the desired stack size D.
Then you would need to fill in D / (P + 2 * (S - D)).
We can consider offering pushing by stack as an alternative option, although from an interface perspective, it might be difficult to communicate to users that this options is available.
If I understand you correctly, then these two values can be converted into one another.
The value in the tree builder is "Go all-in if push is less than X % of the pot".
So, for example, the starting pot is 10, and your starting stack is 90.
You want to push all-in if your stack is 60.
That would mean that the pot at this point would be 10+30+30=70.
And you want to push if your bet is less than 60/70 = 86% of the pot.
Let's call the starting pot P.
The starting stacks S.
And the desired stack size D.
The
I think like if bet is more than x% of stack go all in instead. Would it be something convertible like above because it feels likes "if bet is more than x% of stack go all in instead" is more dynamic to me.
Not sure if I am being clear.
I think like if bet is more than x% of stack go all in instead. Would it be something convertible like above because it feels likes "if bet is more than x% of stack go all in instead" is more dynamic to me. Not sure if I am being clear.
If I understand you correctly, do you mean: "If bet is more than X% of starting stack, go all-in"?
So, in the example below:
1) The starting pot is 10, starting stacks are 90
2) Set the X value at 70%
3) You would now push once stacks drop below 63, and the pot is greater than 64
Otherwise, can you provide an example?
If I understand you correctly, do you mean: "If bet is more than X% of starting stack, go all-in"?
So, in the example below:
1) The starting pot is 10, starting stacks are 90
2) Set the X value at 70%
3) You would now push once stacks drop below 63, and the pot is greater than 64
Otherwise, can you provide an example?
If I didn't understand it wrong, it is the function that pio has.
In the example you give (70%pot left to the river).
If you generate a bet sizing solution of 25 50 60 and AI, Pio, according to the treshold you put, ends up simplifying the tree at 25 AI because the algorithm considers that 50 and 60 is very close to AI, but maintains the small sizing of 25
![](https://s3.amazonaws.com/twoplustwo-actually-definitely-helping-stud/userimages/KDDYvE2.png)
This function is actually good on raising lines
If I didn't understand it wrong, it is the function that pio has.
In the example you give (70%pot left to the river).
If you generate a bet sizing solution of 25 50 60 and AI, Pio, according to the treshold you put, ends up simplifying the tree at 25 AI because the algorithm considers that 50 and 60 is very close to AI, but maintains the small sizing of 25
This function is actually good on raising lines
Ok, we'll take it into consideration, although, to be fair, the two approaches seem really similar to me.
Ok, we'll take it into consideration, although, to be fair, the two approaches seem really similar to me.
Yes, they share similarities, but let me give you an example that happens in GTO+ but not in Pio.
River Line: OOP alternatives: B30% B50% B70% B125% B175% BAI → Pot size left 2.
In Pio, when constructing the tree, due to that threshold, it skips B175% (which is beneficial because it "simplifies" the resolution of the tree knowing that there isn’t much difference between one bet and another). There is also a "G" code in GTO+, but if you use it in this case, you’ll encounter issues with the B30, B50, and B70 bets because you would need to use G25. I hope this makes sense.