Doors #1445
Doors #1445
Conversation
|
It doesn't like going right->left diagonally with this |
|
Ok, the bugs should be ironed out and it's passing all the checks (except Codacy's npath requirements, but I'm not sure if those are actual requirements). |
|
Thank you so much for taking the time to dive in and make this PR :) Looks pretty cool. Codacy doesn't really matter as long as it's formatted right, which it is. Here's the thing though: the pathing thread is, as you might imagine, performance-dominated by movement cost calculation. All the other A* stuff like heuristic, open set heap, and node map end up contributing very little to the performance. A big part of why baritone is so fast is something I did pretty early on, here #180 which is that movement cost calculation is not allowed to allocate any objects. Not even a single |
|
😻 holy cr*p |
|
|
|
im having a really hard time figuring out what the heck is supposed to be happening here? it looks to my eyes this will double the cost of a traverse where the source and destination are currently underground, such as during auto mining? because you're now also taking into account the cost of mining the source blocks?? why? we assume that by the time it's this movement's turn to run, the previous movement has gotten our player into that position, so those blocks will have already been cleared also seems like a missed opportunity to do all this for doors and not also for, e.g., fence gates and trapdoors... |
|
It checks the source blocks in order to make sure that the player isn't standing in the same block as a door which would block the player's movement. EX:
That's what I want to work on next, but I thought it would be better to make that a separate pull request. Efficiency could be improved further, so I guess I'll look into that |
|
This may be over complicated, but perhaps multiple heuristics functions could be used? You'd keep the current heuristic, but afterwards you could have a heuristic that works using only PathingBlockType data (AIR, WATER, AVOID, SOLID), and then finally use the regular calculations. |
|
Right, but your code is adding in the cost of breaking the source blocks. This is incorrect. |
|
Also closes #1454, for reference. |
|
Only MovementTraverse actually tries to open doors and fence gates, and you'd have to create a few utility methods and refactor some stuff in order to get other movements to open doors and fence gates. |
Oh, that's if the player is standing inside an iron door |
|
Most of getMiningDurationTicks() is skipped if the player can walk through the block they're standing on. |
|
Hang on |
|
No, traverse is called underground quite commonly. You aren't supposed to include the cost of mining the source blocks! |
|
This should be faster |
|
|
|
It works normally top->bottom though |
|
Can it be merged, or does it need improvement? |
| if (totalCost >= COST_INF) { | ||
| return; | ||
| } | ||
| totalCost += MovementHelper.getMiningDurationTicks(context, destX, y, destZ, false); | ||
| totalCost += MovementHelper.getMiningDurationTicks(context, x, y, z, false, SpaceRequest.fromFaces(direction)); |
There was a problem hiding this comment.
Sorry. We just can't do this. This double counts ALL cost.
If there's a traverse for example deep underground, this would count the cost of breaking the starting position (two blocks) and the cost of breaking the destination position (two blocks). That just isn't correct. The core movement logic assumes that by the time a movement starts, the previous movement is completed and has moved the player to the start of this movement, which includes breaking any blocks that may have been in the way. This breaks that assumption for the sole benefit of allowing us to open doors that we're standing in at the beginning of the path. There are better ways to accomplish that that don't involve breaking cost calculation invariants.
I wrote some code to handle doors better. Now, baritone can walk through iron doors that aren't obstructing its path. This should also make it much easier to handle trapdoors.