Results 1 to 22 of 22

Thread: Walking..

  1. #1
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default Walking..

    Ok so for some time now I've been working on walking with @Kasi;. We came up with quite a lot of ideas on how to approach it. One was to intercept socket events but that required decrypting the EOC client and injecting into it to get the right fields. Another was to get the Camera Position so that it gives the "Tile" the user is on. This tile is the exact equivalent to that of reflection/injection tiles. However, we do not see the camera position ever being passed to the graphics card directly. Our next idea was to create something like SPS but with 100% accuracy and this one sorta worked out. Well it did work out but we want to know if there are better/easier ways for any of you mathematicians out there.

    Thus our first task was to write a runescape emulator in OpenGL/C++ to emulate how runescape loads the map in both RS2 and RS3. What we came up with was quite weird and tricky at the same time but it worked. The emulator's source is located at: http://www.mediafire.com/download/82...y/Emulator.zip

    Our first code and theories are as follows:


    Non-Rotated Maps:
    Let us say that this is our Map information retrieved from the game:

    C++ Code:
    ptr_glMultiTexCoord2fARB(GL_TEXTURE0, 0, 1);
    ptr_glMultiTexCoord2fARB(GL_TEXTURE1, -240.11853, 356.74777);
    glVertex2f(309.88147, -144.74777);  //Top Left

    ptr_glMultiTexCoord2fARB(GL_TEXTURE0, 0, 0);
    ptr_glMultiTexCoord2fARB(GL_TEXTURE1, -244.00943, -177.2381);
    glVertex2f(305.99057, 389.2381); //Bottom Left

    ptr_glMultiTexCoord2fARB(GL_TEXTURE0, 1, 0);
    ptr_glMultiTexCoord2fARB(GL_TEXTURE1, 289.97644, -181.129);
    glVertex2f(839.97644, 393.129); //Bottom Right

    ptr_glMultiTexCoord2fARB(GL_TEXTURE0, 1, 1);
    ptr_glMultiTexCoord2fARB(GL_TEXTURE1, 293.86731, 352.85684);
    glVertex2f(843.86731, -140.85684);  //Top Right

    OpenGL coordinates are as follows:



    So every glMultiTexCoord2fARB that has: GL_TEXTURE1 as a parameter represents the Minimap circle and the coordinates represent its position relative to the MAP.
    MMCircle:

    Every glVertex2f is Map coordinates and represents where the map is drawn within the current Window.

    So in the above, it looks like:


    Where the MMCircle's bottom left is at: 550, 212 and the center is at 627, 135.

    Now how did we figure that out? Well see the numbers are hidden. The math goes like this:

    Compass Width = 154.
    Compass Height = 154.

    Thus:
    839.97644 + 240.11853 = 550;
    550 + (154/2) = 627. Since the compass is relative to whatever map coordinate is at the top left of the screen.

    -144.74777 + 356.74777 = 212;
    212 - 77 = 135. Since the compass is relative to the top left map coordinate and Y increases downwards in window coordinates.

    This is true for all coordinates above. No matter which pair you choose, you will always get 627, 135 if the quadrants are taken into account as well. It is also true no matter which way the map is turned. The minimap circle is never rotated. It is simply moved up and down relative to the MAP! And the Map is relative to the Window.

    Each map is ALWAYS 512x512. In the above, you will notice that the map is stretched but still a square/rhombus. It's new dimensions is calculated using the distance formula like so:

    C++ Code:
    Width = std::sqrt(std::pow(TopRight.X - TopLeft.X, 2) + std::pow(TopRight.Y - TopLeft.Y, 2));
    Height = std::sqrt(std::pow(TopRight.X - BottomRight.X, 2) + std::pow(TopRight.Y - BottomRight.Y, 2));

    To find out the ratio of the stretched map to the regular unstretched, unrotated map, we do:

    Ratio-X = Width / 512;
    Ratio-Y = Height / 512;

    We then get:
    Ratio-X = 1.042969;
    Ratio-Y = 1.042969;

    Knowing the compass is relative to the Map, we can thus find the player's location within the current Map using the following formula assuming that the map is not rotated too much:

    Player-X = (MMX / Ratio) + (154 / 2); + because X increases going right in window coordinates.
    Player-Y = (MMY / Ratio) - (154 / 2); - because Y decreases going up in window coordinates.

    Where MMX = 240 and MMY = 356 as shown above. The results are thus:


    That is our EXACT player position. The emulator figures that out and draws it to the screen. As you can see the map is only slightly rotated and it is only part of the map. The top part is cut off. I also had to stretch the window to show the right side because the Original Window size is 0, 0, 765, 553. And we know that some of those coords definitely do NOT fit into the window.
    This was our first theory for calculating position and it worked FLAWLESSLY!


    Rotated Maps:




    Our first theory worked perfectly fine! Until one day.. we decided to rotate the map and the algorithm broke :l Why did it break? Well because the MMCircle is always relative to whatever the top-left corner of the map is. If the map is rotated 180 degrees, the bottom right of the map will be drawn at the top left and coordinates would be upside down. Inverting it doesn't help either. I tried all mathematical formulas. Until day two, Kasi figured something out with his magical theoretical brain. Take notes of the coordinates in the map above using our first theory.

    He said.. Why don't we try and rotate the map back to 0, 0 or as straight as it can get. So we tried all possible formulas we knew for rotating but we all know rotating an image is just crazy and ridiculously inaccurate. At first we used these formulas for distance and rotation:

    C++ Code:
    float Distance(Point P, Point Q)
    {
        return std::sqrt(std::pow(Q.X - P.X, 2) + std::pow(Q.Y - P.Y, 2));
    }

    Point RotatePoint(Point P, float cx, float cy, float AngleRadians)
    {
        P.X = cos(AngleRadians) * (P.X-cx) - sin(AngleRadians) * (P.Y-cy) + cx;
        P.Y = sin(AngleRadians) * (P.X-cx) + cos(AngleRadians) * (P.Y-cy) + cy;
        return P;
    }

    And what happened was the map shrunk as it rotated. Sometimes it flipped and sometimes it got large. Very weird since we rotated it around its center-point.

    Then somehow he came up with the following algorithm.. You'll notice that the algorithm still uses the 550, 212 and 627, 135 relativity numbers. It also uses the Map Ratio and thus 77 is what we also call a magic number. For us, these 5 numbers are magical. They don't even change in RS3 :l

    C++ Code:
    float Rot = (360 - 146.95) * ((atan(1) * 4) / 180);  //Knowing that a map is rotated at 146.95 degrees..

    glColor3f(1, 1, 1);
    ptr_glMultiTexCoord2fARB(GL_TEXTURE0, 0, 1);
    ptr_glMultiTexCoord2fARB(GL_TEXTURE1, 317.67151, -52.51767);
    Points[0] =  RotatePoint({867.67151, 264.51767}, 627, 135, Rot);
    glVertex2f(Points[0].X, Points[0].Y);

    ptr_glMultiTexCoord2fARB(GL_TEXTURE0, 0, 0);
    ptr_glMultiTexCoord2fARB(GL_TEXTURE1, 36.11798, 379.89832);
    Points[1] =  RotatePoint({586.11798, -167.89832}, 627, 135, Rot);
    glVertex2f(Points[1].X, Points[1].Y);


    ptr_glMultiTexCoord2fARB(GL_TEXTURE0, 1, 0);
    ptr_glMultiTexCoord2fARB(GL_TEXTURE1, -396.29797, 98.344757);
    Points[2] =  RotatePoint({153.70203, 113.344757}, 627, 135, Rot);
    glVertex2f(Points[2].X, Points[2].Y);

    ptr_glMultiTexCoord2fARB(GL_TEXTURE0, 1, 1);
    ptr_glMultiTexCoord2fARB(GL_TEXTURE1, -114.74445, -334.07123);
    Points[3] =  RotatePoint({435.25555, 546.07123}, 627, 135, Rot);
    glVertex2f(Points[3].X, Points[3].Y);
    glEnd();

    for (int I = 0; I < 4; I++)
    Dists[I] = Distance({0, 0}, Points[I]);

    float Smallest = Dists[0];
    int Element = 0;
    for (int I = 0; I < 4; I++)
    {
        if (Smallest > Dists[I])
        {
            Smallest = Dists[I];
            Element = I;
        }
    }


    And the above Un-rotates the map. Using our ratio theory being applied to the now un-rotated map, calculates all our player coordinates perfectly accurate just like the before. However, the above does NOT work for maps that are aligned straight already. In other words, applying a rotation of 0//360 with the above algorithm, it does NOT work.

    After running his algorithm on the map, it turned out like:



    Now notice the difference in the two sets of coordinates? The first set which you were to take note of; and this set which is 100% accurate and exactly where we stand. They are completely different! If you notice, the emulator does not SEE the difference at all. All it knows is that the mini-map circle is X, Y relative to the Map which is relative to the screen. Thus our position within the map is still the same. However, the formula generated the wrong coordinates. The second formula worked and generated the right coordinates.

    In other words, when mine works, his does not. When mine fails, his works. Mine seems to work for anything between 270 < 0 < 90.
    His works for anything between 45 < 180 < 315.

    I know runescape 3 does not have a minimap circle. It's a rectangle/square but it makes no difference. The same formula will apply since the MMCircle is also a square with a transparent circle inside.


    What we want from you:
    So we want to know if you guys have any other ideas for calculating player position given the above info or if we really have to implement both algorithms given the compass angle. Another problem we have is making these into global coordinates not local. We were most likely going to load a bunch of maps just like SPS does and figure out our location within the local maps. Figure out which local map we're standing in within the global(world) map and that would be our global position but I'm not so sure :S
    Last edited by Brandon; 07-14-2013 at 06:46 AM.
    I am Ggzz..
    Hackintosher

  2. #2
    Join Date
    Dec 2007
    Posts
    2,112
    Mentioned
    71 Post(s)
    Quoted
    580 Post(s)

    Default

    @riwu;

    might you be able to help out?

  3. #3
    Join Date
    Oct 2006
    Location
    Netherlands
    Posts
    3,285
    Mentioned
    105 Post(s)
    Quoted
    494 Post(s)

    Default

    /thread
    Working on: Tithe Farmer

  4. #4
    Join Date
    Feb 2012
    Location
    DON'T PM ME ASKING FOR STUFF
    Posts
    2,170
    Mentioned
    38 Post(s)
    Quoted
    423 Post(s)

  5. #5
    Join Date
    Oct 2006
    Location
    Netherlands
    Posts
    3,285
    Mentioned
    105 Post(s)
    Quoted
    494 Post(s)

    Default

    Quote Originally Posted by xtrapsp View Post
    This is looking VERY interesting
    But I already solved it
    Working on: Tithe Farmer

  6. #6
    Join Date
    Feb 2012
    Location
    DON'T PM ME ASKING FOR STUFF
    Posts
    2,170
    Mentioned
    38 Post(s)
    Quoted
    423 Post(s)

    Default

    Quote Originally Posted by masterBB View Post
    But I already solved it
    Yea, but the whole concept looks interesting

  7. #7
    Join Date
    Dec 2011
    Location
    The Netherlands
    Posts
    1,631
    Mentioned
    47 Post(s)
    Quoted
    254 Post(s)

    Default

    Quote Originally Posted by masterBB View Post
    But I already solved it
    So.. how did you solve it?

    What I did with TRiBot OpenGL was:
    API had a method to get your relative position on the 512x512 map.
    Then based on that you can cut out the minimap square from that 512x512 map.

    Can't you get the relative location based on the shaders or something? There is no need to use these math calculations if you can get the relative position, cut out a square from the 512x512 map. Then you have the non rotated map.

    Worked well for me. I don't know how the API calculated the relative position but I think you talked about that before. Should be easy enough for the other parts.

    Script source code available here: Github

  8. #8
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by J J View Post
    So.. how did you solve it?

    What I did with TRiBot OpenGL was:
    API had a method to get your relative position on the 512x512 map.
    Then based on that you can cut out the minimap square from that 512x512 map.

    Can't you get the relative location based on the shaders or something? There is no need to use these math calculations if you can get the relative position, cut out a square from the 512x512 map. Then you have the non rotated map.

    Worked well for me. I don't know how the API calculated the relative position but I think you talked about that before. Should be easy enough for the other parts.

    I thought Tribot's walking was SPS like? Then he started using injection. I'd like to see what you're talking about with cutting out the MM-Square though. And how would that work in RS3..

    I couldn't find it in the shaders.

    What do you mean get relative position without the calculations. You still have to do some sort of calculation in the end. Only way to avoid this is to get the Camera position and as far as I can tell, in RS2 that isn't passed to the graphics card in any way

    Master-BB came up with this cross product formula.
    Last edited by Brandon; 07-15-2013 at 12:10 PM.
    I am Ggzz..
    Hackintosher

  9. #9
    Join Date
    Dec 2011
    Location
    The Netherlands
    Posts
    1,631
    Mentioned
    47 Post(s)
    Quoted
    254 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    I thought Tribot's walking was SPS like? Then he started using injection. I'd like to see what you're talking about with cutting out the MM-Square though. And how would that work in RS3..

    I couldn't find it in the shaders.

    What do you mean get relative position without the calculations. You still have to do some sort of calculation in the end. Only way to avoid this is to get the Camera position and as far as I can tell, in RS2 that isn't passed to the graphics card in any way

    Master-BB came up with this cross product formula.
    I based my TRiBot GOP script fully around OpenGL, no injection methods needed at all: https://github.com/JJdeGroot/RuneSca.../RS2/GOP%20VIP

    Walking methods: https://github.com/JJdeGroot/RuneSca...s/Walking.java

    From line 216 you will find some methods I used for the actual walking.
    TPS.getRelativePosition() -> Returns your position on the 512x512 image, based from the middle. So 0, 0 you would actually be on coords 256, 256.

    I have no idea how he calculates the relative position, you could try asking him. He has pretty much abandoned RS2/OpenGL. But you mentioned "So every glMultiTexCoord2fARB that has: GL_TEXTURE1 as a parameter represents the Minimap circle and the coordinates represent its position relative to the MAP."
    That is the same as I mean. You can get that Point right?

    You can simply use that Point to cut out the minimap from the big map.


    This big map was never rotated and based on your first post I assume it does actually rotate? You could get an int[][] containing the 512x512 map RGB data on TRiBot. I have no idea how he pulled it off.

    EDIT: Have you tried the RS3 New Interface System yet? You can expand the minimap and see exactly how the map is rotated. It's the same way in RS2.
    Last edited by J J; 07-15-2013 at 08:22 PM.

    Script source code available here: Github

  10. #10
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Looks like the same idea I had. The first post already gets the minimap unrotated. And yeah I also have the pixels for it as well. However, that simply was not enough to get the player position. I'd rather implement one algorithm to get it instead of 2. Yeah I tried the RS3 interface. The algorithms we currently have works in RS3 and without the need to expand the minimap.

    That position in your un-rotated cut out looks off a bit.. however there is no need to even get a map cutout. Not sure why to get a cutout. We're getting player position directly from the game and it's not off by any amount greater than 1-2 pixels using Master-BB's algo. Using the original algorithm, it's accurate down to the very last decimal place.

    Overall, both Tribot walking and this one seem to be the same idea. The orb of occulus helped us out to find Map position, compass pitch, yaw, roll, etc.
    Last edited by Brandon; 07-15-2013 at 09:07 PM.
    I am Ggzz..
    Hackintosher

  11. #11
    Join Date
    Aug 2008
    Location
    London, UK
    Posts
    456
    Mentioned
    0 Post(s)
    Quoted
    1 Post(s)

    Default

    I'm not sure if I understand why it's so complicated. I was under the impression that all that needs doing is: http://ideone.com/e9QmEf

    This just takes the top left coordinate and rotates it by the compass angle, which can be calculated with the dot product of an edge and (0, 0).

    This gives you the relative pixel coordinate.

    From there you can just use an SPS approach, another option would be a CRC table.
    Last edited by ReadySteadyGo; 07-16-2013 at 10:05 AM.

  12. #12
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by ReadySteadyGo View Post
    I'm not sure if I understand why it's so complicated. I was under the impression that all that needs doing is: http://ideone.com/e9QmEf

    This just takes the top left coordinate and rotates it by the compass angle, which can be calculated with the dot product of an edge and (0, 0).

    This gives you the relative pixel coordinate.

    From there you can just use an SPS approach, another option would be a CRC table.

    Because:
    It just isn't that simple. I also tried changing the angle on yours. Still doesn't work but it came close at -10 degrees. However, the map is not at -10 degrees at all. 317 is way off. Dividing by the map ratio brings your coords closer but still not as accurate as the 3 formulas we have: Mine, Kasi's, Master-BB's. The first two are on OP and they work but is complexed. Master-BB gave me a solution that uses cross-product and works. We want to go with his solution as it works at all angles and for all maps. If you have ideas though, I'd still love/want to see it.


    The CRC32 MIGHT work. There is a huge chance it doesn't because the map chunks it loads are different almost every time. They are always different by a set of pixels. For example, running from barbarian village to varrock loads Chunk A. Running from varrock to Barbarian village loads Chunk B. When running back from Barb to Varrock, it'll then load a different part of Chunk A.. aka Chunk C. <--- Rare though. Usually it is just Chunk A and Chunk B and I can live with that but when C comes in, it gets annoying.

    I'll try the CRC32 or anything else before I take an SPS approach. I'll exhaust all options first. The SPS approach is easy to implement but it's all about exploring the client and options.
    Last edited by Brandon; 07-16-2013 at 04:34 PM.
    I am Ggzz..
    Hackintosher

  13. #13
    Join Date
    Aug 2008
    Location
    London, UK
    Posts
    456
    Mentioned
    0 Post(s)
    Quoted
    1 Post(s)

    Default

    Read yours and Master-BB's a bit more. If Master-BB's works then go with that.

    Updated my solution: http://ideone.com/2DJGeG

    Just input the top-left and bottom-left vertices. Bear in mind that I've not tried your emulator or anything, but I think the maths is solid. If you want it commented, let me know.

    Ah, I didn't realise that was the case about the CRC, I can't currently think of another option but the SPS approach.
    Last edited by ReadySteadyGo; 07-16-2013 at 08:28 PM.

  14. #14
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    I tried the hashcode. CRC32, 16, etc.. None worked so it's SPS style with 100% accuracy. Also tried your Algo for local pos @ReadySteadyGo. It's still a no go. Doesn't work lol.

    @masterBB; Just got around to implementing your algorithm:




    Works in RS3 except when the user moves or resizes the map. Gotta find MM-Center too :l Alot easier to grab map info from RS3 but annoying since the same code for RS2 doesn't work.

    Works sorta though. Meh. It can be adjusted.




    Z = compass angle, X = camera height, Y = roll. These are all the euler angles. X-Pos, Y-Pos, Z-Pos is local position of the camera.
    Map-Pos is the player's local X, Y. Map-Matrix is: "Top-Left, Bottom-Left, Top-Right, Bottom-Right" coordinates of the map. Used to calculate local position regardless of angle where MM-Center is 627, 135. Master-BB and Kasi had a big part in these numbers.

    These are local positions. To convert them to global, you find the localmap within the global/world map and add your position to it..
    Still gotta fix the RS3 crap.
    Last edited by Brandon; 07-20-2013 at 11:01 AM.
    I am Ggzz..
    Hackintosher

  15. #15
    Join Date
    Sep 2010
    Posts
    5,762
    Mentioned
    136 Post(s)
    Quoted
    2739 Post(s)

    Default

    @Brandon Could this find which minimap you are on based on all of the RS minimaps?

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

    Default

    I wish i could understand this...
    Also: this cant be done on osr right?

  17. #17
    Join Date
    Mar 2013
    Location
    Shaolin
    Posts
    863
    Mentioned
    24 Post(s)
    Quoted
    519 Post(s)

    Default

    Won't the RS3 update sort of mess this up because the map moves as you pass walls so the camera doesn't clip through them? Your minimap will be moving without user consent, so if you are trying to get the player's area, you won't get an accurate detection because the camera is in the wrong spot?
    I'm not totally sure I understand what's going on, but I think I have a small idea. Looks intense though so props to figuring something like this out.
    You have permission to steal anything I've ever made...

  18. #18
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by Joseph D View Post
    Won't the RS3 update sort of mess this up because the map moves as you pass walls so the camera doesn't clip through them? Your minimap will be moving without user consent, so if you are trying to get the player's area, you won't get an accurate detection because the camera is in the wrong spot?
    I'm not totally sure I understand what's going on, but I think I have a small idea. Looks intense though so props to figuring something like this out.

    No clue what you mean :S It already works partially. I already took into consideration that the map moves with the player. So does the RS2 map it's just you don't see it. And I know it dynamically loads the map but this is interception so it already sees it before you do and it knows where it will draw before you do. So that isn't the problem.
    I am Ggzz..
    Hackintosher

  19. #19
    Join Date
    Feb 2012
    Location
    DON'T PM ME ASKING FOR STUFF
    Posts
    2,170
    Mentioned
    38 Post(s)
    Quoted
    423 Post(s)

    Default

    Quote Originally Posted by Officer Barbrady View Post
    @Brandon Could this find which minimap you are on based on all of the RS minimaps?
    That would be a bloody long check as the maps are so big.

    You would have to scroll through all of the images in Runescape_Other and Runescape_Surface, it's possible, but not ethical

  20. #20
    Join Date
    Oct 2006
    Location
    Netherlands
    Posts
    3,285
    Mentioned
    105 Post(s)
    Quoted
    494 Post(s)

    Default

    Quote Originally Posted by Officer Barbrady View Post
    @Brandon Could this find which minimap you are on based on all of the RS minimaps?
    Might actually work. There probably is a better solution. But what if we had an xml file with the average color of each map and the average deviation of the colors to that color. Then to find your map between the others you can simply filter them out on that.

    e: On a second less stupid thought. Just comparing all world maps with an simple bitmapSame function would be at least as fast :P
    Working on: Tithe Farmer

  21. #21
    Join Date
    Sep 2010
    Posts
    5,762
    Mentioned
    136 Post(s)
    Quoted
    2739 Post(s)

    Default

    Quote Originally Posted by masterBB View Post
    Might actually work. There probably is a better solution. But what if we had an xml file with the average color of each map and the average deviation of the colors to that color. Then to find your map between the others you can simply filter them out on that.

    e: On a second less stupid thought. Just comparing all world maps with an simple bitmapSame function would be at least as fast :P
    Yea as xtrapsp was saying I guess it could be (long?) (how long?) but world position could work something like (mapID, currentmapx, currentmapy)

  22. #22
    Join Date
    Dec 2007
    Posts
    2,112
    Mentioned
    71 Post(s)
    Quoted
    580 Post(s)

    Default

    Jagex doesn't always load the same exact chunks

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
  •