Multiplayer Broken?

#21 thanks Pat for this fix. J

#22 Good info there Pat (and the fix). Thanks.

#23 Awesome, Thanks for the response... Multiplayer seems to get broken often you guys should try and connect to a server before release! :P would only take ~1 minute of your time

#24 If your talking about my posting. It was my fault. It appears I had created and recreated a datablock in some function script that was never ment to do so. It took me like 3 days after reinstalling to figure it out :/

#25 Alright I just tried it and when connecting to undercity I get an error saying that I do not have the appropriate FPS genre kit files and to contact the server admin, so I tried it on the blank room and it works and by accident I pressed f5 for the particle editor and it immediately booted the client with the aforementioned error... I don't understand this as I'm running both clients with the exact same contents in the folder

#26 Edit (I must have been really tired) This fix did fix my multiplayer. It did however introduce a new issue. The players are much choppier then they were. I suppose there is a simple fix for that but I just wanted to throw that out there.

#27 Jesse, did you compile back into Release? Debug will add a lot of overhead and if it is writing constantly it will cause it to stutter at times.

#28 Well, I'm using an i7 with 6 gigs of ram and a Geforce GTX 260 with 1 gig of ram. I did compile the Release build. The game itself runs just fine. I was talking about watching other players move around in the game.

#29 Thanks for the explaination on how you debugged Pat. This is exactly what I like to read. It helps me learn more about torque. Like you said it takes longer to document the error, than it did to find it and fix it. So thanks!

#30 What kind of latency are they getting to the server? Noticed this as well, but the other person is half way across the lag and the latency is around 1 second :-(. Haven't tried with someone with a decent latency (< 100ms or so).

#31 Well, They are gig ethernet cards and one computer is plugged right into the other so. since 1000ms is one second. I'm getting about 0ms between the server and client.

#32 See if changing your packet rates help, it sounds like a bottleneck caused by delayed packets.

$pref::Net::PacketRateToClient = "32";
$pref::Net::PacketRateToServer = "32";

Check out this thread by Steve YorkshireRifles Acaster.

Hope this helps.

#33 @Konrad I am not sure that giving the packet more room is a good idea. I mean every bit of data creates an exponentialy increasing problem. I want to design a Multiplayer game but it needs to flow as well. If looking at the code it says write( does one bit) and writeFlag( does one byte) that could be the reason right there. Changing a bit transfer to a byte without doing the rest of the modifications could easily cause a problem like delayed packets.

If the game's network packets are now bloated to the point where I can only have two players on an empty map and they chug around that is not good. I'm hopeing that its just desyncronization of some sort.

#34 Well, certainly, you could optimize the traffic by stripping out what you don't need. There are many features in Torque3D that are genere specific. Just look at the player class. You could start stripping out data right there.

Btw, afaik writeFlag always writes a bool, even if you feed a byte into it (is that at all possible?). The thing you need to look out for is the case when you push through more bits than what is neccessary (a byte for a bit, or a whole string instead of a tag).

There are certain data that need to be sent to the server and back to the client.. the rate at which a (technically, fix sized) packet is sent can be modified this way. The data you need to send might be more than what you can send at one time. The rest of the data - what you can't send right away - clogs up, and waits to go through with a following packet with elevated importance. This might be one of the reasons why you experience the choppy movement.

If your network can handle the higher rate, then by all means, let it do so. A worst case scenario will be the same lag - but this time the network bandwidth being the bottleneck. If you experience that, you can always go back to a lower rate and start concentrating on sending less data in those packets. If you have no more lag - the better.

You could also dynamically change this value by checking packets on the server, and instructing the client to slightly change its packet send rate on demand (if the server can't take the load).

There's definitely some room left for improvement, but the kind of optimization you describe will probably have the least effect and is the most time-consuming to do in a system that's been being tested for about 10 years now. Still, very important for a multiplayer game.

Someone, please correct me, if I'm wrong here.

#35

Quote:
The data you need to send might be more than what you can send at one time. The rest of the data - what you can't send right away - clogs up, and waits to go through with a following packet with elevated importance. This might be one of the reasons why you experience the choppy movement.

Exactly, That is what I thought. I have however come to a greater understanding. I don't think its the Torque Networking send / recieve since it dynamically increases and decreases from its preferenced limit.

In beta 3 it was optimized enough to have 10 players in game doing whatever. The network changes from beta 3 to beta 4 created enough bloating that the network packet sizes were too large and started to create a choppy effect I discribed with just 2 characters. I think not. It has to be something else.

#36 Hmm, I somehow didn't pay attention to this being a difference between the two betas. Sorry about that. Well, we were told how to debug network stuff right in this thread.. :)

#37 Hmmmmm....Jesse, I don't believe there were network changes from beta 3 to beta 4. There must be something else responsible for the choppyness.

Are you getting packet checksum spam in the console? This indicates that something about the net functions isn't being simulated on the client the same as it is on the server. When this happens, the server is constantly sending large packets (writePacketData/readPacketData) to "catch up" the client, instead of the usual, small updates (packUpdate/unpackUpdate).

#38 Nope I don't appear to be getting spammed with anything. It looks pretty clean as far as I can see. I seriously just installed Beta 4, Opened up the C++ code for the engine source focusing on the FPS pack. Loaded it and made the appropriate change to the writeFlag variable as requested. I then compiled and started up game. I know about the network side of torque its weird is noone able to reproduce this behavior?

#39 Edit: Nevermind, re-read your description. Not the fix.

#40 Opps um ya I must have been really tired. I corrected it :/