Ping, Lag & Co.

[MetEoR]

Hey guys, how much constant lag do you have when you play SSTSE online?

Mine is the most times to 300-350 :down: except sometimes whch arrives so 200-170 :P (and in RARE cases, under 100).

[Fifth]

That's normal in serious sam that you have got the lag. People should stop whinin' about the lag etc. because it's the same for everyone.

[Brandon]

That's normal in serious sam that you have got the lag. People should stop whinin' about the lag etc. because it's the same for everyone.

true but ii only say lag when there really is lag like when it spikes to 1k+ anything under up to 600 is pretty tolerable

[Fifth]

true but ii only say lag when there really is lag like when it spikes to 1k+ anything under up to 600 is pretty tolerable

:thumbs:

When I can't move. ;)

[Die Hard]

I get 60000 ping all the time and still beat everyone :thumbs:

[Xeno]

I get 60000 ping all the time and still beat everyone :thumbs:

damn, this guy own ! :D

I also only say sometimes the word "lag"
and I get banned of Exodus-R-Us time ago
they said they are gonna unban me of their server but I'm still banned, whatever,
I don't want to visit that server :) only 6 slots:down: and american server:down::down:

[Nitro]

I didn't get lag because I tweaked the connection files. The only solution is to fix the game yourself because the makers of the game were too strung out to fix it themselves.

[DiTomasso]

damn, this guy own ! :D

I also only say sometimes the word "lag"
and I get banned of Exodus-R-Us time ago
they said they are gonna unban me of their server but I'm still banned, whatever,
I don't want to visit that server :) only 6 slots:down: and american server:down::down:


how do you know you are still banned, if you don't want to visit that server.
start / rent youre own server, instead of whining about some one else his server.
you should be cratefull to those who spend there time and money, so that we/you can play.

[ObScUr3]

true but ii only say lag when there really is lag like when it spikes to 1k+ anything under up to 600 is pretty tolerable

Agreed, My lag means spikes like (200,876,450,198,674) :thumbs:

[ObScUr3]

I didn't get lag because I tweaked the connection files. The only solution is to fix the game yourself because the makers of the game were too strung out to fix it themselves.

Maybe, but when u fix ur connection u cant use it.
Ok ping like 90 but too much spikes if u dont have an awesome connection.:thumbs:
(I have this problem)

[Nitro]

Maybe, but when u fix ur connection u cant use it.
Ok ping like 90 but too much spikes if u dont have an awesome connection.:thumbs:
(I have this problem)

I have 30MB/s connection but that honestly shouldn't matter, unless you are using 256kb/s DSL or something ancient like that.

[MetEoR]

That's normal in serious sam that you have got the lag. People should stop whinin' about the lag etc. because it's the same for everyone.

No it is not. Everyone gets always different lag, and the player's gameplay is very influenced from the lag. Sometimes I shoot to other players and a hit which should cause 50 of damage, causes them just 10... (as exemple).

[DiTomasso]

No it is not. Everyone gets always different lag, and the player's gameplay is very influenced from the lag. Sometimes I shoot to other players and a hit which should cause 50 of damage, causes them just 10... (as exemple).


try cod2, same problem :thumbs:

[Siron Ex]

the best cure for your lag is by pressing alt/ctrl/del and end task:thumbs: also gives us a break from the whining:thumbs:
ahahaha :D thx for the laugh hug

get some skills instead of crying lag in the game

[Ibrahim]

I had 30 PINGS in DZF SERVER 2 weeks ago.

But now I have always 56 - 100 PINGS in PUBLIC SERVERS (FIGONA & DZF SERVER)

If I get problems with my Connection then my PING is 250 - 60000 ......

[BOA]

I get 60000 ping all the time and still beat everyone :thumbs:

WOW.:eek: Or as Dafosia would have said " youdaman".:D

[Caged Anger]

Serious Sam and Lag are synonomous with each other, and if you don't know that by now then you shouldn't be playing sam. Take it or leave it, its your call but to come here just to ask about lag is stupid. Of course everyone has lag, you think you are unique? Must be new to gaming...

