Sending Packets

[Sturolv]

Here are the packages read from the reserved memory:

Packet1:
0000853397C386756AC421E76343853397C386756AC421E763 43E8030105610A00
Packet2:
0000853397C386756AC421E76843853397C386756AC421E768 43E8030105610B00
Packet3:
0000853397C386756AC421E76D43853397C386756AC421E76D 43E8030105610C00
Packet4:
0700853397C386756AC421E77243010500610D00E803

The character position was read using nomadmemory.au3 and _MemoryRead($pchar + $oposx, $pid, 'float') into a variable. The startposition converted to hex is:

Char position converted to hex:
x: FFFFFED2, y: FFFFFC57, z: 000000DE

As floats:
x: -302.402496337891, y: -937.836303710938, z: 222.902847290039

Char position as floats modified with 4000 and 5500 and divided with 10 it's:369.759750366211, 456.216369628906, 22.2902847290039

The coordinates was writen to the package as a float, maybe that's why they differ from the variables

I read the coordinates with this:

Dim $oposx = 0x3c, $oposy = 0x44, $oposz = 0x40
$charInfo[$IX] = _MemoryRead($pchar + $oposx, $pid, 'float')
$charInfo[$IY] = _MemoryRead($pchar + $oposy, $pid, 'float')
$charInfo[$IZ] = _MemoryRead($pchar + $oposz, $pid, 'float')

I'm not sure if what I think is Y is really Y but maybe it's z instead. I might put the wrong coordinate in the wrong position in the package, making the server to ignore the message.

Could I use an actionstructure and do a move instead of sending packages as long as I only move as much as the speed allows? If so is it move type 0? I would perhaps need to find what different values there are for different moves like regular, fly, swimming.

Edit: I found this promising post:

and it with the check on height it initialises some more for flying up or down. By using that would I still need to create several actions to reach the destination regarding to the flyspeed?

[Sᴡoosh]

in D3d Coordinate systems, Y is what you may know as Z, and Z is either left or right axis.



So thats correct.

Using actionstruct to move up is possible, yes, but you need to set the flags according to this. Interest07's post contains everything you need. After this, write Your current coords to the X/Y offsets in action struct and then your desired height in Z (Yes I call Z for height too even though its actually called Y even by the game).

Hope this was a bit of help.

Cheers

[Interest07]

Yeah you're right, you have swapped the Y and the Z values.

You can use actionstructs, but not to fly straight up, only at a 45 degree angle (I think something like that). For swimming/walking/flying its all the same, the moveType is something that would technically be for when you press space or jump or whatever if I recall correctly, but I never managed to get that working.

With actionstructs you don't need to take into account flyspeed etcetera as the game will do this for you :P

edit:
Even in graphs the XYZ axes would be like they are in game, I'm not sure why people swap Y and Z around, could somebody explain that to me?

[Sᴡoosh]

I dont know why people swap that, but personally, I do to.

Maybe this has to do with the fact that the ingame coords are called X and Y, and height was refered to as Z (when I was still playing).

I dont think it matters much though how you call the vars in your code, as long as you know how the person who documented it decided to call it

[Interest07]

Originally Posted by 2981611

I dont know why people swap that, but personally, I do to.

Maybe this has to do with the fact that the ingame coords are called X and Y, and height was refered to as Z (when I was still playing).

I dont think it matters much though how you call the vars in your code, as long as you know how the person who documented it decided to call it

True, it's caused confusion plenty of times before lol

[Shareen]

Originally Posted by Interest07

Even in graphs the XYZ axes would be like they are in game, I'm not sure why people swap Y and Z around, could somebody explain that to me

It comes from semantics used for 2D systems.
When you use 2D systems, you use X and Y.

When switching from 2D to 3D, you add one more axis and when you do, you are inclined to call it something different, like Z for example.

So you end up calling Z the new axis and it's usually height.
You write it down as XYZ (alphabetical order) meaning X, Y and height.

