Target unit ground position

[goblin2kx]

Yep, the problem was GetWindowRect includes the width of the bar at the top of the window. That accounts for the slightly elevated coordinates. Thankfully I caught this early on by running things in window mode, if it was fullscreen you would not see this problem . Looks like my world->screen transformation works fine.

If you're reading this and looking for how to do world->screen, this is a great source that explains everything.
https://www.ownedcore.com/forums/world-of-warcraft/world-of-warcraft-bots-programs/wow-memory-editing/995149-world2screen-wotlk-classic.html

Thanks everyone for your input!

[thateuler]

How are you calling it? The issue with scales usually is like the UIParent:GetScale value. That's why I called my function WorldToViewport, as it returns the screen % of the x & y. If I call it from a rendering backend (lets say imgui) then I would use something like GetClientRect for the screen size and then apply the % to. If it's in lua though, and returned the % it's important to apply the frames scale to it. Without that, it'll be off at certain resolutions/scaling

Had another look at this and got it figured out. I'm using LibDraw for screen drawing.

Project335/Libs/!LibDraw/LibDraw.lua at master . CuteOne/Project335 . GitHub

• Libdraw uses wow frames to draw lines. The origin is the top left corner and y coordinates are negtive.
• The ViewPort code is working well. It scales the value returned by CGWorldFrame__GetScreenCoordinates by the aspect compensation, which does exactly as it sounds, it normalizes the coordinates to compensate for different aspect ratios. The bottom left corner of the screen is 0, 0, the top right of the screen is 1, 1.
• Disabling the ui scale is a lie. When disabled the ui scale is actually 80%. My monitor is 1920x1080. Not sure if that makes a difference or not.
• Wow has some lua functions to get screen geometry.
  
  • WorldFrame:GetHeight() and WorldFrame:GetWidth() are not affected by the UI scale.
  • UIParent:Get*() and GetScreen*() are affected by the UI scale.
  • Wow Frames (Frame:SetPoint()) is independent of UI scale. Which kinda makes sense hey. Keep things simple.
• Wow seems to have some default scaling all the time. For example, if the window size is 1440x960 and ui scale is 100% then WorldFrame, UIParent and GetScreen* all return 1152x768. (1152 is 80% of 1440.)

So the trick was to give the wow frame code what it wants, which is coords with origin at the top left of the screen that aren't scaled by the ui scale (i.e., multiply viewport by WorldFrame:Get*() and then fix the y coordinate.)

After making this change, line drawing is correct with any ui scale, any resolution and full screen or windowed.

[goblin2kx]

Another question, is the HandleTerrainClick method still usable in retail right now? If it is any hint on where it can found? Thanks!

[scizzydo]

Another question, is the HandleTerrainClick method still usable in retail right now? If it is any hint on where it can found? Thanks!

Yes. There is in retail

[goblin2kx]

Yes. There is in retail

Ok, I found CGGameUI::HandleTerrainClick()

__int64 __fastcall CGGameUI::HandleTerrainClick(__int64 a1)
{
if ( *(_DWORD * )(a1 + 28 ) == 4 || CGGameUI::m_cursorVirtualID )
CGGameUI::ClearCursor(1i64, 1i64, 1i64);
CGGameUI::OnTerrainClick(a1);
return 1i64;
}

and calling it with (seems to be a static function), I dug this up from early posts on the forum, it wasn't 100% obvious.

typedef struct TerrainClickData
{
WoWGUID mover;
float pos[3];
int click_type;
};
data.mover = 0;
data.pos[0]=x;data.pos[1]=y;data.pos[2]=z;
data.click_type = 1;

CGGameUI::HandleTerrainClick(&data);

click_type = 0x1 left clicks. But calling the CGGameUI::HandleTerrainClick it seems to crash the game (not always though). The crash is an access violation, at a location that doesn't really make sense - doesn't seem directly related anyway. Am I missing something? Any ideas welcome!

Edit: Some places on the forums it seems that some are are just using 64 bit mover guid instead of the full 128, I tried this, no crash but it also performs no action.

[scizzydo]

Ok, I found CGGameUI::HandleTerrainClick()

__int64 __fastcall CGGameUI::HandleTerrainClick(__int64 a1)
{
if ( *(_DWORD * )(a1 + 28 ) == 4 || CGGameUI::m_cursorVirtualID )
CGGameUI::ClearCursor(1i64, 1i64, 1i64);
CGGameUI::OnTerrainClick(a1);
return 1i64;
}

