Sometimes with random events the dialogue after them will not close by themselves and I have to pause my bot to manually do it. You should allow an extra second after randoms and then 'click to continue' any dialogue boxes. You may already do this, but if my internet lags it won't so you should have some type of fail safe on this, i.e.

while (isDialogueOpen()) {
    clickToContinue();
    Thread.sleep(random(567, 789));
}

Thanks.

Sometimes with random events the dialogue after them will not close by themselves and I have to pause my bot to manually do it. You should allow an extra second after randoms and then 'click to continue' any dialogue boxes. You may already do this, but if my internet lags it won't so you should have some type of fail safe on this, i.e.

while (isDialogueOpen()) {
    clickToContinue();
    Thread.sleep(random(567, 789));
}

Thanks.

 

 

 

Hey I know this has nothing to do with your bug report but I suggest you look into dynamic sleeps if you are not already familiar. It will make your scripts a lot more crisp and prevent infinite loops Here is an example:

if(isDialogueOpen())
{
    if(clickToContinue())
    {
        long markTime = System.currentTimeMillis();

            while(isDialogueOpen()  && ((System.currentTimeMillis()-markTime) < timeout))
                Thread.sleep(10,20);
        }
    }   
}

This way it breaks out of the loop instantly (pretty much) rather than potentially just sitting there doing nothing for half a second. Choose however long you want the timeout to be in milliseconds.

Edited April 23, 201412 yr by KMJT

Hey I know this has nothing to do with your bug report but I suggest you look into dynamic sleeps if you are not already familiar. It will make your scripts a lot more crisp and prevent infinite loops Here is an example:

if(isDialogueOpen())
{
    if(clickToContinue())
    {
        long markTime = System.currentTimeMillis();

            while(isDialogueOpen()  && ((System.currentTimeMillis()-markTime) < timeout))
                Thread.sleep(10,20);
        }
    }   
}

This way it breaks out of the loop instantly (pretty much) rather than potentially just sitting there doing nothing for half a second. Choose however long you want the timeout to be in milliseconds.

 

I see what you're saying but the loop should never be infinite unless there is an underlying problem with the 2 methods you use to check if the chatbox interface is open and exiting it. I do agree it would be a safe practice to add a timeout check. I'd prefer this though:

while (isDialogueOpen() && System.currentTimeMillis() - start > 10000) {
    clickToContinue();
    Thread.sleep(random(567, 789));
}

EDIT: Also if the clickToContinue() method were to malfunction once the dialogue box would stay open and create the same problem.

 

Thanks for the input 

Edited April 24, 201412 yr by Mikey1

I see what you're saying but the loop should never be infinite unless there is an underlying problem with the 2 methods you use to check if the chatbox interface is open and exiting it. I do agree it would be a safe practice to add a timeout check. I'd prefer this though:

while (isDialogueOpen() && System.currentTimeMillis() - start < 10000) {
    clickToContinue();
    Thread.sleep(random(567, 789));
}

EDIT: Also if the clickToContinue() method were to malfunction once the dialogue box would stay open and create the same problem.

 

Thanks for the input 

You would get the same effect reducing

 

Thread.sleep(random(567, 789));

to a much smaller sleep. Having such a high sleep gives the potential for 0.5-0.7 seconds of dead time which could ultimately be avoided just by lowering the sleep. The sleep is pretty much useless since there is a timer, it is only in there so CPU doesn't spike in the loop.

For example, your timeout is 10000 ms. Say right before the loop start was at 9999ms, meaning you would go in the loop. Now you are stuck in there for 567ms to 789ms. Also you should use booleans to your advantage (unless clickToContinue() is not a boolean but I think it is) . That way if it returns true, you can wait for the next interface, otherwise you can assume the click didn't work and recheck right away without sleeping at all.

You'd be surprised how often methods you think that are full proof fail. The methods provided in the API are just something to work with but you still have to failsafe.

Edited April 23, 201412 yr by KMJT

You would get the same effect reducing

 

Thread.sleep(random(567, 789));

to a much smaller sleep. Having such a high sleep gives the potential for 0.5-0.7 seconds of dead time which could ultimately be avoided just by lowering the sleep. The sleep is pretty much useless since there is a timer, it is only in there so CPU doesn't spike in the loop.

For example, your timeout is 10000 ms. Say right before the loop start was at 9999ms, meaning you would go in the loop. Now you are stuck in there for 567ms to 789ms. Also you should use booleans to your advantage (unless clickToContinue() is not a boolean but I think it is) . That way if it returns true, you can wait for the next interface, otherwise you can assume the click didn't work and recheck right away without sleeping at all.

You'd be surprised how often methods you think that are full proof fail. The methods provided in the API are just something to work with but you still have to failsafe.

 

 

Normal people don't click 100 times a second, hence the high sleep time. That being said, I'm not sure how this is relevant to the topic. With regards to the top, what effect are you referring to? Also, what is the problem with "dead time", the sleep time after the clicking is also to allow the packets to be sent and received (that way, say your in w301, you won't be adding 25 people to your friends list by clicking the chatbox several times).

Normal people don't click 100 times a second, hence the high sleep time. That being said, I'm not sure how this is relevant to the topic. With regards to the top, what effect are you referring to? Also, what is the problem with "dead time", the sleep time after the clicking is also to allow the packets to be sent and received (that way, say your in w301, you won't be adding 25 people to your friends list by clicking the chatbox several times).

At the very least you should be using the methods as they were intended to be used. I assumed by your "clickToContinue()" method you were actually referring to continueDialogue(), which returns a boolean. So you should be using it as a boolean at the very least:

while(isDialogueOpen())
{
    if(continueDialogue())
    {
        long markTime = System.currentTimeMillis();

        while(isDialogueOpen() && ((System.currentTimeMillis()-markTime) < 1500))
            Thread.sleep(10,20);
    }
}

Not sure why you are thinking that it will spam click. If the continueDialogue() returns true (which is why you should be using it as its intended return type, boolean), it will wait for the npc dialogue box to disappear. If for some reason continueDialogue() returns true even though it didn't actually click continue, your fail safe is there (the timeout of 1.5 seconds) to take this into account. If continueDialogue() returns false in the first place, meaning the click on continue was not successful, it will retry right away without sleeping for unnecessary 0.5 - 0.8 seconds.

I am just trying to help. I will leave the thread now, I am not trying to be offensive towards you.