Fix not moving from edge of block

[babbaj]

To try to keep you safe, if you are standing on the edge of a block baritone will choose to start the path on that block rather than the feet because you are standing on air. If the goal happens to also be on that block, the start will already be in the goal and A* will return no movements so baritone will not move. If that is the case then it should be safe to just path from the feet anyways.

tl;dr this fixes baritone not moving when you are on the edge of a block and the goal is in your face

more information in #209

[ZacSharp]

If that is the case then it should be safe to just path from the feet anyways.

No, it's not. Walking onto the supporting block should be safe, but there is no guarantee that a* will decide to do so.
E.g. if all four directions lead directly to a goal, evaluation order decides which is picked. In this video that's consistently -z even if the only safe option is +z.

2024-10-14.15-25-13.mp4

[leijurv]

Thanks for checking that zac, this is the exact case that I was avoiding back in 2018. Particularly, when pathing around 2b2t spawn, it would sometimes get stuck and recalculate, meaning this could happen in the middle of a path not just at the beginning. Sometimes it would be just off the edge of a block, and so if there was no foot support underneath the first movement, it would sometimes decide to do a walk (or a parkour) that would instantly fall like that.

[babbaj]

Just pushed a completely different way to fix this buy prepending the feet position the the path if the start position is different from the feet and only 1 block away

[leijurv]

This is a much better approach I think.

If I'm understanding right, if I'm sneaking off the edge of a block, this will insert an initial movement from playerFeet to pathStart?

This solves your issue because if I'm sneaking off the edge of the goal, this will create a 1 movement long path that basically just centers the player on the block? Does that actually work though? Like will AStarPathFinder actually return an empty path, which you prepend that one movement to?

In the actual technique here, I think there might be a more elegant way:

baritone/src/main/java/baritone/pathing/calc/AStarPathFinder.java

Lines 54 to 58 in 1e2ae34

	startNode = getNodeAtPosition(startX, startY, startZ, BetterBlockPos.longHash(startX, startY, startZ));
	startNode.cost = 0;
	startNode.combinedCost = startNode.estimatedCostToGoal;
	BinaryHeapOpenSet openSet = new BinaryHeapOpenSet();
	openSet.insert(startNode);

Could there just be like a "if we are doing the fake extra movement, make a node called realStart, and do startNode.prev=realStart? That way AStar won't freak out on a path of length 0?

[babbaj]

If I'm understanding right, if I'm sneaking off the edge of a block, this will insert an initial movement from playerFeet to pathStart?

yes

I did some debugging to understand what happens and A* does return a path of 0 length. This only changes what happens after A* returns. That change would be a bit more elegant but wouldn't make any difference because the PathNodes aren't treated like a linked list after that (assembleMovements uses list indexing).

[leijurv]

Okay! So, for example, in zacsharp's example gif, this version would not fall into lava, it would instead path from the supporting block around the lava to the goal, then insert a movement from the above lava position to the supporting block? So it would make like a ? shape?

If you want to do it this way, IMO that's fine. Prepending a blockpos is fine. I just think "realStart" is a bit of a vague name, but fine. Can you add a block comment somewhere explaining the idea and linking to this PR?

[babbaj]

then insert a movement from the above lava position to the supporting block? So it would make like a ? shape?

yes

I just think "realStart" is a bit of a vague name

It could be called playerAt or something but that's not the case when baritone is pathfinding ahead

[ZacSharp]

Found an edge case: #4528