LocalWalker for Position[] fix

[Renegeade]

Hey everybody,

 

One of the things I noticed while developing a script was that walkPath for a Position array sometimes just stops working in the middle for long walking distances. So I wrote a snippet that seems to work around the problem!

 

It checks the distance from the final position every 3 seconds. If the distance from the final position has not changed over 3 seconds, then it builds a "shortened" list, starting from the closest point to where the client is, to the destination, and restarts the local walker. Pretty simple and effective

    private void safeWalkTo(Position[] p) throws InterruptedException {
        this.getLocalWalker().walkPath(p);
        Position lastPos = p[p.length - 1];
        while (true) {
            double lastDistance = distanceSquared(this.myPosition(), lastPos);
            if (lastDistance < 4.5d) {
                break;
            }
            sleep(3000);
            if (Math.abs(distanceSquared(this.myPosition(), lastPos) - lastDistance) < 1.1d) {
                ArrayList<Position> shortenedPath = new ArrayList<Position>();
                boolean startAdding = false;
                for (Position pos : p) {
                    if (distanceSquared(this.myPosition(), pos) < 100d) {
                        startAdding = true;
                    }
                    if (startAdding) {
                        shortenedPath.add(pos);
                    }
                }
                this.getLocalWalker().walkPath(shortenedPath);
            }
        }
    }

    private double distanceSquared(Position p1, Position p2) {
        return Math.pow(p1.getX() - p2.getX(), 2d) + Math.pow(p1.getY() - p2.getY(), 2d);
    }

Edited December 24, 2014 by Renegeade

[Swizzbeat]

Scripting with loops that can continue indefinitely is extremely bad practice. Not only are you breaking the design pattern, but it presents a handful of issues. What if the player is being attacked while they're walking? Maybe a random event might show up? Each script loop should happen as quick as possible so the cycle can restart and determine it's next action based on the given environment conditions.

[Renegeade]

Shouldn't be too much of an issue considering that if the script is stuck too long OSBot interrupts the thread the script is running on.

 

Furthermore, if the player is being attacked while moving, then the scripter should break down the long path into shorter paths and write special code to account for the areas in which the player could get attacked. Otherwise, continuing to move will ensure that the player gets away from the zone of combat.

 

If the original scripter didn't write his own code to handle areas of combat, then that's laziness on the part of the scripter, not anything with this snippet.

 

Furthermore, this doesn't really break the design pattern; from what I can tell, the design pattern of OSBot is to throw a thread at the problem: All the function calls are blocking. When you say that all the script loops are meant to return as quickly as possible, you're thinking of an async, callback-orientated API, which OSBot clearly is not.

Edited December 24, 2014 by Renegeade

[Novak]

walking methods should be boolean to determine if they have happened/you are at the tile/Area you want to be

[Swizzbeat]

Shouldn't be too much of an issue considering that if the script is stuck too long OSBot interrupts the thread the script is running on.

Why would you EVER design a script that could get stuck in the first place?

 

 

Furthermore, if the player is being attacked while moving, then the scripter should break down the long path into shorter paths and write special code to account for the areas in which the player could get attacked. Otherwise, continuing to move will ensure that the player gets away from the zone of combat.

I can't tell if you're being serious or just stupid....

 

If the original scripter didn't write his own code to handle areas of combat, then that's laziness on the part of the scripter, not anything with this snippet.

 

This has nothing to do with anything. Why would you ever want to create separate handling for each area of combat, that's just pointless.

 

Furthermore, this doesn't really break the design pattern; from what I can tell, the design pattern of OSBot is to throw a thread at the problem: All the function calls are blocking. When you say that all the script loops are meant to return as quickly as possible, you're thinking of an async, callback-orientated API, which OSBot clearly is not.

 

You're running your code in a LOOPING method. I've worked on the API, most likely you're using a few of the methods I've written, and all event driven scenario checks happen at the start of the loop. You're attempting to write code that assumes things are static in an environment riddled with independent variables.

 

As for blocking function calls, that's poor design on whoever wrote it. I never liked the way OSBot's API was constructed.

[Renegeade]

If this is not the expected way to do it, what would you suggest?

 

My script needs to walk long distances, and LocalWalker seems to stop working somewhere along the path without fail. It's at a different point every time.