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).
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 ( 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.
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 ( 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)
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?
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.
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.
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?
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.
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.
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 ******** 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.
No, it's not the only one. It's likely that for this instance, Nagle's algorithm for TCP optimization is ******** 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.
Strange issue on my 5017 source... 07/30/2011 - CO2 Private Server - 7 Replies My 5017 Client refuses to accept a v5017 Char Info packet....
Client close.
I even tried it with LOTF packets... as they should work....
However, if i copy and paste a packet from UCCO it logs the char. WTF?
Tried with Different clients, different packets... nothing.
COnquer coordinate in cartesian coordinate ? 02/07/2011 - CO2 Programming - 5 Replies i m working on my minimap in pro4never proxy, i cleaning map from coquer site and put in picture box
now i want to locate my char in this minimap likes in game :) but the coordinate in game are different view of classic cartesian coordinate :)
some1 had module to trasform Conquer coordinate in cartesian coordinate ?
or explain me why cood traslation in math not work :// :handsdown:
i m working on this sistem
[RELEASE]Big Project..5095,5065,5017,5017 (command Server) 10/01/2009 - CO2 PServer Guides & Releases - 23 Replies Hi,
Yes i made a big project with my self by my self i host i edit i control i code.
The Project contain 3 Co plvling Servers and 1 Command server the plvling servers are Snow Server and Treasure island .
snow server works with 5065 client and it have alot of edits , adds , well i have made 135 gears and you can upgrade it in market from De La Vega for 250k CPS for each item also you should get 1 blessing amulet to make dmg -1 and you can get it by killing 1000 Birdman or 1000 Snake man or...
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.