But in 3D systems, height is the middle value (I'm simplifying of course, in a random 3D system height can be anything you like, but for games, this should hold true majority of times), so people coming from 3D systems will write:
XYZ meaning: X, height, Z - keeping the alphabetical order, but meaning Y as height

Where as people used to 2D systems and working in 3D will prefer to write:
XZY meaning: X, height, Y - screw alphabet and make it sensible

By sensible I mean this: keep semantic values static when moving from 2D to 3D (ie,.. if X is width and Y is lenght in 2D system, moving to 3D system doesn't change that). This avoids confusion when coding, since number of axis is irrelevant to you (2 or 3), if X and Y always mean the same thing.

Opposite to it, if X means width and Y means length in 2D, moving to 3D changes that: Y now means height and Z means length.


Word of caution: note that terms like witdh, length and height in 3D world suffer from the similar semantic problem as XYZ. 90 dg. rotation around an axis can quickly turn width into length, so these terms aren't normally used.

[Interest07]

Originally Posted by Shareen

It comes from semantics used for 2D systems.
When you use 2D systems, you use X and Y.

When switching from 2D to 3D, you add one more axis and when you do, you are inclined to call it something different, like Z for example.

So you end up calling Z the new axis and it's usually height.
You write it down as XYZ (alphabetical order) meaning X, Y and height.

But in 3D systems, height is the middle value (I'm simplifying of course, in a random 3D system height can be anything you like, but for games, this should hold true majority of times), so people coming from 3D systems will write:
XYZ meaning: X, height, Z - keeping the alphabetical order, but meaning Y as height

Where as people used to 2D systems and working in 3D will prefer to write:
XZY meaning: X, height, Y - screw alphabet and make it sensible

By sensible I mean this: keep semantic values static when moving from 2D to 3D (ie,.. if X is width and Y is lenght in 2D system, moving to 3D system doesn't change that). This avoids confusion when coding, since number of axis is irrelevant to you (2 or 3), if X and Y always mean the same thing.

Opposite to it, if X means width and Y means length in 2D, moving to 3D changes that: Y now means height and Z means length.


Word of caution: note that terms like witdh, length and height in 3D world suffer from the similar semantic problem as XYZ. 90 dg. rotation around an axis can quickly turn width into length, so these terms aren't normally used.

Thanks

I suppose the difference is whether you start from a 2D perspective and add an axis, or start from a 3D persective right away. I'm used to looking at graphs for example, where X is left to right, Y is bottom to top, and (if it's a 3D graph) Z would be front to back. But it's understandable if you go from map coordinates to ingame coordinates that you put height last.

If there were decent alternatives for the X and Z variable names, I wouldn't mind changing Y to height and X and Z to whatever is appropriate, but I can't really think of any.

[Sturolv]

Alright! After swapping y and z the server now accepts the packages and the char moves up and down, though I only see the camera bouncing up one step at the time while the character remains still all the time untill I make a manual movement then it "teleports" to the new height + my manual movement.

I also tried with the actionstruct and only get that to work if I also make a movement along an other axis. And it seems to only change in height as long as there is still movement going on along the other axis.

Maybe I'm not using the actionstruct correctly.

Suggestions about how to make the movement smooth with packets or how to use the actionstruct better is appreciated, but maybe this belongs in an other thread.

[Interest07]

if you dont see the character moving up also, you don't have all the correct offsets necessary for displaying the character position. I tried to explain earlier that with action structs you can't move straight up, only at an angle, so you'd have to move sideways to use this properly. You most likely are using them properly

Smoothness isn't really important for moving with packets, as it only looks choppy clientside.

[Sturolv]

Ok, I think I can live without the smoothness

As you say I don't have the correct offsets, I found 5 offsets that changes to the new z (I mean height by this), but one of those 5 don't have the correct x and y next to it.

I updated those 4 (with correct x, y next to them) but still the char don't move, only the camera. If I target myself I see the target circle in the right spot though, looks funny

Could you please help me with the offests? I found these and do the following update after the package is sent:

Dim $oposx = 0x3c, $oposy = 0x44, $oposz = 0x40
Dim $oposx2 = 0x7c, $oposy2 = 0x84, $oposz2 = 0x80
Dim $oposx3 = 0x918, $oposy3 = 0x920, $oposz3 = 0x91c
Dim $oposx4 = 0x92c, $oposy4 = 0x934, $oposz4 = 0x930

_MemoryWrite($pchar + $oposx, $pid, $curX, 'float')
_MemoryWrite($pchar + $oposy, $pid, $curY, 'float')
_MemoryWrite($pchar + $oposz, $pid, $curZ, 'float')
_MemoryWrite($pchar + $oposx2, $pid, $curX, 'float')
_MemoryWrite($pchar + $oposy2, $pid, $curY, 'float')
_MemoryWrite($pchar + $oposz2, $pid, $curZ, 'float')
_MemoryWrite($pchar + $oposx3, $pid, $curX, 'float')
_MemoryWrite($pchar + $oposy3, $pid, $curY, 'float')
_MemoryWrite($pchar + $oposz3, $pid, $curZ, 'float')
_MemoryWrite($pchar + $oposx4, $pid, $curX, 'float')
_MemoryWrite($pchar + $oposy4, $pid, $curY, 'float')
_MemoryWrite($pchar + $oposz4, $pid, $curZ, 'float')

[Interest07]

try
coords = 0x390
coords_x = base + 1c + 34 + 390 + 3c
coords_y = base + 1c + 34 + 390 + 40
coords_z = base + 1c + 34 + 390 + 44

[Sturolv]

Originally Posted by Interest07

try
coords = 0x390
coords_x = base + 1c + 34 + 390 + 3c
coords_y = base + 1c + 34 + 390 + 40
coords_z = base + 1c + 34 + 390 + 44

Thanks, that did the trick

[Shortpants]

Where exactly do you set the breakpoint to see the unecrypted packet data?
Could you provide a screenshot of that once?

[Interest07]

I use MHS to set a breakpoint at the sendPacketFunction (0x659450 in PWI atm) to run this script:

void On_BP_1(LPVOID lpvAddress, LPPROC_INFO_MHS lpProcInfo)
{
	DWORD pktSize_ptr = lpProcInfo->pcContext->Esp+8;
	DWORD pktSize = 0;
	
	ReadProcessMemory(lpProcInfo->hProcess, (void *)pktSize_ptr, &pktSize, 4, NULL);
	
	DWORD pkt_ptr_ptr = lpProcInfo->pcContext->Esp+4;
	DWORD pkt_ptr = 0;
	BYTE bp_newpacket[255] = {0};
	char bp_packet[1024] = {0};	

	ReadProcessMemory(lpProcInfo->hProcess, (void *)pkt_ptr_ptr, &pkt_ptr, 4, NULL);
	ReadProcessMemory(lpProcInfo->hProcess, (void *)pkt_ptr, &bp_newpacket, pktSize, NULL);
	
	for (int i = 0; i < pktSize; i++){
		SPrintF(&bp_packet[i*3], "%02X ", bp_newpacket[i]);
	}

	DWORD callingFunctionAddress = 0;
	DWORD callingfunctionAddress_ptr = lpProcInfo->pcContext->Esp;
	
	ReadProcessMemory(lpProcInfo->hProcess, (void *)callingfunctionAddress_ptr, &callingFunctionAddress, 4, NULL);
	



PrintF("[%08X] Packet: %s",callingFunctionAddress, bp_packet);
}

[Sturolv]

I didn't find if there is client information about an other players target.
Also I didn't find any post about an assist package so here is what I found out:

Package for assist:

Func AssistTarget($targetId, $pid)
local $packet, $packetSize

$packet = '3200'
$packet &= _hex($targetId)
$packetSize = 6
sendPacket($packet, $packetSize, $pid)
EndFunc