Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR tries to adress several problems with the getBlock() function in Pathfinding that is core to how paths are generated and also to various Behavior Nodes
Issues that the PR addresses
In the debug overlay, (Not shown in the screenie), the position has an X coordinate of -10.41. However, the block that is chosen by the function is the one with an X coordinate of -11. It can also be slightly seen that the left block should be the block that should be chosen. The erroneous line seems to be
Vector3i blockPos = new Vector3i(pos.x + 0.25f, pos.y, pos.z + 0.25f);
The author of the line might have some other idea in mind, but I am unable to see it. With that said, I feel the change definitely makes the system work better.
You can see in the screenie that even though, the character is 2 blocks high, the output of findBlock() selects a block that is lower. This happens because, in the previous version, only the blocks directly underneath were checked (untill a non null value of block was found). This is wrong because a character hanging from the side of a block (like me in the screenie) would receive a wrong answer. Hence it is essential to also check the surrounding blocks. The order in which the surrounding blocks are checked is also essential. I have tried to implement a custom comparator that checks the blocks in the order of their distances to the location of the entity, ie, the closest block is checked first and then so on.
Some issues left unresolved
You can see in the screenie how even though I am on the ground, the block that is at a height 1, is highlighted. This happens because for floating cubes, the position field points to the feet which are actually hovering above. I don't really see any other fix other than creating a field in the MinionMoveComponent that stores the distance between the feet and the ground. With this, we can also get rid of the need to check the blocks underneath.
Testing Instructions
Open up TutorialPathfinding with the branch improvement/FindBlock. On spawn, you should see a group of 3 yellow flower items in your inventory. The third of this group is the findBlock() item. It highlights the output of findBlock() at the player's location with a pink colour when activated using a right click. Make different structures and try to see if the output is correct.