I ran a script using micro saves. If I want to change those trees to small saves, can I do that? I know you have a rebuild command, but how do I use it and how can I make it so it only rebuilds the turn? (I don't want to have the trees be the massive size of full saves.)

Thanks!

For that usecase it's probably better to only set_mes in one node instead of the whole tree or maybe it's even better to just reassign cut frequencies to the highest EV (that makes it the most realistic without exploiting the opponent across the whole tree).

Unfortunately this isn't and won't be possible. You need to recalculate the trees and make small saves. It's possible the other way around though.

The reason for that is that once you have a micro save only most of the information in the tree is discarded (often as much as 99.9%). There is no way around recalculating that 99.9% so you may just as well run it from scratch.

Yeah but to get turn strategies you need to first calculate rivers anyway so the remark about re-creating 99.9% of the tree stands. Sadly you just need to run it from scratch.

Trust me, set_mes and branch cutting functionality is what we want for this procedure. I'm nagging because you mentioned in a support email exchange we had that the branch cutting might be on the way out. But please leave it in, that will make us happy. ;-)

We are a group of players working with this technique, and we have found it to be a strong approach for training post flop play in a way that simplifies our game plan at negligible EV cost (and sometimes actually EV-boosting, since a simplification might exploit leaks in the player pool).

The approach revolves around moving around "unseen" in equilibria under the assumptions that any small simplifications we do will mostly go undetected. Which is pretty much what happens when you play humans. That means we can gain a lot from simplifying our equilibrium strategy to a level where we are actually able to execute it.

When I try and run a flop multi file aggregate report I get a incorrect node type error.

I have my doubts but I am not going to go into this discussion right now

Does it happen at the start or when the report is already running after some time?
Do you have only saves from one script in the folder? (if not then it will be a problem because trees with different betting structure can't be aggregated).

You may also try following the video, here:
https://www.youtube.com/watch?v=VhG_YsEvfwU (question number 7, see the video description)

It happens at around 30%. I don't think the trees are different, when I run the script it shows all the trees are complete.

Do you sell chart solutions such as 3bet ranges from certain positions separately ?

I am sending you a PM with some questions and Skype contact.

We don't sell the solutions ourselves our friend who we worked with on that is running a PioCloud service though, you can ask him about details of the packs:

http://piocloud.******.com/

For tools>configuration>behavior, what is "Recalc accuracy as a fraction of the pot"?

What affect, if any, does it have on browsing the results? What affect, if any, does it have on time spent solving? (I mean what affect would changing any of those numbers have.)

I like to browse or flip through the various turn cards in a given tree one after the other, but I notice that if the ranges are wide, there is significant lag in loading the turn where I have to wait for a while before I can browse the turn action. Is there anything that I can do on my end to make it load more quickly? (I already have "dont show average line freq..." checked on data presentation tab fwiw.) And out of curiosity, are there like hardware components that govern that loading time. Like would a faster processor or higher Ghz eliminate or decrease that lag?

Thanks!

when you browse through small- or micro-saved solutions the solver has to recalculate forgotten turns/rivers, that's what recalc acc is for. if you lower the accuracy on a given street, browsing will take longer since the solver will produce more precise results, and the other way around. yes, a better processor decreases solving time, and thus also the time it takes to browse through incomplete trees; there's a bunch of info on good comp setups in here too I think.

I downloaded PioSolver free and for some reason the IP hand is not recognized in the browser. It is taking the same hand range from OOP and showing it as the IP range as well, even though in the preflop builder two separate ranges are selected for IP & OOP. Any idea what is going on?

As samooth explained below but you may also find this useful:
https://www.youtube.com/watch?v=VhG_YsEvfwU (point 5)

I am really not sure what you mean by "IP hand is no recognized in the browser". Can you make some screenshot with the problem description?

Did you try following the quick start video:
https://www.youtube.com/watch?v=QnzFpjSr3Lk (as the free version solves one flop: Qs Jh 2h these days it's possible to follow with the free version as well).

One guess I have is the "refresh on new selection" checkbox:
https://gyazo.com/a09378c888103a86607bbae9878c8153

is not checked so the results don't refresh when you browse the tree.

Any news on the new product/update that was announced in a message you wrote earlier in this thread? (it was going to be released end of last month if I remember correctly).
Am quite curious what exactly you guys will come out with

It's ready (and another thing is almost ready) but sadly technical problems coupled with holiday schedule issues delayed it. Right now the plan is to release during first week of August

Damn just upgraded to pro to lol

There will be 1.10 version for our current main product as well, don't worry. It will come later though.
New things are unrelated to the current one although we have made a lot of progress in the development version for NLHE Pio as well

Hi guys, I recently bought PioSolver and am having some problems with node locking.


I edited the flop Cbetting strategy for the OOP player then followed the instructions in the YouTube viedo; making the bet fixed rather than proportional and selecting 'lock all hands'.

I pressed GO in the tree building tab and when solved ran through the hand where OOP cbets flop gets called by IP, on the turn the OOP player turns up with the original range given to him before the lock. There are hands that I have locked to always check flop with that OOP still has on the turn after betting flop.


Has anyone else had this problem or know what I am doing wrong?

Thanks

Sounds like you are gonna try to teach me how to play PLO?

It's important to make sure you are making a distinction between range (how often you have a certain hand at given point in the tree) and strategy (what you do with a hand assuming you have it at this point). The strategy still exists even for hands not in range. Make sure you have "square size proportional to weight" checkbox checked (one of the 4 on the right). More here:

More here:
https://www.youtube.com/watch?v=VhG_YsEvfwU (question number 4).

This is the most likely reason of the problem you are describing. If it's not that please let us know.

Can one couple this program with range estimation programs and card fetchers to get suggested lines while playing online? Has anyone done this? How big of an edge is this?

No you can't.

Why not smartass?

1)it's technically possible but difficult, it would also be against sites ToSes.
2)I don't know if anyone has done this
3)it would be quite a big edge

I left pio overnight solving a preflop spot, when I woke up and checked how far it as I was surprised to see the "exploitable for" was fluctuating quite a bit.

https://i.gyazo.com/ee4a5ac793a028ce...ae500f0e7e.png

Now it's at 4.458 per hand after 40k seconds and keeps fluctuating with every new iteration. Is this normal for preflop sims? I don't remember the postflop sims I've done to fluctuate this much, they generally just go straight down.

I set the accuracy to 0.35% as I read earlier from this thread that it's generally good enough for postflop spots. Does this also apply to preflop sims?

The preflop solver operates on lower accuracy (to save memory) than the postflop one that's why this may happen in some spots. It's already improved a bit in dev but not completely solved. Here are things to keep in mind:

1)It's a very bad idea to use multiple bet sizes postflop when solving preflop trees. Not only it doesn't influence preflop ranges almost at all but it makes things very difficult for the preflop solver. It's especially important to avoid overbets (so "add all-in" checkbox)

2)It's easier for the solver if actions which go to 0% frequency during solving are not included in the tree.

3)Sometimes you just can't reach very good accuracy (bb/100 wise), this happens mainly in forced 3bet/4bet scenarios where the starting pot is very big.

It's not easy to tell what the starting pot is in the preflop scenarios (it's unclear how to treat blinds) it makes more sense to operate on bb/100 terms there. You should aim at 2bb-3bb/100 accuracy. You can usually go lower than that with enough time but sadly not always.