Movement lag compensation code.

Has anyone a good insight on how the movement lag compensation works?

The gui/game client seems to ignore the x/y position it gets via NEW_TICK for the own character (except of course for the initial values) and to just spam whatever coordinates the character is at. But when I ignore my own characters x/y values from NEW_TICK packets in my bot's code and just send whatever x/y I think the bot should be at (i.e. the x/y values my move_towards() method returns ... and yes it knows about my chars speed and the terrain) my bot just gets kicked after like 30-40 tiles BUT ONLY on laggy servers. It works like a charm on servers without lag. Are there delta frames at which the difference of the client x/y and the NEW_TICK x/y need to be correted?

It seems as if the bot has to care about what NEW_TICK has to say about the x/y values the server think the bot is at. I don't quite get it ... the server really should accept any x/y that is within a plausible threshold?

thank you for any input ...

Nobody happens to know how the Flash client does it? Does it ignore your own x/y as received by NEW_TICK completely (except for the initial packet of course) and just send out whatever x/y you are at? Ignoring the x/y from NEW_TICK gets my bots kicked on laggy servers but I refuse to believe that the Flash client would care about the x/y of your own character at a per NEW_TICK packet level? Guess I'll have to find out myself ...

I wanted to look into it but I haven't had the time yet (I wirte something where I need to know). I think, the client ignores it by default but if the distance between the new_tick position and client position reaches a threshold, the client corrects its own position thus resulting in rubberbanding sometimes (if a long time passes between new_tick updates). Anyway that correction is small and rare enough not to get noticed probably. It's just a guess though.

Originally Posted by DatCoder

I think, the client ignores it by default but if the distance between the new_tick position and client position reaches a threshold

That's what I thought. If you can confirm this and share with us how the threshold is calculated it would be awesome.

I wanted to test different $maxDiscrepancy or $maxDelta values this week but didn't have much time. But if you can look it up in the game's source it would save me a lot of time. Reading obfuscated action script is not something I am good in ... ;-)

Originally Posted by eth0nic

I looked into it, but I could not find anything alike in the client. It seems the player position in the NEW_TICK gets always ignored by the client and the server simply always sends back what the client sent previously as TELEPORT or MOVE packet. Even the first NEW_TICK position is ignored (the UPDATE is not though).
I could not reproduce your problem, blocked the NEW_TICK player postion, went to the laggiest server and nothing. Then I generated random floating point numbers as the position but still nothing. I will look into it a little bit later, but probably your problem is not caused by the NEW_TICK response.

Do you know by any chance how the server uses the records field in the MOVE packet? Is it only for a more accurate guess whether you dodged a projectile or got hit since the 200ms NEW_TICK is not enough to determine it? I think if it has another reason, that can be release why you get kicked. There is another myth regarding the MOVE packet that I want to sort out so I will probably write more about it later.

Originally Posted by eth0nic

;-)

This has nothing to do with anything, but why does everyone use this smily face? just use

C: or =D
This one looks ugly no offense :-)

Originally Posted by DatCoder

I could not reproduce your problem, blocked the NEW_TICK player postion, went to the laggiest server and nothing.

I guess it has to do with just moving too soon ... I'll try giving the whole thing a few ticks as there seem to be huge delays between the CREATE_SUCCESS ACCOUNT_LIST and the first few UPDATE and NEW_TICK packets.

Originally Posted by DatCoder

Is it only for a more accurate guess whether you dodged a projectile or got hit since the 200ms NEW_TICK is not enough to determine it?

I suspect that is is only for changes in direction within the 200msec. Like if you press left/right/left/right like mad for like 190msec that jitter will not be seen by the server otherwise. I haven't looked through the source myself but that is what I suspect.

---------- Post added at 09:44 AM ---------- Previous post was at 09:42 AM ----------

Originally Posted by DatCoder

Is it only for a more accurate guess whether you dodged a projectile or got hit since the 200ms NEW_TICK is not enough to determine it?

So yes ... basically just for that ... or for really amazing fine tuned movements like you see in some mouse-avoidance flash games ;-)

---------- Post added at 09:45 AM ---------- Previous post was at 09:44 AM ----------

p.s.: thank you for saving me a lot of time. kudos!

Is there a serverside check for whether the character has moved into an area for which the server did not yet provide the tile information for? My bots still get kicked on laggy servers during rubber-band-warping 2-3 seconds after they join Nexus and move from the spawn to the realm portals ... i.e. if they lag they will warp there and get kicked. Need some more testing ...

Originally Posted by eth0nic

Yes. Black tiles function exactly the same as dark water and walls in most dungeons. If the object hinders your view, you cannot pass it.

Originally Posted by eth0nic

The server keeps track of what tiles it has sent you before. By default the tiles that haven't been sent in UPDATE are noWalk tiles and if you move on it (blue in nexus, black in dungeons), you get kicked. When I tested that teleport hack, I could teleport only to places what I have previously visited already, keep track of the tiles and if the next one you want to move on hasn't been discovered yet, wait for UPDATE.

