Bitstream Assistance please

#1 Have you tried increasing the packet rate?

$Pref::Net::PacketRateToClient = 32; //Rate controls for client/server communication; ranges of 1-32
$Pref::Net::PacketRateToServer = 32; //Rate controls for client/server communication; ranges of 8-32
$Pref::Net::PacketSize = 450; //Initial size in bytes of the comm buffer (may be enlarged if necessary); range 100-450.

How many clients are connected? How fast is the server's connection?

#2 Thanks Peter but yes I have done that already. I have gone through and severely optimized my code but apparently there is still something holding me back.

#3 Hi Ron,

Your description is very vague so it's difficult to help you. Specifically:

Quote:
alot of the data is not transferring properly.

"Properly"? Do you get packet errors? Randomly or always on the same type of object? Or do you get into the game but with incorrect simulation? Huge difference.

Quote:
I am getting a lot of lag with those that join

For players joining, or for players already ingame? Both? If the former, does the lag end when you reach inside the mission, after the loading process has finished?

#4 What kind of computers are involved (client and server) as well as what kind of Internet connections do they have?

What is the "ping" between the client and server?

Do you have any packet loss statistics?

#5 OK. I have no extra data because I have no debug failures at all or anything in the console log that declares a failure.

Some of the data loss is for example, I have my Updated Terrain Deformation resource installed, it worked fine in single player and even worked flawlessly back in January with no code changes to it. Now the data is not updating the terrain updates properly as if it is always a few steps behind where it should be. What I mean is that if you do multiple deformations what the client that joins the game see is always a deformation or two behind what the client that hosted the game sees.

If the client that joins the game is mounted to a vehicle the lag is intense, but the client that hosted sees everything as if normal.

Don't just focus on those two, they are just two examples of what I am seeing, there are several more with particle emitters, weapon fire and so on.

The ping between the client and the server is very (around 10 and lower) but I am hosting on a private LAN so that is why.

Now I had tried the same tests with my backup version from January, all pass and it looks fine. However there have been a lot of updates since then. That is why I am hoping there is something that can just call out the areas that are causing the issue. By the way the LAN isn't the issue, it happens outside the LAN too.

#6 OK now I have some interesting results that give me a bit more to go on or maybe someone can help me easier. I completely removed the Menu Mission Resource from my game. Now I figured out that it was loading the Menu Mission everytime you would host or join a game. This actually fooled me for bit because it made it seem like the ghosting system was actually working, but what was really happening was I was actually getting everything from the mission menu server running in the background.

So apparently my problem is created by a failure in ghosting. I have no idea what could do it because I actually reverted my player and vehicle code back to stock TGEA for the sake of testing, it did not help at all.

What confuses me is if it is not caused by my code, what else can do this?

#7 You might want to check out Ed Maurina's new book, as it goes through the Torque startup sequence in some detail. It sounds like your app is maybe failing to do one of the startup steps that the networking requires.

You should also try running with the TORQUE_DEBUG_NET #define enabled, that adds extra networking debugging. (See torqueConfig.h.) And of course if you're not running a debug build you definitely want to do that, too.

If you can identify the source of the problem in more detail (ie, some objects aren't ghosting ever, network data is being lost or corrupted, or something else) you could do more focused debugging, add log statements, and start poring over the output to find the problem. It's still very vague what's going wrong - could be any number of source issues, from memory corruption on down to an obscure bug in Torque.

Worst case you'll want to take a stock version of Torque and add functionality step by step till everything either works or the problem reproduces itself.

#8 Thanks Ben. Your always a big help. I didn't even think about the DEBUG thing and yes I agree with you about the startup steps since I have actually gone back and made my code pretty much stock other than a couple of bug fixes posted here in the forums and still get the same result. It tends to make me believe that this is something I have messed up in the scripts.