Resolved RS3 Visibility

Discussion in 'Developer Support' started by countvidal, Apr 17, 2016.

  1. countvidal

    Joined:
    Nov 17, 2013
    Messages:
    63
    Likes Received:
    1
    So when I do in rs3 spectre:

    Code (Javascript):
    1.  
    2. final static public int INTERFACE_FIRST_TRADE = 335;
    3. final static public int INTERFACE_SECOND_TRADE = 334;
    4. InterfaceComponentQueryResults trade1 = Interfaces.newQuery().containers(INTERFACE_FIRST_TRADE).actions("Accept").visible().results();
    5. InterfaceComponentQueryResults trade2 = Interfaces.newQuery().containers(INTERFACE_SECOND_TRADE).actions("Accept").visible().results();
    6. System.out.println("IS TRADING: first screen length: "+trade1.size()+" second screen length: "+trade2.size());
    Its prints out 0 for both when no screen is up and as soon as the first screen goes up it prints 1. However, when you exit out of any trade screen it it keeps printing 1 even though none of them are visible.

     
  2. Best Answer:
    Post #18 by Cloud, Apr 26, 2016
  3. Arbiter

    Arbiter Mod Automation

    Joined:
    Jul 26, 2013
    Messages:
    2,561
    Likes Received:
    1,087
  4. Cloud

    Joined:
    Jul 28, 2013
    Messages:
    2,585
    Likes Received:
    931
    Okay so do me a favor and take that component that's returning after it shouldn't be visible and call getLayer() on it until it returns null. Print out the toString method of the last non-null value.
     
  5. Aria

    Joined:
    Feb 26, 2015
    Messages:
    643
    Likes Received:
    242
    This also happened to me, the bot is detecting that the Divination conversion UI is visible. It happened about a hour into botting. I already closed RS, so I can't recreate it at the moment.

    [​IMG]
     
  6. countvidal

    Joined:
    Nov 17, 2013
    Messages:
    63
    Likes Received:
    1
    @Cloud

    Code (Text):
    1.  InterfaceComponentQueryResults trade1 = Interfaces.newQuery().containers(INTERFACE_FIRST_TRADE).actions("Accept").visible().results();
    2.         InterfaceComponentQueryResults trade2 = Interfaces.newQuery().containers(INTERFACE_SECOND_TRADE).actions("Accept").visible().results();
    3.         System.out.println("IS TRADING: first trade screen: "+(trade1.first() == null ? "null" : trade1.first().getLayer().toString())+" second trade screen: "+(trade2.first() == null ? "null" : trade2.first().getLayer().toString()));
    4.        
    print out when they have never been up: [​IMG]
    print out when they are up: [​IMG]
    [​IMG]

    print out when none of them are up: [​IMG]
     
  7. Cloud

    Joined:
    Jul 28, 2013
    Messages:
    2,585
    Likes Received:
    931
    hmm some speculation and facts. There are 100 possible root slots that can be used to build off of to calculate an interfaces position. When getLayer() returns null, that's when we know it's time to check the root slot. We determine which one to use based on an index that the component will have. If this is -1, then we know that it's simply not visible. But if the index is resolves to is within the valid range, but the root slot contains either a null value or an invalid rectangle, it could result in getBounds() returning null while isVisible() would return true since isVisible() only checked the index's value.
     
  8. countvidal

    Joined:
    Nov 17, 2013
    Messages:
    63
    Likes Received:
    1
    So are you saying I should use getBounds null checked instead of isVisible?
     
  9. Cloud

    Joined:
    Jul 28, 2013
    Messages:
    2,585
    Likes Received:
    931
    Nah, it was more of an info dump for myself. I'm making some changes that you may see released tomorrow.
     
    countvidal likes this.
  10. countvidal

    Joined:
    Nov 17, 2013
    Messages:
    63
    Likes Received:
    1
    Ok awesome, would appreciate if you reply to this thread when you release the fix.
     
  11. Cloud

    Joined:
    Jul 28, 2013
    Messages:
    2,585
    Likes Received:
    931
    I'll try to remember but I have a bad memory lol
    --- Double Post Merged, Apr 20, 2016, Original Post Date: Apr 19, 2016 ---
    Can you please check now
    @countvidal
     
  12. countvidal

    Joined:
    Nov 17, 2013
    Messages:
    63
    Likes Received:
    1
    Same problem still happening, isVisible still returning true even when they are not visible.
     
  13. Cloud

    Joined:
    Jul 28, 2013
    Messages:
    2,585
    Likes Received:
    931
    is get bounds still returning a non-null value?
     
  14. countvidal

    Joined:
    Nov 17, 2013
    Messages:
    63
    Likes Received:
    1
    No, getBounds() is null correctly when itsnt visible
     
  15. Cloud

    Joined:
    Jul 28, 2013
    Messages:
    2,585
    Likes Received:
    931
    Alright I just did a "behind the scenes" update to V2.0.4.1, can you give that a try?
     
  16. countvidal

    Joined:
    Nov 17, 2013
    Messages:
    63
    Likes Received:
    1
    Cant get past v2.0.4 for some reason. Wont download the new one, even tried doing it off site.

    [​IMG]
     
  17. Cloud

    Joined:
    Jul 28, 2013
    Messages:
    2,585
    Likes Received:
    931
    The last number typically isn't displayed, if you're running runemate through our exe file then it'll ensure you're on the latest. The last number is used for "silent" updates.
     
  18. countvidal

    Joined:
    Nov 17, 2013
    Messages:
    63
    Likes Received:
    1
    Nope, looks like isVisible still returns true even if its not visible.
     
  19. Cloud

    Joined:
    Jul 28, 2013
    Messages:
    2,585
    Likes Received:
    931
    Alright so I'm investigating a few theories at the moment. I'd like you to find a situation where isVisible is returning true when getBounds() is returning null. Then, starting with that component, print the component.toString(), component.getWidth(), component.getHeight(), component.getBounds(), and component.getLayer(). Then, if getLayer() != null, repeat the process of printing those values out.
    --- Double Post Merged, Apr 26, 2016, Original Post Date: Apr 26, 2016 ---
    @countvidal Fixed it ;)
     

Share This Page

Loading...