Unbalanced network traffic

#1 I get that error message in our build too, though we haven't had any problems.

#2 Thx Stefan

Do you see it once or every time a controlled object does "something"?

I get a checksum line for every tick if I control a plane - but only 1 (when the client connection is made) when I have the exact same plane just sitting in the mission without an attached controlling client.

Weird eh?

Also on death I get a fatal exception with mismatched netevent id.

#3 Sorry, didnt notice there was a reply here.

I get that line 4 times at the startup of the mission, actually. Then I never see it again, not even when another player joins. Seems to me there is indeed something wrong with the internal checksumming stuff.

May I ask, what is considered unbalanced network traffic? I do get jumps from 0.02 to 0.17 kilobits / second, and that is news for me because it was stable before.

Edit: Kilobits, not bits.

#4 Unbalanced as in the checksums are mismatched - usually means that your pack/unpacks do not match (if I understand it correctly)

#5 Okay. Well, when Torque_Debug_Net is defined, mismatches should be flagged AFAIK.
Do you use interiors / sgLights in your case, Thomas?

#6 None of either!

Until I saw the problem in a clean MS4, I thought it was something in our own code.

I'm unsure if its ment to do this, or its a bug.

Brian Ramage - any idea?

#7 The packet data checksum mismatch just means that the client and server are getting out of synch. We fixed some issues in the observer cam recently - they might not have been proofed against the networking.

#8 We had some problems with that a while ago - but that in particular was related to the timer. Clark made a fix to the timer code probably back before MS3 and it's been OK since, so it's probably not that. You should double check though and make sure your windows timer code is up to date with stock TSE.


I've seen this happen a lot in vehicle code when you are writing your own physics. If you don't keep all the variables in synch between client and server, or if some little change is happening on one end and not the other, this will occur. Make sure all the physics calculations are only in the tick updates and not in advanceTime() or interpolateTick().

One thing you can do is drastically remove movement calculations until it stays in synch, then add more back in until you find the bit that is causing the problem.

#9 Thanks guys - I'm pretty sure its not a timer problem. Will doucle check the orbit stuff - as that doesnt work anymore for us (same scripts as before). When you die, it kicks you into orbit cam. And that crashes my machine when running debug with a unknown netevent. Thats why I started looking at the network packages in the first place.

So that might be the bugger. Will report back later after checking

---------------

OK - reverting back to MS3 camera.cpp/.h makes our camera modes work again + doesnt crash when we die + doesnt fubar our clientCommands when dead.

The 2 differences you implemented as far as I can see are a moved compression point + changed code to not set the render transform anymore.

Will do a few simple tests to see what it is that fubars our code.

(The packet checksum disagree still appear though - but they are not fatal this time)


--------

Little more testing

Moving the compression point in MS3 camera.cpp in the readPacket as you have done in MS4 camera.cpp brings back the error. Totally fubars our orbit camera and crashes the engine sometimes.

Only fixing that doesnt rectify all problems, so thats not the only bug. But there is definitely something wrong in that camera code.

#10 Thomas - you are running w/ the net debug macro, right? Debugging without checking that first is gonna be hell.

#11 Ben - yeah. Running with the net debug macro! but it doesnt tell me much to be honest. Except it crashes with a checksum disagree in NetEvent.

I wonder why you even changed the old MS3 camera code. Worked fine! And the changes in MS4 dont seem to do much else than move bits around (except the removal of the setrenderpoint()

#12 OK - found the 2 bugs in the code. Was actually "easy".

But the bugs are crazy - dont know why you guys even changed it from MS3 to MS4. Failed merge?

In readPacketData move the setCompressionPoint back up again, so the code reads

void Camera::readPacketData(GameConnection *connection, BitStream *bstream)
{
   Parent::readPacketData(connection, bstream);
   Point3F pos,rot;
   mathRead(*bstream, &pos);
   bstream->setCompressionPoint(pos);

and delete the setCompressionPoint 10-15 lines further down.

Then also in readPacketData line 355 change this

S32 gIndex = bstream->readInt(10);

into

S32 gIndex = bstream->readInt(NetConnection::GhostIdBitSize);

Orbit camera now works again without crashing the engine :-)

#13 Ah, fantastic. Thanks Thomas!

#14 I reverted the camera code because the TGE camera code that was merged in has broken interpolation on the camera. Having your camera update only once a tick makes it look really choppy.

Thanks for the fix Thomas, seems to work fine.