5017 Coordinate Issue

When players are walking their coordinates are being thrown off on the client side. I have double checked several other sources and I am handling them the same way and returning/sending the packets in the correct order. Is there a known issue with the 5017 client, or is there something i'm doing wrong? It seems as if i'm just not receiving all the packets. It seems to be worse the faster you walk (using cyclone).

Thanks in advance.

Just to confirm that you really are handling coordinates correctly, you're sending back the movement packet after validating it, right? So, if the client sends you a movement packet ([Only registered and activated users can see links. Click Here To Register...] for example), you use the direction to calculate the new coordinates and then send the packet back to the client. I assume you're doing this correctly since you say it's more of a timing issue. How are you handling parallelism in your source? Could it be that a race condition is occurring? Maybe values are being updated at the same time, and that's causing some synchronization conflicts. I doubt it would be a client issue; that's a pretty popular patch.

your dmap(s) might be invalid

Quote:

Originally Posted by Spirited Just to confirm that you really are handling coordinates correctly, you're sending back the movement packet after validating it, right? So, if the client sends you a movement packet ([Only registered and activated users can see links. Click Here To Register...] for example), you use the direction to calculate the new coordinates and then send the packet back to the client. I assume you're doing this correctly since you say it's more of a timing issue. How are you handling parallelism in your source? Could it be that a race condition is occurring? Maybe values are being updated at the same time, and that's causing some synchronization conflicts. I doubt it would be a client issue; that's a pretty popular patch.

I am indeed returning the packet back to the client, and I don't believe it should be the latter due to the fact I don't even begin populating the next buffer until the previous has been processed. It's something that is worth looking into though. Thanks.

Quote:

Edit: No other threads are adjusting the coordinates at all, so i decided to try something like this: if (Hero.Walking) { Console.WriteLine("Attempted to process multiple walk packets at the same time."); } await PlayerWalking(Hero); Hero.Walking = true; Process walk packet Hero.Walking = false; Still didn't have any luck with it though.

Quote:

Originally Posted by turk55 your dmap(s) might be invalid

Even if I completely ignored the DMaps, it should't throw off player coordinates with them just walking should it? (The client would prevent them from walking over things they shouldn't unless they did some editting)

Thanks for the feedback guys. I'll check it out.

When you say thrown off, is it that their walking is being thrown off when they remain in the screen, or is it actually that the server is recording them incorrectly? Like, if you stayed in the screen of another player, moved about, moved out of screen, and moved back in screen, when does it misstep?

Quote:

Originally Posted by Spirited When you say thrown off, is it that their walking is being thrown off when they remain in the screen, or is it actually that the server is recording them incorrectly? Like, if you stayed in the screen of another player, moved about, moved out of screen, and moved back in screen, when does it misstep?

A jump corrects the coordinates entirely. Walking off screen and back on screen doesn't fix the issue. It acts as if I don't receive some of the packets, so the server doesn't change the coords based off the direction. I have double checked the calcs while adjusting the x/y, and even took the calcs off of Redux and still no luck. The coordinates go off whether you stay on their screen or off of it, but it does correct when you jump.

Just for clarity: I check the coordinates the server has for the player using a command, and match them with the clients coords in the top left. After walking so far the coordinates will differ.

So, regardless of if the player is in someone's screen or not, the coordinates will differ between the client and server. It really sounds like a race condition is occurring somewhere. My advise would be to print each packet and coordinate change, and see if it's processing each packet. Count your steps, then count the packets processed and the coordinates changed. If you're processing all packets, try locking the function (temporarily) just to see if it's a collision occurring when you save the coordinates. Hopefully you can find the root cause with that.

Quote:

Originally Posted by Spirited So, regardless of if the player is in someone's screen or not, the coordinates will differ between the client and server. It really sounds like a race condition is occurring somewhere. My advise would be to print each packet and coordinate change, and see if it's processing each packet. Count your steps, then count the packets processed and the coordinates changed. If you're processing all packets, try locking the function (temporarily) just to see if it's a collision occurring when you save the coordinates. Hopefully you can find the root cause with that.

I would PM this to you but you can't receive messages. Would you be willing to talk over skype for a few and maybe take a look at it? I would be willing to pay.

I white-listed you. You said you have packet loss... and it just occurred to me now: are you splitting your buffer into multiple packets? If not, that would explain why some packets might magically disappear. Also, I require no payment. I'm just happy to help a fellow developer in the community. As a side note: I'll be releasing a public source on my board around this patch soon (4330). Don't know if that interests you or not, but I thought I'd let it be known.

Quote:

Originally Posted by Spirited I white-listed you. You said you have packet loss... and it just occurred to me now: are you splitting your buffer into multiple packets? If not, that would explain why some packets might magically disappear. Also, I require no payment. I'm just happy to help a fellow developer in the community. As a side note: I'll be releasing a public source on my board around this patch soon (4330). Don't know if that interests you or not, but I thought I'd let it be known.

Sounds good. I'm def. interested. As far as the buffer goes i'm not actually splitting it up. Wasn't actually aware the client would even allow me to do so. Do you think that would cause the issue?

Quote:

Originally Posted by 12k Sounds good. I'm def. interested. As far as the buffer goes i'm not actually splitting it up. Wasn't actually aware the client would even allow me to do so. Do you think that would cause the issue?

The buffer from your socket system doesn't just contain one packet; it contains multiple packets. C# doesn't know what's what in regards to a stream of bytes, which is why TQ has that binary header with the packet length. It reads in that length and splits the buffer based on that length. That's exactly why you're not getting your walk packets, you're processing one and then throwing away the buffer.

Quote:

Originally Posted by Spirited The buffer from your socket system doesn't just contain one packet; it contains multiple packets. C# doesn't know what's what in regards to a stream of bytes, which is why TQ has that binary header with the packet length. It reads in that length and splits the buffer based on that length. That's exactly why you're not getting your walk packets, you're processing one and then throwing away the buffer.

Is the walk packet the only packet that does this? I would of thought I would have a much larger issue than this if that's the case.

Quote:

Originally Posted by 12k Is the walk packet the only packet that does this? I would of thought I would have a much larger issue than this if that's the case.

No, it's not the only one. It's likely that for this instance, Nagle's algorithm for TCP optimization is screwing you over. The packet is only 10 bytes for that patch (or something small like that), and so it's likely that the operating system is waiting for more packets to pool up before sending data. It's a very small window of time, but if you're using cyclone or something more rapid, it's more likely to occur. The client also does its own buffering on sends. On the server side, the more players you have, the more likely data is to buffer since you can't readily service every request. Just in general, packet splitting needs to happen. It's going to be a problem you'll experience on every patch.

Quote:

Originally Posted by Spirited No, it's not the only one. It's likely that for this instance, Nagle's algorithm for TCP optimization is screwing you over. The packet is only 10 bytes for that patch (or something small like that), and so it's likely that the operating system is waiting for more packets to pool up before sending data. It's a very small window of time, but if you're using cyclone or something more rapid, it's more likely to occur. The client also does its own buffering on sends. On the server side, the more players you have, the more likely data is to buffer since you can't readily service every request. Just in general, packet splitting needs to happen. It's going to be a problem you'll experience on every patch.

You are now my lord and savior. Thanks man. Greatly appreciated. Tested and working flawlessly.