Hey Nitro, you mind pointing to where you learned to tweak it? Would be interested to see what you changed to make it better. :)

[Nitro]

I've posted all of that many times...I'm to lazy to find all those tweaks again. However, off the top of my head, start out with tweaking your BPS settings (everyone should have their own settings specific to their internet connection speed). Then, throw out all the detailed textures in the maps and replace them with concrete Q3DM17-style textures. Turn off any useless crap such as shadows, etc. Add tweaked command codes into your startup.ini file (this is the part I'm not going ot take the time to look for). There's more but if you're smart, you'll find my old topics.

[MetEoR]

Serious Sam and Lag are synonomous with each other, and if you don't know that by now then you shouldn't be playing sam. Take it or leave it, its your call but to come here just to ask about lag is stupid. Of course everyone has lag, you think you are unique? Must be new to gaming...

Hey Nitro, you mind pointing to where you learned to tweak it? Would be interested to see what you changed to make it better. :)

I haven't opened this topic because I don't know anything about lag and gaming... I'm not new, and I perfectly know what is the lag and why there is; I just wanted to see how many people who play Serious Sam TSE multiplayer have a high lag and how many ones a low lag..

[ObScUr3]

I have 30MB/s connection but that honestly shouldn't matter, unless you are using 256kb/s DSL or something ancient like that.

I should have 4MB/s connection but with the most of test it arrives 640Kb/s LMAO :P

[Nitro]

I should have 4MB/s connection but with the most of test it arrives 640Kb/s LMAO :P

THen you are either capped by your ISP or you are using a test center that is very far from your location.

[Nitro]

just found some of my old posts since im bored out of my mind

How to minimize lag and stuttering

Before reading this, make sure you know how to use console.

First of all, try to connect to servers that will give you a lower ping. Even though the ping shown in Arcade is not the exact measure of the real ping you will have in game, it is a good point to start from. Also note that if your connection to a server is dropping packets, it might be better to try one that has greater ping, but doesn't drop packets. In some cases it is possible to compensate even for the packet loss, but it is better if there is none. It all depends on different factors, and you will have to experiment. Here we will explain how to do it and what to pay attention to.

To adjust your settings, you need to be connected to a game server of choice, so you can see how it respons on the settings. You might have to readjust depending on the server you connect to. For connections of lower quality you will need different settings than for a low ping stable connection.


Diagnostic Tools

When connected, you should have the diagnostic tools turned on. Those tools are the latency display and netgraph.

Latency is turned on with the console command 'hud_bShowLatency=1' and it shows your current ping in the lower right part of screen. The ping is shown in milliseconds and is a smoothed value averaged over a few last seconds. Lesser value is better. All below 100 will give you excelent experience, but is usually not possible with a plain modem connection. Modem users should expect between 200-500 and it can all work very smooth if there are not too many dropped packets and your framerate is smooth otherwise.

Netgraph is turned on with 'hud_bShowNetgraph'. It is displayed as a vertical graph of horizontal lines scrolling up in the loer right part of screen, just above the latency. Netgraph shows how your ping varies with time, whether your connection is dropping packets and if you have any other instabilities.

