Jump to content
Sign in to follow this  
IceKontroI

Help with Conditions (EDIT: SOLVED)

Recommended Posts

EDIT: Figured it out. Needed to do

while (!stop.active()) {

    // continue walk process

}

Feel free to use this post as a reference if you are having the same problem.

I would like to add a stopping condition to a custom walking method I wrote, but I can't seem to get the condition to recalculate each time; it just keeps using the original value I fed into it on method start. Here's some pseudo code to give you an idea what I'm working with:

public static void walkMethod(RSTile[] path, Condition stop) {
	System.out.println("Beginning walk process.");
	while (stop != null && pathList.size() > 0) {
		// select tile to walk to
		// click tile
		// sleep
	}
}

And the Condition looks like:

	static Rectangle destinationArea = new Rectangle(1, 1, 4, 6);

	static Condition stoppingCondition =  new Condition() {
		public boolean active() {
			System.out.println("THIS TEXT SHOULD BE VISIBLE.");
			General.sleep(10);
			RSTile playerTile = Player.getPosition();
			Point playerPoint = new Point(playerTile.getX(), playerTile.getY());
			return destinationArea.contains(playerPoint);
		}
	};

The first thing I don't understand is what Conditions actually return. I would assume it's either true or false, but it seems to be more than that. This will help me figure out how to word my while loop so it can stop when the player's position is in the destinationArea.

The other thing I don't get is how to make the Condition run through each line whenever it's called within the containing walkMethod(). I should be seeing the "THIS TEXT SHOULD BE VISIBLE." text every time the while loop in walkMethod() iterates but it never displays.

Any insight into how I'm doing this wrong would be greatly appreciated. I wish I didn't have to ask on the forums, but there isn't any good documentation anywhere on how Conditions work (on tribot Conditions at least).

Edited by IceKontroI

Share this post


Link to post
Share on other sites

@IceKontroI

Conditions should return true if the walking method should break early, and false if it shouldn't.
 

It is encouraged to use the premade Walking methods, you can add the condition as a argument in most functions, and it will be checked constantly while walking.
Walking#walkPath would fit your case.

The stopping_condition_delay argument is the amount of 'sleep' that is used while constantly checking your condition during walking.

 

Please don't be afraid to ask :) I think many of us would be glad to help you.

Share this post


Link to post
Share on other sites
3 minutes ago, IceKontroI said:

@laniax thank you, but as it turns out I figured out the problem almost immediately after posting. Turns out you can't check if the Condition == a boolean value, but you can check if the Condition.active() == a boolean value, which solved the problem.

That is correct, but it is still recommended to use the Walking methods, since it will check your condition async instead of, for example, only before clicking.
It has extra antiban as well.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Our picks

    • This release will:

      Fix login bot after today's game update (Thanks @JoeDezzy1)


      Fix latest in-game world hopping issues (Thanks @erickho123)


      Compact Settings UI and set location relative to TRiBot (Thanks @JoeDezzy1)


      Fix an older implementation of GrandExchange#getWindowState (Thanks @JoeDezzy1)


      Improve the preformance of NPCChat by only searching in certain interface parents (Thanks @JoeDezzy1)



      Upcoming updates:

      Break handler bug fix


      Improved CLI support


      LG support for RuneLite


      Much more



      Note: If you are using LG, please restart both the RS client and TRiBot
        • Thanks
        • Like
      • 15 replies
    • This release will:

      Fix bytecode manipulation in order to prevent the modification of parameters within the Filter and Condition classes themselves (thanks @wastedbro)


      Fix NPE caused by non-null value in GE API (thanks @erickho123)


      Add and fix equals methods for api2007.types (thanks @JoeDezzy1)


      Modify Mouse#leaveGame to make the mouse leave the game from top, left, right, or bottom (thanks @erickho123)


      Add Entrana area to Ships API (thanks @erickho123)


      Fix raid prayers index/settings in Prayer API (thanks @erickho123)



      Upcoming updates:

      Break handler bug fix


      Improved CLI support


      Much more



      Note: If you are using LG, please restart both the RS client and TRiBot
        • Like
      • 29 replies
    • This update will:

      Implement better canvas locking/synchronization mechanism


      Fix small Login API bug


      Remove the requirement for xbooting Java classes


      Use ExecutorService to perform canvas work in parallel


      Add "Account Management" game tab to GameTab API (thanks @Encoded)


      Fix NPCChat#getMessage (thanks @Encoded )


      Fix NPCChat#selectOption (thanks @Encoded )


      Fix Banking API after today's update (thanks @Encoded )


      Fix in-game world hopper after today's update (thanks @Encoded )



      Upcoming updates:

      Break handler bug fix


      Improved CLI support


      Much more



      Note: If you are using LG, please restart both the RS client and TRiBot
        • Thanks
        • Like
      • 38 replies
    • This release includes:

      Fix updater bug which was causing a bunch of issues


      TRiBot will no longer require manual hook fixes every time the RS client updates - the updater has been fully patched for objects


      Hooked login fields


      Improved the login bot


      Ability to recognize the banned/locked messages again


      Ability to read the current input for username and password fields


      If the username or password is already entered correctly, it won't be erased


      If only part of the username or password is already entered correctly, it won't be erased. The login bot will fill in what's missing.


      If there are a few invalid characters after a valid substring of your username/password, only (approximately) those invalid characters will be erased. The login bot will then proceed to fill in the missing characters.





      Coming soon:

      Skull icon fix


      Improve screen rate and responsiveness of the RS client (both regular client and LG)


      Much more
        • Thanks
        • Like
      • 33 replies
    • This release includes:

      Fix shift clicking option selecting


      Fix high paint delay settings saving


      Update prayer IDs for the quick select menu


      Remove RS3 support


      Fix hooks



      RS3 Support Removed

      The RS3 client hasn't been updated since our Old-School version of TRiBot was released, as many of you may have noticed. Keeping all of the RS3 code in the client made the client as a whole harder to maintain, larger, slower, and messier. As hardly anyone still uses the RS3 client, and since the RS3 API was hardly functioning, we made the decision to completely remove it from TRiBot.

      For the average user, this means that the client will be smaller, cleaner, and faster. Future updates will also take less work meaning there will be more frequent updates.

      If you were one of the few users still using the RS3 client, we apologize for the inconvenience. No future support for RS3 is planned. There are many other botting clients which has support for RS3, so we recommend finding an alternative if you wish to continue botting on RS3.
        • Thanks
        • Like
      • 25 replies
  • Recently Browsing   0 members

    No registered users viewing this page.

×