Results 1 to 7 of 7

Thread: [Project] RS Entities

  1. #1
    Join Date
    Aug 2007
    Location
    Colorado
    Posts
    7,421
    Mentioned
    268 Post(s)
    Quoted
    1442 Post(s)

    Default [Project] RS Entities

    This is a project I've been working on the past couple of days but it's something I've always wanted to do I just didn't have the enthusiasm to begin working on it. What this is, is a color record of an entity (NPCs & Players) in-game to give us accurate information of that same entity, like it's actual bounds, an auto-colored TPA, the base point, and so forth. I've only designed this, so far, to keep track of our own player. It's still primitive and restricted, with so much more work to do, but at its current stage it's more accurate than anything we have.

    I first got the idea when thinking back on RSPS. If any of you are familiar with them the original engines were quite basic when it came to handling Players and NPCs, as there were class files for both to handle them separately. Later on we took a different approach and created a handler for both NPCs & Players; creatively enough the "EntityHandler". It made sense because both NPCs and Players share many same attributes such as drawn model, walking, animation, health... I always liked this so my plan is to reflect the same principle in SRL to handle on-screen moving entities.

    -Possible uses (Player)-
    • Could be used to track our player (at any camera angle) only on-screen and exclude others
    • Based on our player's true on-screen position determine things like our health, animation, even facing direction
    • Find an object/NPC that is truly closest to our player, no more sorting from the middle of the screen
    • Determine the damage (and type of damage) our player is receiving
    • Determine the camera 'pitch' (also would take a bit of work)


    -Possible uses (NPC)-
    • Determine which NPCs are currently in combat
    • Constantly track a specific NPC while it moves (this will take some work though...)
    • Determine if a certain NPC is being attacked (as well as damage type)


    -How it works-

    Quite simple actually, at the beginning of the scrip the user is asked to hover your mouse over your player's in-game top (not your players head, the top) and the color at that position will be recorded, and every similar color within a 15x20 radius will be recorded. Next you do the same for your player's bottom. After those colors are chosen the similar colors will be merged together (top and bottom are merged separately) to give us a 'best color, tolerance, and Sat/Hue mod). Later when the script calls the 'UpdatePlayer' procedure these colors are found, TPAs merged, split (to exclude nearby unwanted similar colors), and the end result is stored as, what I call, a "TEntity" type. This is what I have so far:
    Simba Code:
    Type
    TEntity = record
      Bounds      : TBox;
      BasePnt     : TPoint;
      tCol,tTol,
      bCol,bTol   : Integer;
      FullTPA     : TPointArray;
      tHMod,tSMod,
      bHMod,bSMod : Extended;
    end;

    In the future this can include helmet, top, bottom, and the weapon/shield (if any). I plan to take what I have and eventually write an independent file to handle all of this, but as this is still in development I'm not exactly to that point yet. Here below is some examples of what I'm able to do with it so far:

    -Debugging basic attributes-



    ^ Only the mouse position in the last image is set on the player's "BasePoint".

    -Finding direction of objects to our player-



    ^ Note the box is not the actual fishing spot that was found, that's the area in which the script is searching for the fishing spot. The box is only displayed when a fishing spot is found in any direction of the player; dynamics.

    -Accurately finding our player's health bar-



    ^ As you know when you rotate the camera your player is no longer located, on-screen, in the same position as before. Also over time (and map region change) your player also shifts on-screen position. It's for this reason that determining our player's health, while excluding other health bars, is so difficult. But luckily this entity handler searches for the health bar only according to player's model on-screen and not a static search area. What you see above is where the script is searching for the health bar, at all 4 angles.


    So I guess that's it for now. I'll continue tweaking this bit by bit and making more snippets that will run off of this system. Of course there's always room for errors and inaccuracies and thinking ahead I believe there always will be. But this is a solid start and a very handy tool for scripters. Oh one more thing, I've only designed this for OSRS as that's all I'm focusing on now days. If you have any questions or comments post away and I'll try to answer to the best of my knowledge.

    Current projects:
    [ AeroGuardians (GotR minigame), Motherlode Miner, Blast furnace ]

    "I won't fall in your gravity. Open your eyes,
    you're the Earth and I'm the sky..."


  2. #2
    Join Date
    Dec 2011
    Location
    New York, USA
    Posts
    1,242
    Mentioned
    12 Post(s)
    Quoted
    193 Post(s)

    Default

    here's something i came up with a while ago... dunno if it will be of use to you or not (maybe as a failsafe or something).

    Using this procedure (draws the purple thing on the tip of the bronze full helm):
    Simba Code:
    procedure drawbronzehelm;
    var
      cts, i, x, y: Integer;
      tpa, blootpa: TPointArray;
      atpa: array of array of TPoint;
    begin
      ColorToleranceSpeed(2);
      SetColorSpeed2Modifiers(0.07, 0.91);
      repeat
        FindColorsTolerance(TPA, 6293044, MSX1, MSY1, MSX2, MSY2, 13);
        SplitTPAWrap(TPA, 10, ATPA);
        SMART_DrawDot(false, MiddleTPA(atpa[0]), clred);
      until false;
    end;

    I figured out that every time you log in there's a different circle around your player that the camera revolves around. example below, drawn with the above procedure


    what I realized is that if you grab the point of the center of the purple thing on the bronze helm at 0 degrees, and then 180 degrees, you can figure out where that circle around your player is. because by knowing 2 points of the circle, you can figure out the radius and center of the circle (when your camera is north).

    then whenever you want to search for a mainscreen object and sort from whatever is truely closest to your player regardless of camera angle, you can use RotatePoint to rotate the zero degree point to wherever it becomes on the circle that was created earlier based on rs_getcompassangle

  3. #3
    Join Date
    Jan 2012
    Location
    127.0.0.1
    Posts
    702
    Mentioned
    11 Post(s)
    Quoted
    76 Post(s)

    Default

    Nice Idea @Nebula, one slight issue, to accurately define a circle u would need 3 points not 2.

  4. #4
    Join Date
    Dec 2011
    Location
    New York, USA
    Posts
    1,242
    Mentioned
    12 Post(s)
    Quoted
    193 Post(s)

    Default

    Quote Originally Posted by Enslaved View Post
    Nice Idea @Nebula, one slight issue, to accurately define a circle u would need 3 points not 2.
    Well yeah you would need 3 normally, but if the two points you have are 180 degrees away from eachother, then the midpoint between the 2 points is the center of the circle, and half the distance between the 2 points is the radius

  5. #5
    Join Date
    Sep 2012
    Location
    Netherlands
    Posts
    2,752
    Mentioned
    193 Post(s)
    Quoted
    1468 Post(s)

    Default

    interesting!

  6. #6
    Join Date
    Jan 2012
    Location
    127.0.0.1
    Posts
    702
    Mentioned
    11 Post(s)
    Quoted
    76 Post(s)

    Default

    Quote Originally Posted by Nebula View Post
    Well yeah you would need 3 normally, but if the two points you have are 180 degrees away from eachother, then the midpoint between the 2 points is the center of the circle, and half the distance between the 2 points is the radius
    The assumption would be accurate if not for the fact that turning 180 degrees exactly is extremely unreliable in OSRS and henceforth the assumption that it will always intersect at the centre point is void. But as I sad, good idea.

  7. #7
    Join Date
    Apr 2007
    Posts
    373
    Mentioned
    2 Post(s)
    Quoted
    24 Post(s)

    Default

    Anyone still working on this?
    ~Fre

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
  •