Each line in the graph represents one packet you receive (or don't receive) from the server. Length of the lines shows its latency - full row equals 1000ms, so one half equals 500ms etc. The color of the line shows type of the packet and its other characteristics:

GREEN:
This is a normal action packet is received in sequence. All is well. The shorter the line is, less you are predicting and the better will your accuracy be.

RED:
Packet is missing. Your computer must request resend from the server before proceeding. This will cause a complete halt of the game or small stuttering, depending on your ping. It can be compensated.

WHITE:
A non-action sequence is received. This happens when the game is paused, when you receive chat messages, new players are joining, someone has changed his/hers model, nickname, or other settings and similar. While the game is under pause, you will keep receiveing a steady stream of those. White lines are completely normal and does never indicate any problem.

BLUE:
A replicated action is received. This means that packet stream from you to the server is unstable, so the action buffer emptied and server had to make your player repeat the last action you did with keyboard/mouse, since it didn't receive the packet from you in time. It can be compensated.

YELLOW:
An action was skipped. This means that server action buffered overfilled and server had to drop one of the actions you did. This is similar to BLUE and they usually come in pairs. when you receive blues you always receive yellows and vice-versa.


Client settings to change

Here is the list of settings you need to change in order to set your connection well. These are all client-configurable variables. This means that event though some of them control the behavior of the server, they are all configured by each client independently on their own machines. If server needs to have some setting it is then automatically transmitted to it when you change it in console. Allow about a second for a setting to take effect.

cli_bAutoAdjustSettings:
Initially, 'cli_bAutoAdjustSettings' is set to 1. That means that engine will automatically adjust the settings for you. If it doesn't work well, you have to first set 'cli_bAutoAdjustSettings=0' or it will snap back everything you try to change. After you have set autoadjustment off, you can proceed with finetuning.

cli_bPrediction:
This controls prediction. It is a simple toggle: 'cli_bPrediction=0' turns it off and 'cli_bPrediction=1' turns it on. Prediction removes lag by predicting what will happen a few fractions of seconds ahead before even receiving that information from the server. It can predict your own movements perfectly, since you play on that computer. The movements of enemies in coop will also be predicted very acurately, especially if some enemy is attacking you. Movements of other players are not very predictable since they are humans and tend to jump around quite a bit, but the prediction system will at least try to smooth that out.

If your lag reaches 100ms (or even 50ms if you are very sensitive to lag), you will want to have prediction turned on, or it will feel very strange and sluggish. If prediction is on, it effectively removes any lag you can feel.

cli_iBufferActions:
The variable 'cli_iBufferActions' controls size of the action buffer on the server. That buffer compensates for the lag variation. Its values range between 1-5 usually. Default value of 1 actually disables buffering. Each unit above gives you 50ms of buffer at server to compensate for lag variation. So, if your latency varies between 200-300ms you will need at least 3 buffers - 1 is initial and 2 extra to account for that 100ms variation. Too high buffering will just add additional lag to your game and you don't need that. Always increase/decrease by one and see what happens.

Note that if you use prediction, you _have_ to set buffer to at least 2. Using prediction with buffer set to 1 can cause stuttering.

cli_iMinBPS:
This controls incoming bandwidth from server to client. It is stated in bytes per second, and is usually refered to (in net gaming community) as 'rate'. This is ammount of data server will send to your client per second. It controls how many times a server will send you one packet. By default it doesn't resend any packets to you, assuming that your connection is stable. But if your connection is unstable, you might need to increase this and by that way compensate for the lost packets. You should usually try with settings in the range 1000-3000. If you have a 56k modem, don't try to go above 5000, or you'll choke it. You can never set this too low, because it always sends at least copy of each packet. You can only make it send more than default.

[Nitro]

Be careful when you're tweaing becuase in 1.05, I tweaked them where the lag is 60ms for a US server but I get a stabilizing connection every 10 mins because of a missing packets. dont make it too low or too high. if u screwd up and get my problem, fix it like this

ABOUT SYNCBADS
==============
WHY IT HAPPENS
--------------
The whole network system in Serious Engine is based on 'virtual-input method'. That means that the entire state of the game (called SessionState) is exactly same on all computers, both on host and on clients. Whatever one presses on his keyboard/mouse is sampled by his computer and sent to the host 20 times per second. That 20 Hz interval is called one 'tick'. Each sent packet is called PlayerAction. Now the server gathers PlayerActions from all clients and for each tick it packs all PlayerActions in one large packet called AllActions, then it compresses it and sends it to all clients. The AllActions packets drive the game time. With each AllActions packet received, the SessionState on the client computer advances one tick (0.05s) in time. If the initial state is same and AllAction packets are same and properly sequenced, SessionState situation should always remain same on all computers. You can think of it like numerically integrating a function. You have a start value and values of df/dt for each interval.

That is the base of the system. On top of that there is a lerping system that smoothens things out for FPS!=20 and prediction system that locally executes few ticks ahead before actually receiving the AllActions from server.

Now, if everything is right, the situation should always be same on all computers (pseudo random seed is part of the SessionState, so it is same too, no real random in fact). That requires very careful AI implementation. And I mean _very_ careful. We must take care we don't do anything that is random in any way, anything that makes SessionState depend on client frame rate, models loaded, local settings, or similar. That can be a real problem. Also coupled with prediction, since the predictor entities must not interact with the rest of world. It seems like an unattainable goal, but it is not really that complicated in most situations. That is the only solution so far that has the performance capabilities we want, and we will have to live with it.

Now, to detect if something goes wrong, so we can debug it (and also to prevent situations like 'I killed you!', 'No, I killed you!' - what usually happens when it goes out of sync) - we employ the synccheck system. Every few ticks, all SessionStates create checksums of some relevant entities and send them to the server. The server then checks if the CRCs from client equal the CRC from its local SessionState, and does some actions if some fails.

Now what can go wrong:
1) "SYNCBAD: Client '%s', Tick %.2f" - some client has sent synccheck for given tick in time, and it was wrong
2) "SYNCLATE: Client '%s', Tick %.2f" - server has just received a synccheck from the client, but the tick that the check is for is so old that the server no longer keeps it in buffer. (buffer size is controlled by net_iSyncCheckBuffer). Occasionally, on very low pings and with a very slow server, the client can actually be faster than the server, so it generates a similar "SYNCLATE". These are both, non-fatal.
3) "No valid SYNCCHECK received for too long!" - either because of too large ping or too much packet loss, server has not received any syncheck from a client for 2x the size of syncheck buffer on server, and the client is being kicked out.

