Results 1 to 9 of 9

Thread: Color detection issues due to movement for jade vine chopper.

  1. #1
    Join Date
    Mar 2014
    Posts
    205
    Mentioned
    4 Post(s)
    Quoted
    116 Post(s)

    Default Color detection issues due to movement for jade vine chopper.

    So I'm writing a Jade Vine firemaker that uses the new Seren curse (oh my is the xp ever great), but I'm running into an issue with detecting the vines. Since the player moves, I have to be able to detect the vine, click on it, move to it and then detect the vine again. I don't want to just have the mouse move in an area around my character to check each cardinal direction, so I decided to do a TPA search for the "chopped" colors, as they differ from the original colors. Other than false positives (which I can get rid of with tweaking of the TPA and area to search and stuff, I hope), the only issue I'm having is that it will often detect a previously chopped vine as the vine I'm currently trying to chop. To deal with this, I figured I could do some fancy math based on the middle of the screen and where I clicked in the first place to filter out any TPointArrays that are not in that general direction from the main ATPA (so a click in the top right of the screen would filter points that are in the bottom right, bottom left and top left).

    So now that wall of text is over, I have two questions:

    Does this solution make sense? I can't think of anything else, and it seems to make sense to me, but I could just be insane.

    Does anyone have any other suggestions or insight into how to solve this issue? Line count is an issue (this is for my entry to the contest), but I have 150+ to work with right now and the core of the code is complete, so as long as it isn't huge it isn't a big deal.

  2. #2
    Join Date
    Dec 2011
    Location
    Toronto, Ontario
    Posts
    6,424
    Mentioned
    84 Post(s)
    Quoted
    863 Post(s)

    Default

    I'm curious, how are you distinguishing from the Curly roots and regular roots?

  3. #3
    Join Date
    Mar 2014
    Posts
    205
    Mentioned
    4 Post(s)
    Quoted
    116 Post(s)

    Default

    Quote Originally Posted by Sin View Post
    I'm curious, how are you distinguishing from the Curly roots and regular roots?
    In what way? I wasn't aware there was a difference, unless you mean the roots you can chop and the roots at the sides of the cave, in which case I'm just relying on proximity currently.

    Edit:

    Oh I see. Didn't know there was a difference. Might look into it.

  4. #4
    Join Date
    Oct 2013
    Location
    East Coast USA
    Posts
    770
    Mentioned
    61 Post(s)
    Quoted
    364 Post(s)

    Default

    Please post a picture.

  5. #5
    Join Date
    Mar 2014
    Posts
    205
    Mentioned
    4 Post(s)
    Quoted
    116 Post(s)

    Default

    http://puu.sh/jRi9Z/108c2e2df8.jpg

    Here's a sample picture of the cave. Chopped vines are a darker green (similar to the vines around the edge of the cave) than the ones on the screen there. The issue is that if one of the vines is the "chopped" color and I go to chop a vine close enough to the "chopped" vine, it picks up the "chopped" vine as the vine I'm trying to chop because the vine is already the color I'm looking for and is within the search area. I need to find some way to always (or at least mostly reliably) pinpoint the vine I'm trying to chop.

  6. #6
    Join Date
    Oct 2013
    Location
    East Coast USA
    Posts
    770
    Mentioned
    61 Post(s)
    Quoted
    364 Post(s)

    Default

    I think I get the problem statement now

    When you click it the first time it's bright green. Then, I assume, you run over to it and whack it at least once before it turns to the darker green?

    So the color changes about the same time as the pixel shift is settling from running around?

  7. #7
    Join Date
    Mar 2014
    Posts
    205
    Mentioned
    4 Post(s)
    Quoted
    116 Post(s)

    Default

    Quote Originally Posted by bonsai View Post
    I think I get the problem statement now

    When you click it the first time it's bright green. Then, I assume, you run over to it and whack it at least once before it turns to the darker green?

    So the color changes about the same time as the pixel shift is settling from running around?
    Yes. I use minimap.isPlayerMoving() to decide when I'm done moving to the vine and can start searching for the chopped color.

    Edit:

    I should clarify that it isn't necessarily the same time, it's just at some point within the next 5 seconds (typically; I've never seen it take longer) after you stop moving that you start chopping.

  8. #8
    Join Date
    Dec 2011
    Location
    East Coast, USA
    Posts
    4,231
    Mentioned
    112 Post(s)
    Quoted
    1869 Post(s)

    Default

    Quote Originally Posted by adc View Post
    Yes. I use minimap.isPlayerMoving() to decide when I'm done moving to the vine and can start searching for the chopped color.

    Edit:

    I should clarify that it isn't necessarily the same time, it's just at some point within the next 5 seconds (typically; I've never seen it take longer) after you stop moving that you start chopping.
    If .waitPlayerMoving() doesn't cut it, try this function on for size:

    Simba Code:
    procedure TRSMinimap.waitFlagExists(timeout:integer); //waits up to timeout for the flag to be gone
    var
      t:TTimeMarker;
    begin
      if (not isLoggedIn()) then
       exit();

      if (not self.isFlagPresent()) then
       begin
         writeLn('Flag not present, unable to wait while flag exists');
         exit();
       end;

      t.start();

      while (t.getTime() < timeout) do
       begin
         writeLn('Waiting while the flag exists');
         wait(randomRange(250, 500));

         if (not self.isFlagPresent()) then
          exit();
       end;
    end;

    The flag always disappears slightly before the player stops moving, so this might be what you need.

    (disclaimer: I don't fully understand the issue)
    Last edited by KeepBotting; 08-30-2015 at 04:35 PM.
    GitLab projects | Simba 1.4 | Find me on IRC or Discord | ScapeRune scripts | Come play bot ScapeRune!

    <BenLand100> we're just in the transitional phase where society reclassifies guns as Badâ„¢ before everyone gets laser pistols

  9. #9
    Join Date
    Mar 2014
    Posts
    205
    Mentioned
    4 Post(s)
    Quoted
    116 Post(s)

    Default

    Quote Originally Posted by KeepBotting View Post
    If .waitPlayerMoving() doesn't cut it, try this function on for size:

    Simba Code:
    procedure TRSMinimap.waitFlagExists(timeout:integer); //waits up to timeout for the flag to be gone
    var
      t:TTimeMarker;
    begin
      if (not isLoggedIn()) then
       exit();

      if (not self.isFlagPresent()) then
       begin
         writeLn('Flag not present, unable to wait while flag exists');
         exit();
       end;

      t.start();

      while (t.getTime() < timeout) do
       begin
         writeLn('Waiting while the flag exists');
         wait(randomRange(250, 500));

         if (not self.isFlagPresent()) then
          exit();
       end;
    end;

    The flag always disappears slightly before the player stops moving, so this might be what you need.

    (disclaimer: I don't fully understand the issue)
    I don't think there even is a flag at all, but regardless; isPlayerMoving isn't the issue. Thanks for the suggestion either way :P.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •