PWI GUI Mapper

[amineurin]

So my question is... Why are people not using this? Someone knows a reason that I don't?
To me it seems almost ideal, because it doesn't rely on actionstructs which are a ***** to deal with and have loads of offsets to maintain.
Secondly, you don't have the problem of the Z co-ordinate (Yes, Interest07 - Z ) which I don't think anyone has found a way to define accurately enough for purely packet based movement (although I know some people are still striving for purely packet based movement with the goal of making a clientless bot).

what exactly is the Z problem ?
i personal use action struct to move/fly and it works fine with Z cords.

calling the ingame AutoRoute looks better, since u say no offset search after updates.

but, ingame function is not so good like actionstruct.
as example in my catshop bot i show cords like 651, 627
wen i use AutoRoute to go there, i had to search the shop since its not really direct and some meters are around to look.

if i use the cords i get ingame (before i rounded them) and use action struct, i stand in the middle of the shop and had no searching for it.
autoroute cant handle .687843 inputs

but im sure, for some other things it can be good to use.

[dumbfck]

Originally Posted by amineurin

what exactly is the Z problem ?
i personal use action struct to move/fly and it works fine with Z cords.

Yeah it's fine with action structs, I meant that some people had trouble with Z coord for packet based movement because the client is very fussy about them. Looks like Interest has nailed that though lol.

Originally Posted by amineurin

but, ingame function is not so good like actionstruct.
as example in my catshop bot i show cords like 651, 627
wen i use AutoRoute to go there, i had to search the shop since its not really direct and some meters are around to look.

if i use the cords i get ingame (before i rounded them) and use action struct, i stand in the middle of the shop and had no searching for it.
autoroute cant handle .687843 inputs

The actual integers you pass to the autoroute function are about 10x the resolution of 'viewable' in-game coords, that is, the whole world map is effectively an 11,000 x 8,000 grid (roughly ). A difference of 1 equates to roughly one step when running. That should be enough resolution to get close enough to anything really, whether it be a catshop or a resource or whatever.

Pros:

• Very simple function to inject
• Only requires x and y parameters. No need to worry about z
• Client handles everything else - No need to worry about corrupting registers (the old... 'Actionstructs break after a while' issue)
• Do your own calculations (distance etc) with integer maths - Much faster than floating point maths.

Cons:

• The little "Auto route" box pops up every time you move.
• Very slightly less resolution than using floats with actionstructs
• The destination marker on the mini-map (top right corner) and on the main 'big map' just point somewhere random, way off the map. I expect I can probably find the function to correct that though (actually, thinking about it, is that what BuBucekTop was asking for? I think I still misunderstood the original question lol)
• Can't be used to adjust height in air or water (although I suppose there might be a z coord in the call - I'll have to check later as I only tested this on the ground)

[BuBucekTop]

Originally Posted by dumbfck

Ok... I've found a function in game that I'm able to inject which will allow me to autoroute. To use it is literally as simple as

AutoRouteTo(x, y)

The thing is... I can't imagine that nobody else has found it...

You're wrong. I've found this function a couple of years ago (actually before discovering moving through actionstruct)
For current version PW-RU it looks like :

Const                 
  PW_BASE_ADDRESS   = $00A571E0;
  PW_DYNAMIC_BASE_OFFSET = $001c;       // [base] + 1c = CECGameRun
  PW_ROLE_BASE_OFFSET = $0034;          // [base] + 1c + 34

  AutoRouteAddr     = $00478ED0; //$004551D0; //$00452B60;

this is inject function :

procedure AutoRouteCall(cmd : Pointer); stdcall;
var
  addr: Pointer;
begin
  addr := Pointer(AutoRouteAddr);
  asm
    pushad
    mov eax, dword ptr [PW_BASE_ADDRESS]
    mov eax, dword ptr [eax + PW_DYNAMIC_BASE_OFFSET]
    mov ecx, dword ptr [eax + PW_ROLE_BASE_OFFSET]
    push cmd
    call addr
    popad
  end;
end;

And this is the only entry point for controlling auto-routing.

This is how to navigate to point (x, y) :

procedure AutoRouteStart(x, y : integer);
var
  buf : array[0..6] of integer;
begin
  buf[0] := 330;
  buf[1] := 0;
  buf[2] := 0;
  buf[3] := 0; // Команда на взлёт
  buf[4] := x;
  buf[5] := y;
  buf[6] := 0;
  InjectFunc(@AutoRouteCall, @buf, SizeOf(buf));
end;

This is how to change altitude :

procedure AutoRouteAltitude(z : integer);
var
  buf : array[0..6] of integer;
begin
  buf[0] := 330;
  buf[1] := 0;
  buf[2] := 0;
  buf[3] := 1; // Команда сменить высоту
  buf[4] := z;
  buf[5] := 0; // Хз что, но может быть 0 или 1
  buf[6] := 0;
  InjectFunc(@AutoRouteCall, @buf, SizeOf(buf));
end;

And this is how to stop :

procedure AutoRouteStop();
var
  buf : array[0..6] of integer;
begin
  buf[0] := 330;
  buf[1] := 0;
  buf[2] := 0;
  buf[3] := 2; // Команда стоп
  buf[4] := 0; buf[5] := 0; buf[6] := 0;
  InjectFunc(@AutoRouteCall, @buf, SizeOf(buf));
end;

Finally you can use it like this :

AutoRouteStart(1350, 345);
AutoRouteAltitude(75);

The only thing I can't figure out for past two years - how the f*ck can I control destination point coordinates on big map and mini-map.
That was an original question to you.

[dumbfck]

Ahh yes, that's the exact same function I've found, with the same parameters too and for the 'stop autoroute' stuff.
Thanks for the info on altitude though, I hadn't figured that part out yet.

By the way, you can get the function address from [[[playerBase]+0]+0x50]

I understand your question now. I'll take a look when I get home later.

[amineurin]

can this finally used with sendpackets too ?

wen i use actionstruct to move, the pointer also is not on the right place of the map.
so maybe thats a function itself, called after moving or before.

im not familiar with any tool to look in memory, but maybe if any of you calling the ingame autoroute with a break...you can see what is all calling then ?
but im sure u did this before

[dumbfck]

Originally Posted by amineurin

can this finally used with sendpackets too ?

This isn't related to packet based movement. It's sort of the call just before the actionstruct stuff, i.e., it just tells the client to move your char to x,y and the client handles all the action struct stuff.

Originally Posted by amineurin

wen i use actionstruct to move, the pointer also is not on the right place of the map.
so maybe thats a function itself, called after moving or before.

im not familiar with any tool to look in memory, but maybe if any of you calling the ingame autoroute with a break...you can see what is all calling then ?
but im sure u did this before

Yeah the problem is there are hundreds of functions that get called lol. You can't see which one actually controls graphical stuff because the frame is constructed in the background, then when the graphics / display frame timer ticks (or whatever it's called) the whole image is drawn to the screen. Probably the only ways to find it are:
a) Very very good intuition and be able to guess what sort of values it's likely to use so you can search those (unlikely lol)
b) Step through code around the area that you believe to be attributed to what you're investigating and hope some of the values look like they might be responsible for what's happening - Modify values during runtime to check.
c) Disable functions by jmp'ing over the calls or returning early and see if that bypasses observable functionality.
d) Disassemble large segments of code and analyse them, trying to figure out exactly how it works (this is the damn hard way).

All of the above are made somewhat easier if you have some sort of idea what class / object the functions belong to.

[amineurin]

yes i understand that is not really for sendpackets.
i think so that it the function can maybe used for packets, since what i understand the packets call the ingame functions.


just a poor idea:
is the pointer on the map not a little graphic ?
so maybe it helps to see what name it has and look for the name in the memory.

or set up a flag on the map and give it a name, then searching for the name or function what drawn it on the map.

i mean, some function must set the pointer/flag on the map to some cords after autoroute is called.
so if there also the graphic is drawn, the function is maybe found.

same function is called wen clicking on a green name in quest window.

anyway, it sounds like much work im miles away to do

[BuBucekTop]

Originally Posted by amineurin

i mean, some function must set the pointer/flag on the map to some cords after autoroute is called.

Actually some function sets destination mark (you calling it "flag") coordinates.
Then Autorouting routine starts - inside it toggles this "flag" visible.

My problem is figuring out this function.

Originally Posted by amineurin

same function is called wen clicking on a green name in quest window.

Exactly!

[dumbfck]

I dug pretty deep into all the functions that are bound to the actual mini map object (in the GUI stuff). I'm fairly confident that setting the destination mark is not (directly) done in one of these. I found the functions that draw the actual GUI windows / frames / controls themselves - When disabling that function (i.e., no controls are drawn on screen at all), as I had suspected, the map still gets drawn, so it may not be strictly handled as a GUI object. When you click the map, you are actually clicking an invisible overlay over the map - this is how the co-ordinates are read.
I also found the function which is responsible for drawing the dots on the map for mobs, players and NPCs. Disabling that still allowed the destination marker and the route line to be drawn.
I also managed to disable the individual functions that draw the destination marker and the route line, but as you said BuBucekTop, the coords are definitely set somewhere else.
I can also confirm that the mark is drawn before the char autoroutes.

However, I did start trying a different approach last night that seemed to be finding some interesting functions completely separated from the GUI stuff... It was getting very late so I abandoned it but I made a lot of notes so I shall be having another try at this later tonight

[BuBucekTop]

dumbfck, note that in map rendering code there are strange string labels - MARK1 - MARK6

[dumbfck]

Yes, mark1 - mark6 are dialogue names. They are much like the "window" controls although much simpler - but they can be found in the same list as all the other GUI windows (e.g., inventory, shop, chat window).
They are always there but are just made invisible until you open your big map.
I didn't get time to look at this stuff last night, but I'll probably have a poke sometime soon.

Just to clarify... Are you trying to control these markers, or are you trying to make it so that when using the previously mention autoroute function, the temporary line on the minimap and big map are not drawn at a weird angle going off the map?

[BuBucekTop]

To clarify - I want to control destination point on map (and hence dashed trace from my current position to it) to point it to correct coordinates.
I want it for route debug purposes and eyecandy ofcource.
But I gave up searching for this function solo and now willing to find it with community help.

Just figured out that mark on minimap drawn latest. I mean - it's being drawn topmost over all dialogs. If it helps.

[BuBucekTop]

any progress ?

[dumbfck]

I found the coordinates for the marker on the minimap (the little star inside a circle) that shows the destination point and was able to control it's position by hooking the function that normally handles it. However, I didn't have any luck with the dashed line. I'll post my findings and the code for controlling the destination point later (I'm not at home at the moment).
I *think* I've been able to isolate the function that draws the dashed line, i.e., I can disable it so that the line doesn't get drawn, but it's a pretty big function with lots of variables and lots of trigonometry in it lol.

***Edit***
Update

I've not found a 'good' solution for this, but I've spent a good few hours on it and don't really want to probe it any further lol, so I'll post what I've found so far.
Ok, a little primer...
The coordinates of the little marker on the mini map are pretty easy to find. The actual marker (the circle with the star on it) is a GUI dialogue / object / control called mMark6.
If you use my GUI Mapper you can see this is found at:

baseCall->structures->guiBase0->guiBase1->guiDialogueList->guiDialogue[0xAC]
I.e., 
[[[[[[baseCall] +0x1C] +0x18] +0x8] + 0xC4] +0xAC]

That's the base of the mMark6 object. lets call this mMark6Base.
X and Y coords of this are at mMark6Base + 0x98 and 0x9C respectively.
These values are constantly written to so it's not really practical to simply modify their X,Y coords in memory. I tried to inject the function which writes them, but there seems to be some sort of stack protection on it!?! Either that or I'm mis-interpreting it.
The function I'm talking about is at 0x77C8A0 (Descent).

    0077C8A0     /83EC 20       SUB ESP,20                               ; elementclient.0077C8A0(guessed Arg1,Arg2,Arg3,Arg4,Arg5)
    0077C8A3  |. |53            PUSH EBP
    0077C8A4  |. |55            PUSH EBP
    0077C8A5  |. |8BD9          MOV EBX,ECX                ** Hook here **
    0077C8A7  |. |8B43 34       MOV EAX,DWORD PTR DS:[EBX+34]
    0077C8AA  |. |8B88 88020000 MOV ECX,DWORD PTR DS:[EAX+288]
    0077C8B0  |. |8B90 8C020000 MOV EDX,DWORD PTR DS:[EAX+28C]
    0077C8B6  |. |05 88020000   ADD EAX,288
    0077C8BB  |. |56            PUSH ESI
    0077C8BC  |.  8B7424 40     MOV ESI,DWORD PTR SS:[ARG.16]
    0077C8C0  |.  57            PUSH EDI
    0077C8C1  |.  8B78 08       MOV EDI,DWORD PTR DS:[EAX+8]
    0077C8C4  |.  8B40 0C       MOV EAX,DWORD PTR DS:[EAX+0C]
    0077C8C7  |.  33ED          XOR EBP,EBP      <- Stack protection???
    0077C8C9      3BF5          CMP ESI,EBP

So... in the end I just hooked the function at 0x77C8A5, where I then modify the values that were sent as the desired X,Y coords of the mMark6 object.

The detour write looks like this:

LPVOID makeDetour(LPVOID lpFuncOrig, LPVOID lpFuncDetour)
{
    
    LPVOID lpMallocPtr = NULL;
    // Alloc mem for the overwritten bytes
    if((lpMallocPtr = (LPVOID)malloc(5)) == NULL)
        return NULL;

    PBYTE pbFuncOrig = (PBYTE)lpFuncOrig;
    
    BYTE reWrite[5];
    for(int i = 0 ; i < 5 ; i++)
    {
        reWrite[i] = pbFuncOrig[i];
    }
        
    BYTE overWrite[5];
    overWrite[0] = 0xE8;
    *(DWORD*)(overWrite+1) = (DWORD)lpFuncDetour - (DWORD)lpFuncOrig - 5;    // CALL PwMapHaxDLL.hSetMiniMapMarker
    /* will need to write following instructions back at end of hook:
    0077C8A5  8BD9          MOV EBX,ECX
    0077C8A7  8B43 34       MOV EAX,DWORD PTR DS:[EBX+34]
    */


    // Enable writing to original
    DWORD dwProt = NULL;
    VirtualProtect(lpFuncOrig, 5, PAGE_READWRITE, &dwProt);

    // Write the detour
    for(int i = 0; i < 5; i++)
        pbFuncOrig[i] = overWrite[i];

    // Reset original mem flags
    VirtualProtect(lpFuncOrig, 5, dwProt, new DWORD);

    return lpFuncOrig;
}

A simple overwrite with a relative call to my hook function.
The hook function then looks like this:

static DWORD * funcThisTarget;
static DWORD * mMark6Base;
__declspec( naked ) DWORD hSetMiniMapMarker( )
{
    _asm
    {
        PUSHAD
        MOV funcThisTarget, ECX
    }
    
    mMark6Base = (DWORD*)&baseCall->base->structures->guiBase0->guiBase1->dialogueBase->dialogObj[0xAC/4]->unknown0[0];
    
    if(mMark6Base == funcThisTarget)
    {
        _asm
        {
            MOV EAX, 0x375
            MOV [ESP+0x50], EAX
            MOV EAX, 0x3B
            MOV [ESP+0x54], EAX
        }
    }

    _asm
    {
        POPAD
        MOV EBX,ECX
        MOV EAX,DWORD PTR DS:[EBX+0x34]
        RETN
    }
}

Where the structs are defined as: (ignore all the other stuff - I didn't bother removing a lot of unneeded stuff, sorry).

struct __baseCall
{
public:
    __base* base;                //0x0000  
};

struct __base
{
public:
    char uk0[0x1C];                    //0x0000
    __structures* structures;        //0x001C
    char uk1[0x78];
    __stringConstStructArray* stringConstStructArray;    //0x90
    char unknown1[0x1D8];            
    HWND hWnd;                        //0x0274
};

struct __structures
{
public:
    char unknown0[0x18];        //0x0000
    __guiBase0* guiBase0;        //0x0018 
    char unknown1[0x18];        //0x001C
    __player* player;
};

struct __guiBase0
{
public:
    char unknown0[0x8];            //0x0000
    __guiBase1* guiBase1;        //0x0008  
};

struct __guiBase1
{
public:
    char unknown0[0xC4];        //0x0000
    dialogueBase* dialogueBase; //0x00C4  
};

struct dialogueBase
{
public:
    dialogueObj* dialogObj[0x6AC];
};

struct dialogueObj
{
public:
    char unknown0[0x4C];
    char* name;                    // 0x004C
    char unknown1[0x40];        // 0x0050
    char show;                    // 0x0090
    char unknown2[0x7];            // 0x0091
    DWORD xPos;                    // 0x0098
    DWORD yPos;                    // 0x009C
};

struct guiControlObject
{
public:
    char uk0[0x10];
    dialogueObj* parentObj;        // 0x0010
    char uk1[0x4];
    char* pName;                // 0x0018
    char* pCommand;                // 0x001C
    char* pSoundFile;            // 0x0020

    char hasFocus;                // 0x0074
    char uk3[0xF];
    DWORD xPos;                    // 0x0084
    DWORD yPos;                    // 0x0088
    DWORD width;                // 0x008C
    DWORD height;                // 0x0090
    
    char* text;                    // 0x00B8
    char* toolTip;                // 0x00BC

    item* itemObj;                // 0x00F4

    char isHovered;                // 0x0118

    DWORD scrollbarTop;            // 0x0124
    char scrollMouseDownPos;    // 0x0128
    char uk5[3];
    DWORD selectedIndex;        // 0x012C
    char uk6[4];
    DWORD columnHover;            // 0x0134
    DWORD rowHover;                // 0x0138
    char scrollbarMouseDown;    // 0x013C
    char uk7[3];
    DWORD scrollbarIndex;        // 0x0140
    char maxScrollPos;            // 0x0144
    char uk4[0xB];
    guiListItem* guiListItems;    // 0x0150
    char uk8[8];
    DWORD guiListItemCount;        // 0x015C
    DWORD imageOffsetInMap;        // 0x01FC
    imageProperties* imgProp;    // 0x0210
};

As you can see, it only modifies the arguments on the stack if the *this pointer is pointing to the mMark6 object (the function we hooked is called in the graphics rendering loop and also handles drawing other stuff).
Ideally, if this was incorporated into a full program, I would have set a flag showing that we want to modify the mMark6 position (e.g., so it only updates when we want to inject the movement function and not when you actually click the minimap ingame). However, I only made this as a proof of concept.
Once it has been identified that the *this pointer is correctly pointing at the mMark6 object, I simply hardcoded some values into the X and Y coords. 0x375 and 0x3B respectively. These will probably differ depending on your window size.
Ideally, you would read the Win_Map dialogue position (the complete container window in the top right corner) and added the Hide_2 position to that. The Hide_2 control is the 7th child control of the Win_Map dialogue and is actually the drawing surface of the map. This is located at:

[[[[[[[[[[[[[[[baseCall] +0x1C] +0x18] +0x8] +0xC4] +0x5C] +0x1C4] +0xC] +0xC] +0xC] +0xC] +0xC] +0xC] +0xC] +0x8]

The X,Y location of this child object is at the above base + 0x84 and 0x88 respectively. The width and height are at 0x8C and 0x90.

Anyway... with the above hook in place, if you click on the minimap, the marker position will be overridden.
Again, this is not really practical but it's just to demonstrate where the location is written.
This is actually pretty useless - Perhaps you guys can figure out how to hook / inject it better.

As for the dotted line...
If we inspect the map.xml interface file in interfaces.pck, we can see this:

    <IMAGEPICTURE Name="Hide_2" x="309" y="12" Width="128" Height="128">
        <Resource>
            <FrameImage FileName="Window\对话框_透明色a.bmp"/>
        </Resource>
    </IMAGEPICTURE>

Yep... it's that Hide_2 thing again (the drawing surface for the map).
However, the frameImage specified, Window\对话框_透明色a.bmp is actually a little 1x1 pixel purple square - I believe this gets redrawn for each dot that constitutes the dotted line. However I had little luck tracking it down.
I did isolate a few possible functions responsible for actually drawing it - I'll go through my notes and try to find them if anyone needs them, however, I think there may be a better solution.

Again, this isn't ideal, but you could possibly simulate a 'click' on the minimap or the main map. This is very simple.
I threw ogether this little AutoShit demo to simulate a minimap click (yes, I know... but I had a similar program already which only needed a little modification lol).

#include <NomadMemory.au3>

Global $kernel32 = DllOpen('kernel32.dll')
Global $pid = ProcessExists('elementclient.exe')

global $baseCall = 0xA521C0
global $moveViaMiniMapCall = 0x583290
global $moveViaBigMapCall = 0x5D0EB0

$pHandle = _MemoryOpen($pid)

; Mini map container window (Win_Map)
Global $Win_Map_List[6] = [0, 0x1C, 0x18, 0x8, 0xC4, 0x5C]
$Win_Map_Base = _MemoryPointerRead($baseCall, $pHandle, $Win_Map_List)
$Win_Map_Base = $Win_Map_Base[1]
$Win_Map_X = _MemoryRead($Win_Map_Base + 0x98, $pHandle)
$Win_Map_Y = _MemoryRead($Win_Map_Base + 0x9C, $pHandle)

; Mini map image control (Hide_2)
Global $Hide_2_List[15] = [0, 0x1C, 0x18, 0x8, 0xC4, 0x5C, 0x1C4, 0xC, 0xC, 0xC, 0xC, 0xC, 0xC, 0xC, 0x8]
$Hide_2_Base = _MemoryPointerRead($baseCall, $pHandle, $Hide_2_List)
$Hide_2_Base = $Hide_2_Base[1]
$Hide_2_X = _MemoryRead($Hide_2_Base + 0x84, $pHandle)
$Hide_2_Y = _MemoryRead($Hide_2_Base + 0x88, $pHandle)
$Hide_2_Width = _MemoryRead($Hide_2_Base + 0x8C, $pHandle)
$Hide_2_Height = _MemoryRead($Hide_2_Base + 0x90, $pHandle)

; Get absolute screen coords of centre of minimap (accounts for resizing window etc)
$miniMapPlayerX = $Win_Map_X + $Hide_2_X + ($Hide_2_Width / 2)
$miniMapPlayerY = $Win_Map_Y + $Hide_2_Y + ($Hide_2_Height / 2)

; Move 1 unit East and 1 unit South
Global $tarX = $miniMapPlayerX + 1
Global $tarY = $miniMapPlayerY + 1

; coords in YYYYXXXX format
Global $coords = BitOr(BitShift($tarY, -16), $tarX)

;ConsoleWrite(Hex($Win_Map_Base) & ' ' & Hex($Hide_2_Base) & ' ' & Hex($coords) & @CRLF)

_MemoryClose($pHandle)

$funcCall = $moveViaMiniMapCall
moveViaMap($Win_Map_Base, $Hide_2_Base, $coords, $funcCall)

DllClose($kernel32)



Func moveViaMap($outerObj, $innerObj, $coords, $funcAddress)
    Local $pRemoteThread, $vBuffer, $loop, $result, $OPcode, $processHandle, $packetAddress
    
    $processHandle = memopen($pid)
    $functionAddress = DllCall($kernel32, 'int', 'VirtualAllocEx', 'int', $processHandle, 'ptr', 0, 'int', 0x46, 'int', 0x1000, 'int', 0x40)
    
    ;Construct the OpCode for calling the 'SendPacket' function
    $OPcode &= '60'                             ;PUSHAD
    $OPcode &= '68'&_hex($innerObj)                ;PUSH innerObj
    $OPcode &= '68'&_hex($coords)                ;PUSH coords
    $OPcode &= '6A00'                            ;PUSH 0
    $OPcode &= 'B9'&_hex($outerObj)             ;MOV ECX, outerObj
    $OPcode &= 'B8'&_hex($funcAddress)            ;MOV EAX, moveViaMiniMapCall
    $OPcode &= 'FFD0'                           ;CALL EAX
    $OPcode &= '61'                             ;POPAD
    $OPcode &= 'C3'                             ;RETN
    
    ;Put the OpCode into a struct for later memory writing
    $vBuffer = DllStructCreate('byte[' & StringLen($OPcode) / 2 & ']')
    For $loop = 1 To DllStructGetSize($vBuffer)
        DllStructSetData($vBuffer, 1, Dec(StringMid($OPcode, ($loop - 1) * 2 + 1, 2)), $loop)
    Next
    
    ;Write the OpCode to previously allocated memory
    DllCall($kernel32, 'int', 'WriteProcessMemory', 'int', $processHandle, 'int', $functionAddress[0], 'int', DllStructGetPtr($vBuffer), 'int', DllStructGetSize($vBuffer), 'int', 0)
    ;ConsoleWrite(Hex($functionAddress[0]) & @CRLF)

    ;Create a remote thread in order to run the OpCode
    $hRemoteThread = DllCall($kernel32, 'int', 'CreateRemoteThread', 'int', $processHandle, 'int', 0, 'int', 0, 'int', $functionAddress[0], 'ptr', 0, 'int', 0, 'int', 0)
    
    ;Wait for the remote thread to finish
    Do
        $result = DllCall('kernel32.dll', 'int', 'WaitForSingleObject', 'int', $hRemoteThread[0], 'int', 50)
    Until $result[0] <> 258
    
    ;Close the handle to the previously created remote thread
    DllCall($kernel32, 'int', 'CloseHandle', 'int', $hRemoteThread[0])
    
    ;Free the previously allocated memory
    DllCall($kernel32, 'ptr', 'VirtualFreeEx', 'hwnd', $processHandle, 'int', $functionAddress[0], 'int', 0, 'int', 0x8000)
    
    ;Close the Process
    memclose($processHandle)
    
    Return True
EndFunc

Func memopen($pid)
    Local $mid = DllCall($kernel32, 'int', 'OpenProcess', 'int', 0x1F0FFF, 'int', 1, 'int', $pid)
    Return $mid[0]
EndFunc

Func memclose($mid)
    DllCall($kernel32, 'int', 'CloseHandle', 'int', $mid)
EndFunc

Func _hex($Value, $size=8)
    Local $tmp1, $tmp2, $i 
    $tmp1 = StringRight("000000000" & Hex($Value),$size) 
    For $i = 0 To StringLen($tmp1) / 2 - 1 
        $tmp2 = $tmp2 & StringMid($tmp1, StringLen($tmp1) - 1 - 2 * $i, 2)
    Next
    Return $tmp2
EndFunc

Again, it's only for demonstration purposes so is very simplistic.
It calculates the position of the player marker (the arrow) on the mini map, then injects the function which handles moving via the mini map.
For this demonstration it simply autoroutes 1 'unit' East and 1 unit South.

There is a similar function for the large map at 0x5D0EB0 which can be called using the exact same injector, but using different coordinates. I didn't get as far as finding a pointer to the current player position on the big map so I tested it with hardcoded values and it worked.
Oh... one other little snag with the large map function is that it checks for the Alt key being pressed otherwise it won't autoroute - it will simply show the zoomed map at the specified coordinates. For my test, I simple patched the client at 0x5D1099

005D1099     /0F88 A3000000 JS elementclient.005D1142

Just patch it to a JMP and it will always assume the Alt key is pressed - again only useful for this precise debugging purpose but I'm sure there's a more elegant way to deal with this.

So... Although this itself is potentially pretty useful for navigating around the immediate local area, it's possibly useful in a wider scope...
As the function mentioned a few posts back which injects the autoroute function does not write the map markers / traces, perhaps it would be possible to first simulate a map click which would setup the destination marker and the dashed line, then manually inject the autoroute function to get a more accurate route.

That's about it - Sorry it's not a decent solution but maybe it'll help in some way.

Cheers.

[1nfinite]

I know this thread is pretty old now, but thanks for the idea for using the dev console to look for IDs. I'm also using it to find the offsets for x,y,z pos in the latest update (which I admit was irritating me before). And you're right, d_boundbox does look cool Anyway, mucho gracias, you have my thanks

N.B. Depending on your version to get this working now you might have to edit the *-v1 file as well as the one stated in OP to get the console working. I did anyway.

Also, you can exit the console with Esc. Not sure if anyone had posted that before. Think OP said it stole focus and wouldn't go away without reinstating the backup'd interfaces.pck but there's no need, just hit esc when you're done doing whatever totally legit things you're doing with the dev console.