Override default run behaviour in webwalker

[timthebot]

Hi there,

 

So as far as I can see, if I use the following:

getWalking().webWalk(Positions... positions)

then the default behaviour is to turn run on. Is there a way for me to specify if I would like to walk or run.

 

Thanks

[Flamezzz]

Yes but you have to use the 'low level' api (events):
 

Position dst = new Position(0,0,0);
INodeRouteFinder nrf = INodeRouteFinder.threadSafeWrapper(INodeRouteFinder.createAdvanced());
WebWalkEvent e = new WebWalkEvent(nrf, dst);
e.disableRun();
boolean failed = execute(e).hasFailed();

[dopenes]

That seems like poor design. Why doesn't Alek implement a method to disable/enable that behavior....

 

Something like:

public void onStart()
{
     //code..

     //The method..
     getWalking().setRunEnabled(true);

     //code..
}

Edited January 28, 2016 by dopenes

[FrostBug]

 

That seems like poor design. Why doesn't Alek implement a method to disable/enable that behavior....

 

Something like:

public void onStart()
{
     //code..

     //The method..
     getWalking().setRunEnabled(true);

     //code..
}

 

Because the webwalker is still a new feature, and nobody has made an official suggestion in the suggestions section.

 

[timthebot]

 

Yes but you have to use the 'low level' api (events):

 

Position dst = new Position(0,0,0);
INodeRouteFinder nrf = INodeRouteFinder.threadSafeWrapper(INodeRouteFinder.createAdvanced());
WebWalkEvent e = new WebWalkEvent(nrf, dst);
e.disableRun();
boolean failed = execute(e).hasFailed();

 

 

Ooh that looks lovely thank you!

 

Just had another question, the webwalk seems to end every route very consistently, as follows:

 

1) Walks as close to end tile as possible

2) Finishes route by spam clicking specific block until character is on exactly that tile.

 

This last behaviour is something I'd imagine is rather detectable... is there a way to specify that routes are allowed to be approximate, and then the event will end when the distance to the final tile is under some tolerance?

[lisabe96]

Ooh that looks lovely thank you!

 

Just had another question, the webwalk seems to end every route very consistently, as follows:

 

1) Walks as close to end tile as possible

2) Finishes route by spam clicking specific block until character is on exactly that tile.

 

This last behaviour is something I'd imagine is rather detectable... is there a way to specify that routes are allowed to be approximate, and then the event will end when the distance to the final tile is under some tolerance?

In my experience webwalker finishes when it's under 2-3 tiles distance of the destination automatically?

Annoys the shit out of me sometimes when I runs out of a building because of that

[FrostBug]

Ooh that looks lovely thank you!

 

Just had another question, the webwalk seems to end every route very consistently, as follows:

 

1) Walks as close to end tile as possible

2) Finishes route by spam clicking specific block until character is on exactly that tile.

 

This last behaviour is something I'd imagine is rather detectable... is there a way to specify that routes are allowed to be approximate, and then the event will end when the distance to the final tile is under some tolerance?

 

WalkingEvent has a setMinDistanceThreshhold, but this does not seem to be in WebWalkEvent yet.

 

Try setting a break condition to check the distance to the goal.

wwEvent.setBreakCondition(new Condition() {
    @Override
    public boolean condition() {
        return myPosition().distance(destination) <= threshhold;
    }
});

(wrote in hand, probably got errors)

 

[timthebot]

Perfect, thanks guys

[lisabe96]

Wait a sec, I seem to have the same problem in .37

I want to walk to the bank area but it is spam clicking the same tile every time again rather than using a random position.

[timthebot]

Wait a sec, I seem to have the same problem in .37

I want to walk to the bank area but it is spam clicking the same tile every time again rather than using a random position.

 

Yes, I believe the functionality you described was as it worked for me in 2.4.36, however with the update to .37 its now spam clicking a very specific tile each time...

 

I assume you are walking to bank with, for example:

getWalking().webWalk(Banks.VARROCK_EAST); 

Using this it'll even go so far as run INTO the area, be definitely within the area, and then spam click the specific spot until it gets there...

 

Bear in mind I'm currently at work so I can't test anything out at the moment, I will try the condition approach suggested when I get home from work in about 6 hours...

[lisabe96]

Yes, I believe the functionality you described was as it worked for me in 2.4.36, however with the update to .37 its now spam clicking a very specific tile each time...

 

I assume you are walking to bank with, for example:

getWalking().webWalk(Banks.VARROCK_EAST); 

Using this it'll even go so far as run INTO the area, be definitely within the area, and then spam click the specific spot until it gets there...

 

Bear in mind I'm currently at work so I can't test anything out at the moment, I will try the condition approach suggested when I get home from work in about 6 hours...

Yes that's exactly what I'm using and the issue I have, i posted about it in the bug section

[Alek]

@Dopeness - If you want full customization of an event, you can create the event yourself as pointed out by Flamezzz. The "front-end" API is for newer scripters or people who are perfectly fine with how the default events are handled. 

I'm aware of some of the main screen tile spam along with spamming the minimap on the first tile being walked to. We tried to patch a serious issue with web walking to areas, in which because of the threshold you would walk right outside it. The spamming/clunkiness is something which is something that will take a little bit of time to smooth out.

[lisabe96]

@Dopeness - If you want full customization of an event, you can create the event yourself as pointed out by Flamezzz. The "front-end" API is for newer scripters or people who are perfectly fine with how the default events are handled. 

I'm aware of some of the main screen tile spam along with spamming the minimap on the first tile being walked to. We tried to patch a serious issue with web walking to areas, in which because of the threshold you would walk right outside it. The spamming/clunkiness is something which is something that will take a little bit of time to smooth out.

 

It's not just the spamming, as I told in my bug thread it also doesn't randomize the position when using webWalk(area)

It goes to the exact same tile every time.