I did Locoweeds tutorial and I am getting to much lag.
i was thinking becouse player always moves and then jumps back a little... is it posible that client sends his location to the server, continues moving then, meanwhile server sends his location to others including client that send it in the first place, so player gets old location and jumps back to it...
My question now is how to tell server not to send it back to the client but only to others???
that is if my teory is correct... if not just tell me how to reduce lag:D

Did you set dplay_smooth=0? I believe there are issues with the Dead Reckoning system in A6 that can cause the snap back, even on a fast network. dplay_smooth=0 should turn it off.

it helps realy just a little... still having lag... any other solutions??

I know I tried it months ago. It lagged for me too.

Interesting though, what loco said in this thread below regarding the multiplayer efficiency of 3DGS.

http://www.coniserver.net/ubbthreads/showflat.php/Cat/0/Number/716757/page/2/fpart/1/vc/1

Oh well, George is working on a new multiplayer tutorial thing. I'd like to see if it lags too?!?!

When you stop moving, does the entity seem to overshoot and then jump back? If so, this isn't really lag. The jump back is caused by the dead reckoning system (smoothing) overcalculating the location of the entity, and then correcting it. You can use ent_sendnow to 'send the location quicker'. It helps some but doesn't fully correct the problem.

It seems to me that when locoweed originally wrote his tutorial, he 'avoided' this problem by setting dplay_smooth = 0 to turn off smoothing.


Did you use var dplay_smooth = 0? Declaring it as a var is important. I don't believe it will work without doing this.

but for this there is ent_sendnow...if u stop moving just use this command and it won't do it anymore

Hi,

When you are first doing your intial multiplayer testing over the internet I would recommend starting with the simplest code possible and test the heck out of it.

Use F11 to see what is going on. Make sure to limit FPS dpending how you are sending data. If your FPS is running like 200 and you are not limiting how your data is sent, you could end up sending 200 updates per second over the network and the buffer will overload quickly, even on a LAN connection.

So start with a very simply program, test out each multiplayer variable and command one at a time and see what effect it has.

I would definately study all of the DPLAY variables, especially ones like DPLAY_ENTRATE, but study them all and test them.

Also know all of the multiplayer commands like ent_sendnow(), proc_local(), etc and test the heck out of them also.

For intial testing the Multiplayer Tutorial I wrote is really too complex test each multiplayer aspect individually. I just updated some very simply outdated barebones code tonight that makes testing one thing at a time much easier.

Here is the link to the updated simple Barebones code:
MultiplayerBarebones

Use some simple code like that and test everything you can think of to reduce network traffic before your code get's too big to test. Use F11, track bits per second being transferred, etc, the read-only DPLAY variables. The main variables to track are dplay_bps, dplay_bpspeak, and dplay_latency. Once you see what the DPLAY variables are doing you can deduce where the strain on your network is coming from.

Then add some projectiles to the simple code, test the projectiles as ent_create(), ent_createlocal(), proc_local(), proc_client(), test all of those type of commands one at a time and see how they effect how well the network performs.

Be thorough, test everything in a simple program before you use it in your main project. Do everything possible with proc_local(), like animation, basically do entity.nosend_everything but origin, angles, and the few things you need to think you need to send.

Anyhow, hope that helps some.
Goodluck,
Loco

Mucho thanks Loco...