and calling it with (seems to be a static function), I dug this up from early posts on the forum, it wasn't 100% obvious.

typedef struct TerrainClickData
{
WoWGUID mover;
float pos[3];
int click_type;
};
data.mover = 0;
data.pos[0]=x;data.pos[1]=y;data.pos[2]=z;
data.click_type = 1;

CGGameUI::HandleTerrainClick(&data);

click_type = 0x1 left clicks. But calling the CGGameUI::HandleTerrainClick it seems to crash the game (not always though). The crash is an access violation, at a location that doesn't really make sense - doesn't seem directly related anyway. Am I missing something? Any ideas welcome!

Edit: Some places on the forums it seems that some are are just using 64 bit mover guid instead of the full 128, I tried this, no crash but it also performs no action.

The guid is a 128bit field. I've been away from my PC to check the function I'm using. There's a few that are in a call chain, I'm pretty sure it's the OnTerrainClick

[goblin2kx]

The guid is a 128bit field. I've been away from my PC to check the function I'm using. There's a few that are in a call chain, I'm pretty sure it's the OnTerrainClick

Ahh I'd be interested to know which function you call in that call chain.
I think it's a specific circumstance when this happens, and it has something to do with casting right where the target is (interaction with the left click and an already selected target). Most of the time it just works.

Edit: Should it matter if you call CGGameUI::HandleTerrainClick or CGGameUI::OnTerrainClick? All it does in CGGameUI::HandleTerrainClick as extra is to clear the cursor when a right click is performed.

[Kangaroo6052]

Can you get the length, width, and height of the object? Based on the code above, it only retrieves a single point at the base.

[scizzydo]

Can you get the length, width, and height of the object? Based on the code above, it only retrieves a single point at the base.

The point talked about is the center ground position of the model. You can get stuff like the bounding radius and height from other parts of the struct. If grabbing the height, make sure to get the model scales from the display struct too. The combat reach for example applies these scales to the value read, but not the height

[Kangaroo6052]

The point talked about is the center ground position of the model. You can get stuff like the bounding radius and height from other parts of the struct. If grabbing the height, make sure to get the model scales from the display struct too. The combat reach for example applies these scales to the value read, but not the height

Thanks for the guidance! I think I still need to learn how to find the height and scaling factor.

[helloworld1024]

No need to redact... this stuff has been public knowledge for quite some time. I have yet to see a VMT being checked, and even if they were ret checked, you can easily fake it with a rop gadget. It's just the aggressive checks where they register where functions are direct calls that the ret check requires it from specific calling locations. Stuff like the CGUnit_C::GetPosition is only called from vtable, so it would be a call rax type situation, easy to fake with assembly. As far as transforms:

                Matrix44 mat;
                if (pobj->GetMatrix44(&mat)) {
                    const auto inv_m = mat.inverse();
                    const auto rel = inv_m.multiplyVec3(in);
                    lua_pushvec3(L, rel);
                    return 3;
                }

That's my lua callback code for transforming a world coordinate to the transport relative location (useful for the fights you're on a transport, and the transport moves). Without that, your spells would "slip" off the transport.

struct Matrix44 {
    float m[4][4];
    Matrix44() {
        m[0][0] = 1.f; m[0][1] = 0.f; m[0][2] = 0.f; m[0][3] = 0.f;
        m[1][0] = 0.f; m[1][1] = 1.f; m[1][2] = 0.f; m[1][3] = 0.f;
        m[2][0] = 0.f; m[2][1] = 0.f; m[2][2] = 1.f; m[2][3] = 0.f;
        m[3][0] = 0.f; m[3][1] = 0.f; m[3][2] = 0.f; m[3][3] = 1.f;
    }
    Matrix44(float val[4][4]) {
        for (int i = 0; i < 4; ++i)
            for (int j = 0; j < 4; ++j)
                m[i][j] = val[i][j];
    }

