Low CPU Mode

[The Undefeated]

When using Low CPU mode, the bot actually skips methods or gets stuck. For example: When trying to open the bank, it will open it, right after close it and does this 3 times.

Any way to fix this? Or is the best way to just not use low CPU mode.

 

[Reveance]

Always exactly 3? That's interesting since it's also a problem with GrandExchange#buyItem when on low CPU mode or if there's little CPU resource available

[Mordred]

Shits weird o.O

[Hel]

I've had this too, the way to ghetto-like fix I found was to just add a sleep function after opening the bank

Edited April 3, 2017 by Slut

[naaiz]

Conditional sleeps should fix it

[Booleans YAY]

I always use this on my VPS low CPU and disabled rendering. I don't have this issue ever though.

[The Undefeated]

2 hours ago, Slut said:

I've had this too, the way to ghetto-like fix I found was to just add a sleep function after opening the bank

This is my open bank method.

 

    public void openBank() throws InterruptedException {
        NPC banker = getNpcs().closest("Banker");
        if(!bank.isOpen()) {
            if (banker != null && banker.isVisible()) {
                banker.interact("Bank");
            } else {
                getBank().open();
            }
            Timing.waitCondition(() -> bank.isOpen(),6000);
            sleep(random(300,600));
        }
    }

It has a conditional sleep and it still happens sometimes. The same for opening Grand Exchange, it opens it and closes it 2/3 times. 

It even accidently pressed on the banker NPC opening a dialoge and not opening the bank. There is also a bug in the buyItem method for the GE.

 

2 hours ago, Reveance said:

Always exactly 3? That's interesting since it's also a problem with GrandExchange#buyItem when on low CPU mode or if there's little CPU resource available

Not always 3, sometimes even 4. I'll try to record it. 

 

I don't really want to add a conditional sleep to every method which requires to open a interface if there's another option.

The weird part is that it also closes the interface, why should it? When calling the openBank() method, does it automatically close and reopen it?

Edited April 3, 2017 by The Undefeated

[harrypotter]

16 minutes ago, The Undefeated said:

This is my open bank method.

 

    public void openBank() throws InterruptedException {
        NPC banker = getNpcs().closest("Banker");
        if(!bank.isOpen()) {
            if (banker != null && banker.isVisible()) {
                banker.interact("Bank");
            } else {
                getBank().open();
            }
            Timing.waitCondition(() -> bank.isOpen(),6000);
            sleep(random(300,600));
        }
    }

It has a conditional sleep and it still happens sometimes. The same for opening Grand Exchange, it opens it and closes it 2/3 times. 

It even accidently pressed on the banker NPC opening a dialoge and not opening the bank. There is also a bug in the buyItem method for the GE.

 

Not always 3, sometimes even 4. I'll try to record it. 

 

I don't really want to add a conditional sleep to every method which requires to open a interface if there's another option.

The weird part is that it also closes the interface, why should it? When calling the openBank() method, does it automatically close and reopen it?

Try something like this:

public void openBank() throws InterruptedException {
    if (!getBank.isOpen()) {
        if (getBank.open()) {
            Timing.waitCondition(() -> getBank.isOpen(), 6000);
        }
    } else {
        // Bank is open
    }
}

I've never had problems with handling banks in this way.

Edited April 3, 2017 by harrypotter

[Hel]

I use 

private void openBank() throws InterruptedException {
		bank.open();
		int reset = 0;
		while (!bank.isOpen()) {
			sleep(random(10, 15));
			reset++;
			if (reset > 300) {
				reset = 0;
				bank.open();
			}
		}
}

 

[Apaec]

You can't rely on an api method to execute correctly first time, low-cpu or not (The reason for this is the bot is dealing with a live game, so latency fluctuations / dcs etc also have a say in the script execution). For this reason, writing scripts in a heavily 'recipe' style is not recommended (e.g bank#open, then bank#withdraw assuming the bank is open after calling bank#open)

Try and design your scripts such that it will do whatever it needs to do and repeat if necessary to reach the desired in-game situation.

(tip: try the if statement)

~apa

2 minutes ago, Slut said:

I use 

private void openBank() throws InterruptedException {
		bank.open();
		int reset = 0;
		while (!bank.isOpen()) {
			sleep(random(10, 15));
			reset++;
			if (reset > 300) {
				reset = 0;
				bank.open();
			}
		}
}

 

D:

[Hel]

1 minute ago, Apaec said:

You can't rely on an api method to execute correctly first time, low-cpu or not (The reason for this is the bot is dealing with a live game, so latency fluctuations / dcs etc also have a say in the script execution). For this reason, writing scripts in a heavily 'recipe' style is not recommended (e.g bank#open, then bank#withdraw assuming the bank is open after calling bank#open)

Try and design your scripts such that it will do whatever it needs to do and repeat if necessary to reach the desired in-game situation.

(tip: try the if statement)

~apa

D:

don't give me that, it's rough but it works

[Apaec]

Just now, Slut said:

don't give me that, it's rough but it works

Apologies haha, it's a sure way to end up in an infinite loop, perhaps consider a for loop or a different design such as integrating a method relying on the onLoop's delayed loop to retry!

[Hel]

Just now, Apaec said:

Apologies haha, it's a sure way to end up in an infinite loop, perhaps consider a for loop or a different design such as integrating a method relying on the onLoop's delayed loop to retry!

It honestly doesn't end up in an infinite loop ever, I've ran scripts for over 24 hours with that banking method and it doesn't get stuck, also I suck at utilizing the onLoop's loop. To your dismay I use those sort of loops to retry all my actions that could have a miss-click or something of the sort.

[Apaec]

2 minutes ago, Slut said:

It honestly doesn't end up in an infinite loop ever, I've ran scripts for over 24 hours with that banking method and it doesn't get stuck, also I suck at utilizing the onLoop's loop. To your dismay I use those sort of loops to retry all my actions that could have a miss-click or something of the sort.

I would highly recommend against that. Although you might have gotten lucky in the past, using while loops like that means the risk of getting stuck is high. There's no perfect solution but it's important to design your scripts as to minimise this risk!

[The Undefeated]

7 minutes ago, Apaec said:

Apologies haha, it's a sure way to end up in an infinite loop, perhaps consider a for loop or a different design such as integrating a method relying on the onLoop's delayed loop to retry!

If there's a reason why it would run in an infinite loop it would be quite useful, if the script continues while not being able to open the bank it could lead to more bigger problems.