2 and 3 will happen if the client has problems with his/hers connection, and is dropping packets and having extremely low frame rates. These are not a problem. But when making a mod, you must ensure that your code does not produce the problem under 1.


HOW TO DEBUG
------------
The behavior of the server when bad syncs start to happen is controlled by these cvars:

ser_bPauseOnSyncBad:
server pauses immediately when a syncbad is detected.
-
ser_tmSyncCheckFrequency:
How often should clients generate sync-check (in seconds). The value is taken at server start and frozen for entire duration of the game.
-
ser_iExtensiveSyncCheck:
DEBUG: Do extensive sync checking
0 = minimal (default)
1 = check all players and movers
2 = check all entities in world
3 = check all entities extensively
This must be set on the server before the game is started.

ser_iKickOnSyncBad:
Determines how many bad syncs will a server tolerate before kicking a client.
0 means no kicking at all - note that that can lead to complete
desynchronization of a game.
-


By default, pausing is off, extensive checking is off, kicking is set to 10 bad syncs and frequency is one second. It means that if something really goes very much out of sync, the client(s) in question will be kicked to assure the game consistency.

If you wish to debug bad syncs, you will have to turn pausing on, turn kicking off and put the frequency down to 0.05. It means that it will check as often as possible and that in event of any bad sync situation the game will be paused immediately. Then when the game auto-pauses, you type cli_bDumpSync at each client, and at server. It will generate the file 'Temp\SyncDump.txt'. It contains data of all entities considered when doing the synccheck CRC. Then you use some diff tool to find what went wrong, by examining differencies between the dumps. We used the WindowsCommander's built in differ, and it works really great.

Also, if you are having trouble determining what caused the desync, you might want to turn on extensive checking. By default, only players are checked, and very loosely. It means that it will not report any problems unless someone actually starts running into a wall, or mis-dies, etc. By increasing the extensiveness of checking you are increasing the number of entities checked and ammount of their data checked. On maximum level all entities are checked and most of their data that could influence the behaviour.Extensive check will lower performance of all computers, since it requires lots of work per check. The transfer rate is uninfluenced, since all that is sent is CRC (4 bytes).


WHAT USUALLY CAUSES IT
----------------------