    Matrix44 inverse() const {
        Matrix44 inv;

        // Transpose the 3x3 rotation part (this inverts the rotation)
        inv.m[0][0] = m[0][0]; // First column
        inv.m[0][1] = m[1][0];
        inv.m[0][2] = m[2][0];

        inv.m[1][0] = m[0][1]; // Second column
        inv.m[1][1] = m[1][1];
        inv.m[1][2] = m[2][1];

        inv.m[2][0] = m[0][2]; // Third column
        inv.m[2][1] = m[1][2];
        inv.m[2][2] = m[2][2];

        // Invert the translation by applying the inverted rotation to the translation vector
        inv.m[3][0] = -(inv.m[0][0] * m[3][0] + inv.m[1][0] * m[3][1] + inv.m[2][0] * m[3][2]);
        inv.m[3][1] = -(inv.m[0][1] * m[3][0] + inv.m[1][1] * m[3][1] + inv.m[2][1] * m[3][2]);
        inv.m[3][2] = -(inv.m[0][2] * m[3][0] + inv.m[1][2] * m[3][1] + inv.m[2][2] * m[3][2]);

        // Set the bottom row (identity matrix row)
        inv.m[0][3] = 0.0f;
        inv.m[1][3] = 0.0f;
        inv.m[2][3] = 0.0f;
        inv.m[3][3] = 1.0f;

        return inv;
    }

    Vec3 multiplyVec3(const Vec3& v) const {
        Vec3 result;
        result.x = m[0][0] * v.x + m[1][0] * v.y + m[2][0] * v.z + m[3][0]; // m[3][0] is the x translation
        result.y = m[0][1] * v.x + m[1][1] * v.y + m[2][1] * v.z + m[3][1]; // m[3][1] is the y translation
        result.z = m[0][2] * v.x + m[1][2] * v.y + m[2][2] * v.z + m[3][2]; // m[3][2] is the z translation
        return result;
    }
};

Heck, even the transform matrix shit can be found on this forum from pretty far back if you search properly

VMTs:
CGObject_C::GetPosition - 18 windows, 19 mac
CGObject_C::GetPositionRaw - 19 windows, 20 mac
CGUnit_C::GetFacing - 20 windows, 21 mac
CGUnit_C::GetFacingRaw - 21 windows, 22 mac

Up to you to find the matrix Which one of the matrix functions that you can use from the mac wod binary is also now behind a ret check

Hint: There is a virtual function that returns the matrix. It's just not as easy to call on MacOS (arm) due to arg2 not being in the correct register if you were to compile the code on your own :P

11.0.5 CGObject_C::GetPosition and CGObject_C::GetPositionRaw disappeared from vmt
Some spells would ‘slip’ off the transport in dungeon now!

So " pobj->GetMatrix44(&mat) " is use Transport_Matrix(playerGUID) to get Matrix44 to mat?
Then pass the current world coordinates in multiplyVec3 to get the inverse matrix coordinates?

[scizzydo]

11.0.5 CGObject_C::GetPosition and CGObject_C::GetPositionRaw disappeared from vmt
Some spells would ‘slip’ off the transport in dungeon now!

So " pobj->GetMatrix44(&mat) " is use Transport_Matrix(playerGUID) to get Matrix44 to mat?
Then pass the current world coordinates in multiplyVec3 to get the inverse matrix coordinates?

For casting on transports, you need transport relative coordinates, and to apply the mover GUID in the terrain data passed to the function. If you read off the movement structure, this is the relative location. If you're doing a coordinate that is in world coordinates though, you must inverse the transports matrix, and multiple the coordinates to get the relative. If you're going from relative to world, you don't have to inverse the transports matrix, just multiply the relative coordinates to get the world coordinates.

[helloworld1024]

For casting on transports, you need transport relative coordinates, and to apply the mover GUID in the terrain data passed to the function. If you read off the movement structure, this is the relative location. If you're doing a coordinate that is in world coordinates though, you must inverse the transports matrix, and multiple the coordinates to get the relative. If you're going from relative to world, you don't have to inverse the transports matrix, just multiply the relative coordinates to get the world coordinates.

I've done it.

Thanks for the relevant tips, learnt something new today!

So is there an easy way to get world coordinates now?

[Kangaroo6052]

Maybe I haven't understood the difference between several matrices. Confusing the concepts involved

For example, the xyz I get from CMovement+0x18, in some dungeons, such as on a ship, it happens that the spells slip off

Do I need to inverse matrix this xyz?

As far as I know, in some vehicles, like Alliance ships and Horde zeppelins, the coordinate system seems to be incorrect; it appears to be using relative coordinates. I’m not entirely clear on the details yet, still learning about it.

[ostapus]

11.0.5 CGObject_C::GetPosition and CGObject_C::GetPositionRaw disappeared from vmt
Some spells would ‘slip’ off the transport in dungeon now!

So " pobj->GetMatrix44(&mat) " is use Transport_Matrix(playerGUID) to get Matrix44 to mat?
Then pass the current world coordinates in multiplyVec3 to get the inverse matrix coordinates?

in retail 57292 - 0x00000001425E8AC0 is the function to return object position