Expose reachRange argument in findPath for PathFinder

[Doc94]

This PR just expose the accuracy for generate paths

[jpenilla]

Not sure about the accuracy name, I know that's the name from Parchment but it's assigned to a vanilla field reachRange.

[Doc94]

Not sure about the accuracy name, I know that's the name from Parchment but it's assigned to a vanilla field reachRange.

yeah i has the same question what name use the field or the other...

[Malfrador]

I like reachRange more. I don't really associate accuracy with pathfinding terminology personally.

If I wrote a pathfinder I'd probably name this parameter something like arrivalDistance or goalRadius.
reachRange seems close enough to that, and generally I think we should try to stick to Mojang names for simplicity.

[JavierFlores09]

I would call the parameter tolerance given it is only used in Pathfinder#findPath to check whether the manhattan distance between the currently evaluated node and the target node is less than or equal to the accuracy parameter. Higher accuracy values would lead to more target nodes being considered within reach, so it is counter-intuitive to what people would consider as "accurate".

That being said, higher tolerance values means more paths to search, which will either strain the server or just hit paper's pathfinding optimization where it just stops trying to pathfind after 10 failed paths or it has been less than 2 seconds since the last failed path. So there should be a note about using high values for this parameter. This is the case only for the moveTo methods, which I thought were being exposed too, it doesn't really matter for findPath

[lynxplay]

Agree with both above, accuracy is a pretty unfun name for this given it is inverted.
I don't have much of a preference between tolerance and reachRange, might as well just default to mojangs naming, the most important bit is good javadocs on the parameter (better than param reachRange The reach range lol)

[Leguan16]

Another name I suggested in discord was deviation. I figured to throw it in.

[Doc94]

Rebased and change the argument to reachRange based in the last changes in NMS (and the comment of lynx)

[Warriorrrr]

Range annotations should be added to the new params to indicate that they must not be negative, it would also be nice if the javadocs could explain what the param actually does

[Doc94]

Range annotations should be added to the new params to indicate that they must not be negative, it would also be nice if the javadocs could explain what the param actually does

the positive annotation not?

for the javadocs... not sure if you have a suggestion for that.. (my way to explaint things its not the best...)

[Warriorrrr]

Positive works too as long as IDEs support it, I am just more familiar with jetbrains'.

I don't have any suggestions for the javadocs, just needs to be sufficient enough so that plugin devs can know what it does without needing to ask in paper-dev

[Doc94]

Positive works too as long as IDEs support it, I am just more familiar with jetbrains'.

I don't have any suggestions for the javadocs, just needs to be sufficient enough so that plugin devs can know what it does without needing to ask in paper-dev

okay i use the NonNegative (like components) annotation because 0 its a valid number and Positive not allow that...

and for docs... im try something i hope basic explain what this does....

[Doc94]

docs modified with a little of help... i include a mention to a external site for what the algorithms used by internals.