GTO+/CardRunnersEV?
This is the support thread for CardRunnersEV, which is hand EV analysis software.
Don't look at the post above. It's stupid of me, considering that quick switching works from the main matrix and you can see the combo in question.
I can't delete the previous post.
Sorry.
How to rescale GTO+ for widescreen resolutions?
If you enlarge the window horizontally, the interface will automatically rescale to accommodate the new dimensions. However, if you’re referring to ultra-wide monitors, there is a practical limit—beyond a certain width, it becomes challenging to arrange the interface items in a usable way. In such cases, it's probably best to not use the full width of the monitor.
Too take advantage of the net .gto2 extensions, can we convert the old databases?
I have all my databases exported into individual flops. How can i do that without going one by one?
I loaded a bunch of them with CTRL+W, then "Save As", a big file was created but when i try to open it, it crashed GTO+.
EDIT:
Ok, i figure it out. Load all 166 individual files, "Export flops to file" and it worked.
Loading old .gto 166 individual files took me 42 seconds. The same files but with the new extension took 1 minute and 59 seconds.
The files are much smaller (150-200mb vs 25-50mb) but the loading speed was what i was looking for after reading the changelog.
Too take advantage of the net .gto2 extensions, can we convert the old databases?I have all my databases exported into individual flops. How can i do that without going one by one?I loaded a bunch of them with CTRL+W, then "Save As", a big file was created but when i try to open it, it crashed GTO+.EDIT:Ok, i figure it out. Load all 166 individual files, "Export flops to file"
The multi-threading optimization currently applies only to database loading/saving.
In some cases—such as loading files that contain only a single tree—the process may actually take longer due to the overhead of decompression.
For example, loading now takes approximately 0.7 seconds per file compared to the previous 0.25 seconds.
While this difference is negligible for a small number of files, it becomes significant when loading large batches, such as 166 files.
I’ll make a note of this and we'll apply multi-threading to CTRL+W, "Merge files" and "Export database" as well.
Hi scylla,
i'm working a lot with the "display data as graph" feature and wondered if you could add blocker and unblocker score stat that measured between 0 to 1 based on how much EV is removed from the Villain's hands with greater equity for the blocker score and how much EV is not removed from the Villain's hands with lower equity for the unblocker score and have the ability to scatter them like the other stats
The infrastructure is already exist and only need to present the data based on existing stats like EV and equity, not much of a work and super useful feature so I hope you will seriously consider it.
Thanks!
The multi-threading optimization currently applies only to database loading/saving.In some cases—such as loading files that contain only a single tree—the process may actually take longer due to the overhead of decompression. For example, loading now takes approximately 0.7 seconds per file compared to the previous 0.25 seconds. While this difference is negligible f
Ok. Thank you.
How can i revert back to a single database from 163 individual files? I just tried CTRL+W -> Save As, the file was created successfully but then the file doesn't load. It crashes GTO+ every time.
Not possible or a temporary bug? Any other way?
Thank you
Ok. Thank you.
How can i revert back to a single database from 163 individual files? I just tried CTRL+W -> Save As, the file was created successfully but then the file doesn't load. It crashes GTO+ every time.
Not possible or a temporary bug? Any other way?
Thank you
We've identified a bug affecting the handling of large files (specifically those over 2GB, or 2³¹ bytes) in v178.
Although initial tests with large files passed successfully, subsequent changes introduced a crash in this scenario.
As a result, we've decided to postpone the release of v178 to Monday — or potentially a bit later — to allow for further testing and stability improvements.
On Monday, we'll also be adding multi-threading to the functions we discussed earlier, along with a few others.
The key takeaway (which we seem to need to keep relearning) is that releasing significant updates on a Friday before the weekend is not ideal.
I apologize for the inconvenience and for taking up your time with a release that wasn’t quite ready.
No worries at all, these things happen!
Keep up the great work.
Hi. Sorry for this post, maybe it should have been made back in 2015, but the truth is I'm not finding a solution. My question is pretty simple, just to have a starting point. I want to understand how EV works in CardRunners EV by streets. In this tree, which EV should matter to me as the BTN — the one on the Flop or the one Preflop? What stands out to me is that CO's Folds have EV0, and I imagine that the part that is negative might be affecting the EV Preflop. Is that the case?
That is, if I want to compare EV lines in BTN, do I have to relate the preflop EV, which is a global EV of the tree, and not when the tree ends?
Sorry for the basic and outdated post. I understand if you don't reply. Thanks.
Hi. Sorry for this post, maybe it should have been made back in 2015, but the truth is I'm not finding a solution. My question is pretty simple, just to have a starting point. I want to understand how EV works in CardRunners EV by streets. In this tree, which EV should matter to me as the BTN — the one on the Flop or the one Preflop? What stands out to me is that CO's Folds hav
A flop has been entered, so you need to look at the EVs on the flop.
The EVs preflop have been calculated in the knowledge of what the flop will be.
Scy, Dev Pio about his blocker feature:"I tried to make a video about blockers and I got stuck a little when I tried to explain the differences in EV of few actions based on blockers and realized that current model is useful in only half cases.The blockers seem to be mostly relevant for bluffing or calling with bluff catchers.For bluff catchers we want to know the ratio of valu
Just ran into this post.
I've posted a suggestion about blockers feature and just wanted to say +1 for this, this is really useful feature even when mathematically the effect is marginal it has a huge importance when composing ranges and trying to understand the logic behind solver's output.
Hope it will be implemented.
Just ran into this post.
I've posted a suggestion about blockers feature and just wanted to say +1 for this, this is really useful feature even when mathematically the effect is marginal it has a huge importance when composing ranges and trying to understand the logic behind solver's output.
Hope it will be implemented.
We can consider adding this feature, although it's important to note that blockers have minimal impact in most practical scenarios—particularly when dealing with wide or standard ranges. They only become somewhat relevant in extremely narrow ranges, which typically occur in rare lines like bet-raise-reraise sequences. In other words, blockers are largely irrelevant in the majority of spots and only gain significance in lines that almost never occur. While we can explore adding support for this, I personally feel that it may be better to leave this feature out.
We can consider adding this feature, although it's important to note that blockers have minimal impact in most practical scenarios—particularly when dealing with wide or standard ranges. They only become somewhat relevant in extremely narrow ranges, which typically occur in rare lines like bet-raise-reraise sequences. In other words, blockers are largely irrelevant in the major
I think the same as you today. I mostly prefer updates to the trainer, and some improvements to the added reports / building tree.
The clearest example is when you start browsing a subset from the flop reports and it has several cbet sizings, there may be boards where the sizing chosen to navigate never chooses it and yet it shows them to you... if you multiply that by 47 turns and 163 flops... imagine the noise it makes when you want to study it.
Another is to be able to see in a general way in the reports how a group of hands plays in a certain runout. Today the only option is to just choose a combo.
One thing I forgot to mention, could the "combo locking" be added?
If I understand correctly, this function would allow groups of hands to be unlocked but the rest of the range would adapt to this new strategy by changing the overall non-unlocked strategy.
This work like that?
I think the same as you today. I mostly prefer updates to the trainer, and some improvements to the added reports / building tree.The clearest example is when you start browsing a subset from the flop reports and it has several cbet sizings, there may be boards where the sizing chosen to navigate never chooses it and yet it shows them to you... if you multiply that by 47 turns
Why not both?😀
I understand what scylla says, but this feature is easy to implement as he said and this feature has decent additional value in spots where ranges are not too wide such as various river spots or 3bp+.
And again, even if the effect of blockers on EV or action frequencies is marginal many times I found myself trying to understand the solver's output for different lines with different combos and found out that the solver is mostly basing his range construction on card removal so this feature can help conclude way faster about the logic of the solver in different spots, right now I need to hover on most of the grid to find validation to my assumptions which is really time consuming and can sometime be wrong while with the feature presented in the Pio video when the grid present the percentage of blocking and unblocking of different ranges based on equity thresholds it makes things clear and easier to understand the logic behind the solver's actions in many spots which I think that even if the effect on EV is sometimes marginal it is priceless in terms of functionality and efficiency.
Anyway scylla, whether you'll decide to add it or not I appreciate your work and your listening.
Why not both?😀I understand what scylla says, but this feature is easy to implement as he said and this feature has decent additional value in spots where ranges are not too wide such as various river spots or 3bp+.And again, even if the effect of blockers on EV or action frequencies is marginal many times I found myself trying to understand the solver's output for different li
It would be good to have it, I'm not saying no. But time is finite, and if they have X amount of time allocated for coding, nowadays I'd prefer them to use it in a different direction. Having both would be ideal (that's why I proposed it back then), but if we have to prioritize, I lean towards the trainer and agg reports.
BTW Any ETA for V 1.78?? I've been hitting the refresh button all day, waiting for the relaunch (I didn't get to see what it came with, haha).
I think the same as you today. I mostly prefer updates to the trainer, and some improvements to the added reports / building tree.The clearest example is when you start browsing a subset from the flop reports and it has several cbet sizings, there may be boards where the sizing chosen to navigate never chooses it and yet it shows them to you... if you multiply that by 47 turns
Are you referring to sorting by 'Turn'?
This issue shouldn't occur when sorting by Equity, EV, or Bet.
Another is to be able to see in a general way in the reports how a group of hands plays in a certain runout. Today the only option is to just choose a combo.
We can consider it, but this would require considerable programming time and would also make the interface significantly more complex.
We need to weigh this against the value it adds—as well as the potential value it detracts.
At a certain point, adding too many features can overwhelm users and lead to abandonment.
One thing I forgot to mention, could the "combo locking" be added?
If I understand correctly, this function would allow groups of hands to be unlocked but the rest of the range would adapt to this new strategy by changing the overall non-unlocked strategy.
This work like that?
It's technically possible, but in practice it's nearly unusable.
We've invested a significant amount of time trying to implement this and couldn't create a workable version.
The main issue is that two separate actions are required: one to specify which hands to lock, and another to assign the desired weights.
With a list of hundreds of hands, it's extremely difficult to keep track of what's been selected.
As with other features, we need to weigh the value it adds against the potential downside—namely, users giving up due to excessive interface complexity.
Why not both?😀I understand what scylla says, but this feature is easy to implement as he said and this feature has decent additional value in spots where ranges are not too wide such as various river spots or 3bp+.And again, even if the effect of blockers on EV or action frequencies is marginal many times I found myself trying to understand the solver's output for different li
As mentioned above, we need to be selective about which features we add. While it's tempting to keep expanding functionality, every new button increases interface complexity—potentially discouraging new users. Ultimately, we have to balance the practical value a feature provides against the complexity it introduces.
BTW Any ETA for V 1.78?? I've been hitting the refresh button all day, waiting for the relaunch (I didn't get to see what it came with, haha).
We experienced some setbacks—most notably, the main testing computer had a damaged cooling fin on its power supply unit.
While reviewing other features, we also identified areas that could benefit from multi-threading or background processing.
We've dedicated some development time to optimizing those as well.
All things considered, it will likely be next week.
Are you referring to sorting by 'Turn'? This issue shouldn't occur when sorting by Equity, EV, or Bet.We can consider it, but this would require considerable programming time and would also make the interface significantly more complex. We need to weigh this against the value it adds—as well as the potential value it detracts. At a certain point, adding too many features can ov
Look into it please.
Look into it please.
I can't seem to reproduce this.
Is it possible that, although it says that the line is used 0%, it's actually something like 0.0001%?
I can't seem to reproduce this.
Is it possible that, although it says that the line is used 0%, it's actually something like 0.0001%?
If a line occurs 0% or around, it shouldn't display that node on the turn. Am I making myself clear? Because it doesn't exist....Showing it creates inconsistencies in the statistics. It would be ideal to figure out how to parameterize so that if a line occurs less than X%, it doesn't display. I understand that in bet/raise situations, if the raise occurs 5%, it's important. But in a C-bet node where 50% is chosen, 4% sizing another, and check is 'noise.'
Something similar happened in the trainer, which you were able to solve by playing 'Loose mode.'
If a line occurs 0% or around, it shouldn't display that node on the turn. Am I making myself clear? Because it doesn't exist....Showing it creates inconsistencies in the statistics. It would be ideal to figure out how to parameterize so that if a line occurs less than X%, it doesn't display. I understand that in bet/raise situations, if the raise occurs 5%, it's important. But
I can see if we can add some sort of cutoff.
That said, it's worth noting that these lines don’t occur 0% of the time - they’re just very rare.
Something similar happened in the trainer, which you were able to solve by playing 'Loose mode.'
I’ve tried to reproduce this by doing the following:
1) Navigate to a node where at least one of the preceding actions is very rare.
2) Select "Drill the current decision – loose."
3) Sit down and started playing.
When I repeatedly press F1 (to draw a new hand), the rare line never seems to be selected.
Granted, if a line occurs 0.01% of the time, it could theoretically show up once every 10,000 hands—but in practice, that doesn’t seem to be an issue here.
Is it possible you're doing something different?