Roger. So this is one reason for getting kicked ... but there seem to be others. I checked for the proper speed ... i multiply the maxSpeed with 0.65 just to be safe (0.66 is the speed modifier for "pool" tiles in nexus) ... still getting kicked randomly ... will test later today.

Here is my moveTowards func() ... don't think you can do much wrong here though ... I also tested it with a bot that just follows me around ... speeds are right ... on servers without lag there is 0 problem. Maybe it has to do with TELEPORT ... do you need to leave your position unchanged for 1 Tick after TELEPORT as well? Like with the initial NEW_TICK packet?

Code:

 
my $speed=$myself->stats(22) + $myself->stats(50);
my $tilesPerSecond=4+5.6*($speed/75);
my $tilesPerTick=$tilesPerSecond*0.2;
$tilesPerTick*=0.65;
my $pos=$rotmg->moveTowards($myself->pos,$goto,$tilesPerTick);

my $move=Rotmg::Packet->new('MOVE');
$move->tickId($packet->tickId);
$move->time($rotmg->gameTime);
if(defined $pos){ 
 $move->pos($pos);
}else{
 $move->pos($myself->pos);
}

Code:

sub moveTowards {
 my $self=shift;
 my($pos1,$pos2,$speed)=@_;
 if($pos1->x==$pos2->x && $pos1->y==$pos2->y){ # distance==0
  return $pos2;
 }
 my $distance=sqrt( ($pos1->x-$pos2->x)**2 + ($pos1->y-$pos2->y)**2 );
 if($distance<$speed){
  return $pos2;
 }
 
 my $vec_x=($pos2->x-$pos1->x)/$distance;
 my $vec_y=($pos2->y-$pos1->y)/$distance;
 $vec_x*=$speed;
 $vec_y*=$speed;
  
 my $pos=Rotmg::Pos->new($pos1->x+$vec_x,$pos1->y+$vec_y);
 return $pos;
}

---------- Post added at 08:52 AM ---------- Previous post was at 07:11 AM ----------

This is driving me nuts ... they just get randomly kicked without any obvious reason or under any reproduceable circumstance when ignoring NEW_TICK and just spamming out their own client-side-calculated x/y values via MOVE. Even on non-laggy servers some get kicked after like a minute.

Time to debug this I guess ... this will be "fun" ...

No, you don't have to wait after teleport, at least I don't do that but it can't hurt if you do.
I believe what you are missing is that the MOVE packet should be completely independent from NEW_TICK and the server. There is nothing that guarantees that you will get exactly 1 NEW_TICK packet exactly every 200ms and it seems you not just calculate with 200ms but actually believe that 200ms that the server sent is really 200ms. No, it's not.
Forget about the tickTime and tilesPerTick.

If a NEW_TICK is recieved you should get the difference between the time of previous and the current newtick in gameTime, let it be timeDiff. Get the current position and add the timeDiff*tilesPerSecond*tileMultiplier to it's direction. Send the MOVE with the tickId, gameTime, newPosition. Now save the time of the current newtick as previous newtick. In pseudo code:

Code:

if not prevTickTime:
  sendMovePacket(tickPacket->tickId,gameTime,position,[])
  prevTickTime := gameTime
  return
currTickTime := gameTime
tilesPerSecond := 4+5.6*(speed/75)
moveDirection := (target-position)/distanceof(target,position)
newPosition := position+moveDirection*tileModifier*tilesPerSecond*(currTickTime-prevTickTime)
position := distanceof(target,position) < distanceof(newPosition,position) ? target : newPosition
sendMovePacket(tickPacket->tickId,gameTime,position,[])
prevTickTime := currTickTime
return

As you can see the whole thing has nothing to do with that 200ms and the tileModifier is the multiplier of the current tile, I don't calculate what's between them and I think the server does neither (I haven't got dropped because of it yet). If by any chance it does, then you can calculate the average speed by checking what tiles are there between your position and the new position. Hope this solves it...

If that was the reason my bots wouldn't work without a problem if I don't ignore the x/y in NEW_TICK. I always sent MOVE in response to NEW_TICK and it never made any problems whatsoever. They have been running for thousands of hours.

But it is good to know nonetheless. Will rewrite the code accordingly. I will debug it later and report my findings! Thx!

Originally Posted by eth0nic

If that was the reason my bots wouldn't work without a problem if I don't ignore the x/y in NEW_TICK.

You should ignore everything in the NEW_TICK except the tickId. The position I talked about is not the position of NEW_TICK, but the one you store in the client and always recalculate. In the pseudocode only the "tickPacket->tickId" is part of the tick packet. Note that I edited the code a bit (the inital value part)

I fully understand what you are saying. I just don't see how this would cause the kicks. I had NEW_TICK always trigger my MOVE packet and it never made any problems. I will change the code to make MOVE deltaTime triggered and not NEW_TICK triggered ... but that most likely isn't the problem. My bots have used NEW_TICK as a trigger for a year or longer and never got kicked. But maybe relying on NEW_TICK's x/y slowed them down so much that the packet timing wasn't an issue. They were moving quite a bit slower than the normal client which ignores NEW_TICK's x/y.

Will report.

Movement lag compensation code.

Post a Reply

Similar Threads

Tags for this Thread