Walk delay in 2011 clients

[RagnaGaga]

Kinda like this topic: http://www.eathena.ws/board/index.php?showtopic=276312

All the 2011 clients I've tried have some weird kind of walking delay. I tried January 2011 till July 2011 and they all have the same problem.

Whenever you quickly click twice in a row, the second click is pretty much not registered. It's like there's a delay of 300ms or something before you can actually click again and it registers the click.

We couldn't trace this back to any source-related change, so is it simply something that Gravity added to the 2011 clients? Although I checked cookieRO, which for sure has quite a new client, and they do not have this issue.

Any clue?

[jTynne]

Trojal said to me that this was something to do with the kRO attempt at mouse freedom. He didn't offer any fix for it, and I've not experimented with it much myself, but the 2011-03-15 client isn't having that issue for me. If I hear or find anything else, I'll toss it here.

Just out of curiosity, which client date are you experiencing issues with?

Edited November 27, 2011 by jTynne

[RagnaGaga]

Pretty much anything with packet version 26. I tried clients from January, March, April, May, June and July.

[jTynne]

Odd, I'm not having that issue with the March 15th client (read here on eAnet that it's the latest "stable" client supported by eAthena), though I do have it set to version 25 in the clientinfo file running the latest eAthena on my laptop. I do know what you're referring to, though, as I had the issue previously about six or so months ago when I was toying around with the newer clients.

[RagnaGaga]

M'yeah, it's caused by packet ver 26. We pretty much have to use that for clients after November 24th 2010 so using 25 is not an option.

[Ai4rei]

Check the topic linked in the first post, there is a solution now.

[jTynne]

You're the best, Ai4rei

[Judas]

Omg thank you

[Mercurial]

Imma post here just for reference

http://www.eathena.w...&pid=1061097400

To get past this issue you will need to hex your client, I cannot think of a way the server could affect this. The thing works the following way inside the client:

<p>CZ_REQUEST_MOVE (old walktoxy packet):

• Encode target coordinates into a 3 byte field.
  

• Send packet 0x85 or 0xa7 (depending on client).
  

<p>CZ_REQUEST_MOVE2 (walktoxy packet used by pv26 clients):

• Check some global value, if zero, do not walk.
  

• Check some other global value, if not zero, do not walk.
  

• If lastTick+1000>timeGetTime(), do not walk. Here is your double-click; new clients allow the packet to be sent only once per 1 second.
  

• Send packet 0x35f (encoded target coordinates have been encoded somewhere else already).
  

The easiest way to get rid of it would probably be this:

CMP EBX' date='DWORD PTR DS:[8D402C] ; Case 10C of switch 006B23FD

JE 111005RE.006B6BB0

CMP DWORD PTR DS:[86CCE8],0

JNZ 111005RE.006B6BB0

MOV ESI,DWORD PTR DS:[<&WINMM.timeGetTime>] ; WINMM.timeGetTime

CALL NEAR ESI ; <&WINMM.timeGetTime>

MOV ECX,DWORD PTR SS:[EBP+2F8]

ADD ECX,3E8 ; 1000ms

CMP EAX,ECX

JBE 111005RE.006B6BB0

CALL NEAR ESI ; <&WINMM.timeGetTime>

MOV DWORD PTR SS:[EBP+2F8],EAX

LEA EAX,DWORD PTR SS:[ESP+46C]

MOV EDX,35F

PUSH EAX

MOV WORD PTR SS:[ESP+470],DX

MOV DWORD PTR SS:[ESP+472],EBX

PUSH EDX

JMP 111005RE.006B9AC7

into:

CMP EBX' date='DWORD PTR DS:[8D402C] ; Case 10C of switch 006B23FD

JE 111005RE.006B6BB0

CMP DWORD PTR DS:[86CCE8],0

JNZ 111005RE.006B6BB0

MOV ESI,DWORD PTR DS:[<&WINMM.timeGetTime>] ; WINMM.timeGetTime

CALL NEAR ESI ; <&WINMM.timeGetTime>

MOV ECX,DWORD PTR SS:[EBP+2F8]

ADD ECX,0 ; changed to 0

CMP EAX,ECX

JBE 111005RE.006B6BB0

CALL NEAR ESI ; <&WINMM.timeGetTime>

MOV DWORD PTR SS:[EBP+2F8],EAX

LEA EAX,DWORD PTR SS:[ESP+46C]

MOV EDX,35F

PUSH EAX

MOV WORD PTR SS:[ESP+470],DX

MOV DWORD PTR SS:[ESP+472],EBX

PUSH EDX

JMP 111005RE.006B9AC7

Edit: Most recent clients even use a delay of 2500ms. Also before you ask for a hex, it is client specific; if you are skilled with a disassembler, look for MOV R32,35Fh (where R32 can be any 32bit register), there should be only one in the whole client.

Edited December 14, 2011 by Brian

[Damon]

Hi.

I open my client with HexEdit, but no way to found who change the Ms... (like all the quote, impossible to find a correspondance)

Someone can explain me pls ?

Thanks you

[Hayate Yoshida]

Hi.

I open my client with HexEdit, but no way to found who change the Ms... (like all the quote, impossible to find a correspondance)

Someone can explain me pls ?

Thanks you

This is not hex, this is x86 assembly. You need a program like OllyDBG or any other dissassembly program.

Edited March 19, 2012 by Shinon Yoshida

[e0706]

if you using 'windows 7', 'Enhance pointer precision' check off.

This option is 'Mouse properties' window in Control Panel.

I changed modified assem, but enable this option, delay will still remain...

sorry, i bad english...;;

Edited March 20, 2012 by e0706

[Hayate Yoshida]

if you using 'windows 7', 'Enhance pointer precision' check off.

This option is 'Mouse properties' window in Control Panel.

I changed modified assem, but enable this option, delay will still remain...

sorry, i bad english...;;

I'm totally confused by your post, Windows 7 has very little to nothing to do with this post.

[ralph00]

How do I actually find the strings? Can somebody give a detailed solution to this? Thanks.