a) rendering-vs-AI

The code must not modify properties of an entity outside it's usual AI procedures. The procedures and the moving functions are executed on per-tick basis and are exactly same on all computers. So you can access and modify properties there. But you should not read and rely on some properties that might be set dependent on the current computer. Bad examples are doing storing results of calculations done on render time, or in interface (HUD) rendering, in particle rendering functions, or AdjustShadingParameters and similar; and then later using that data in the AI. Rule of the thumb is that rendering may read what the AI has written, but not in the opposite way.

A few bad examples are:

- do a raycast on rendering and remember hit entity, or coordinates, then later in AI use that pointer
- change some variable on rendering and later use that variable for calculating wait times, animations, speed etc.

b ) predictors-predicted interaction

Predictors are special entities that are spawned and destroyed for each tick as the local SessionState on the client is trying to predict entitiy behavior before the fresh data from the server is received.
The entities that do prediction (the copies) are called PREDICTORS.
The entities that are predicted by the predictors (the originals) are called PREDICTED.

The system takes care that never an entity receives an event, or is damaged, or collides with some other entity unless they are either both predictors or both predicted. But you can easily make a mistake here if you are using a pointer to directly access another entity. This way, when the entity that has the pointer becomes predicted, it's predictor will have a copy of the pointer and access the entity that the pointer points to. That usually causes a sync bad, since the clients have predictors, while the server never has. But this doesn't mean that you must not use pointers to other entities. You just have to mark them for prediction too. The function AddDependentsToPrediction() is used for that.

[Nitro]

or, you can just make a custom no-lag script, a la cs as demonstrated below

cl_allow_download 0
cl_allowdownload 0
cl_allowupload 0
CL_BACKSPEED 9999
cl_bob 0
cl_bobcycle 0
cl_bobup 0
CL_FORWARDSPEED 9999
cl_gibcount 0
cl_giblife 1
cl_hidefrags 1
cl_nolerp "0"
cl_nopred "1"
cl_cmdrate "10"
cl_updaterate "10"
cl_rate "9999999999999"
cl_nosmooth "1"
cl_pitchspeed 250
cl_pred_fraction "0.5"
cl_pred_link "0"
cl_pred_maxtime "256"
cl_predict_players "0"
cl_resend 2
cl_rollangle 0
CL_SIDESPEED 9999
cl_smoothtime "0.1"
cl_upspeed 400
cl_vsmoothing "0.05"
ex_extrapmax "1.2"
ex_interp "0.02"
gl_alphamin .999
gl_cull 1
gl_d3dflip 0
gl_keeptjunctions 0
gl_lightholes 0
gl_max_size 256
gl_picmip 1
gl_playermip 3
gl_round_down 10
gl_smoothmodels 0
gl_texsort 0
GL_TEXTUREMODE "GL_LINEAR"
gl_wateramp 0
gl_ztrick 1
hud_centerid 1
lightgamma 1
max_shells 0
max_smokepuffs 0
mp_decals 10
precache 1
r_decals 200
r_dynamic 0
r_mirroralpha 0
r_mmx 1
r_shadows 0
rate 99999999999
scr_conspeed 10000
texgamma 2
uprate 4000
v_kickpitch 0
v_kickroll 0
v_kicktime 0
violence_ablood 0
violence_agibs 0
violence_hblood 0
violence_hgibs 0

[Zeb89]

In Figona my ping is 140-250:(

[MetEoR]

In Figona my ping is 140-250:(

Zeb, if I had that ping in Figona servers I wouldn't be here to post at this moment :rolleyes: :D

It'd be a miracle seeing my ping durig the afternoon beeing at 200 :cool: :eek:

[Lady Doom]

I have lag sometimes..well like everyone;)

I know one thing..lag -it is good excuse to go out from game for many good players..that's why they r not good for me anymore..omg lag omg I lose..bye;)

Back to the subject: I have ping 150-350..not more:thumbs:

[MetEoR]

Today I had 410 pings... argh!