More aggressive path splicing about baritone HOT 4 CLOSED

Done! e0f2159

from baritone.

Here's a gotcha, 30-minutes-ago-self. If the next path is allowed to start anywhere along the current path it wants, it might start from a position that it's already passed.

So there's a tradeoff here. The earlier you calculate the path, the more breathing room you have to calculate the next one. But also, the earlier you calculate it, the fewer chunks are loaded in the direction you're going in. (this is why old MineBot next planning was so dumb: it starting calculating the next segment immediately after current finished calculating and started executing). So, right now path calculation takes a max of 4 seconds, and to account for fluctuations between cost calculation and actual tick time, we start calculating the next path 150 ticks out (7.5 seconds). So, theoretically, we could start calculating at 150 ticks out, then allow the last 3 seconds of path to be valid starting points for the next path? This is tricky. What if there's an overestimate in cost? Does the current path just stop N blocks from the end because it's still waiting for the next one to be done calculating and we told it that it could start from any of these last N blocks?

This is starting to just sound like we should cutoff the last N blocks from every path we calculate and let the next one start from there, which is bad.

from baritone.

Ok here's a better way to do it! Force the next path to start from exactly the end of the current one, but decrease the cost of backtracking below what the actual costs of those movements are. Like, if a movement ends on a position that's a part of the current path, decrease its cost by 10%. This will tiebreak between all the possible traverse/diagonal combinations to backtrack and make the "best" one an exact backtrack of the current path. This way we can use the existing path splicer and get the benefit. Yay!

from baritone.

Explanatory video: https://www.youtube.com/watch?v=CGiMcb8-99Y

from baritone.