ArrayIndexOutOfBoundsException on DaxPathFinder

itsdax / Runescape-Web-Walker-Engine

A navigation engine for OSRS written for TriBot

https://tribot.org/

Apache License 2.0

81 stars 37 forks source link

ArrayIndexOutOfBoundsException on DaxPathFinder #221

Closed BegTribot closed 6 months ago

BegTribot commented 11 months ago

https://github.com/itsdax/Runescape-Web-Walker-Engine/blob/25d77106b5aa3db1bcc2bb867eb7460a88e6d0e7/src/main/java/dax/walker/utils/path/DaxPathFinder.java#L168 Weird one, shouldn't collisionData.length < home.getX() prevent the ArrayIndexOutOfBoundsException? Can getX return different results for different calls? Maybe should be cached into a variable, same for home.getY()

java.lang.ArrayIndexOutOfBoundsException: Index -5129 out of bounds for length 104
at scripts.api.dax.walker.utils.path.l.G(DaxPathFinder.java:168)
at scripts.api.dax.walker.utils.path.b.f(PathUtils.java:35)
at scripts.api.dax.walker_engine.d.G(WalkerEngine.java:105)

itsdax commented 10 months ago

huh I thought those fields were final. I guess not

we should probably store it in a local variable as you mentioned

FALSkills commented 10 months ago

It's already being stored as a local variable. The X value being returned by home.getX() is -5129, and the function call is making sure it is less than 104 (so it is technically true). We could add a check to make sure it is >= 0, however this is caused by an underlying issue with TRiBot API.

itsdax commented 10 months ago

Maybe I'm misunderstanding something... but:

if home.getX() is -5129, then that contradicts with collisionData.length < home.getX()
collisionData.length can't be less than 0 so that means collisionData[home.getX()] shouldn't have ever triggered.
- if it did trigger, then that means home.getX() > 0, which wouldn't have caused this stacktrace

My understanding is that home.getX() returned 2 different values mid branch.

FALSkills commented 10 months ago

I must not have had my coffee yet when I was looking at this, because yes it is returning different values. It looks like this is due to how TRiBot calculates x/y when it is a local tile, as it is an active calculation based upon the map offset, and not simply returning an x or y. If I were to guess, this occurrs rarely while the next map chunk is being loaded. We can cache the x and y coords of the home tile rather than use the function calls and it should be fine.