about last example of fala: I can understand if people don't hit a lagging out person in other games, but on a unlagged mod? you should basically hit what you see and that is a problem.

The initial thread has been answered more than once. It is a player decision whenever to use client-side delag or not. Some might have a better experience with that, others may not. That's why it is configurable.

Well, let's try this. I'm not really good at explaining things, especially in English.

wrote:

BUT i completely do no understand when i do fire 3-5 times to a laggy opponent where i hit every singe shot and the hit is not counted... there is nothing to compare because he haven't hit me at all and every of my hits should be counted since the hit should be registered locally and delivered to the server SO why it does fail?

There is another implementation called "Zero Ping". In contrast to "Unlagged", the client sends information to the server whether it hit another player or not. However this is highly abusable by malicious clients, as they could just send a hit while they really did not.

In Unlagged the server is sovereign and decides whether it was a hit or not. Generally this is the better method but it can produce some odd effects to the player. You can read up the most common ones here.

wrote:

u probably experienced a situation when someone lagged out and changed in air, u tried to hit him but every rail passed trough... it has completely no logic...

This is the most extreme example of Unlagged's skip correction. Maybe you still remember these days without unlagged. You could clearly see a player "skipping around".

Unlagged reduced this effect by sending predicted movement changes to you while the real skipping player actually did not send any updates to the server and thus did not move at all. This helps you to track his movement and most probably hit him once he sends an update again.

But while it sends you the movement change, the player actually does not move on the server, his hitbox will remain on his old position where he started skipping. In general this is not a big deal because skipping only happens for a very few frames, however, when the connection is really interrupted (e.g. the player will timeout after "sv_timeout" defined time) this becames a problem, as you will see the player in his advanced position, where he (most probably) would be once his skipping ends, while his hitbox remains on the old position.

Skip correction can be disabled by the server with /set g_smoothClients 0.

It's up to the server admin to decide whether it's worth or not only to be able to hit "timeout" players.

wrote:

But while it sends you the movement change, the player actually does not move on the server, his hitbox will remain on his old position where he started skipping. In general this is not a big deal because skipping only happens for a very few frames, however, when the connection is really interrupted (e.g. the player will timeout after "sv_timeout" defined time) this becames a problem, as you will see the player in his advanced position, where he (most probably) would be once his skipping ends, while his hitbox remains on the old position.

let me in here. About the hitbox remaining in the old position... afaics predicted movement is put in the unlagged history, so the hitbox position does match visual position anyways, does not it?

wrote:

I've noticed in last weeks that when i
respawn on map (clicking ofc) in reality i'm already spawned since some
second, but i don't understand the cause.. i see players moving ready to
spawnkill me (after 2^n clicks).

This "late respawn" happens to me offten and it's connected with other issues - I think the list below is full:
- mentioned late respawn (when you can fire weapon right after respawn it's obvious symptom).
- enemies respawn faster - sometimes you can't hit them even when aiming right spawnpoint, because right after enemy respawn he's already in move.
- enemies are warping while in move - it's similar to fps drop and looks like models are chasing their right position, but are too slow at it (like kid walking with his parent who make bigger steps needs to run a few steps once in a while). It also makes negative accel impression (mouse move was right but target skipped away).
- enemy direction change is delayed and compensated afterwards - especially visible when enemy is jumping in air (too late, too fast, too high).
- enemy is suddenly appearing out of the corner and is able to hit you which looks like guessed position but statistically it happens too often (wallhack impression).

I call it "Late snapshots" or "bad synchro". Didn't notice deja vu effect tbh, but I believe it could happen to players fragged by delayed one. It is not connected with e+ directly imo, but with specific client's connection, routing, etc. and that's why not everyone is bitchin about it (also not everyone is aware of it). Nevertheless I think it might be improved by netcode itself (some kind of buffer implemented... idk).

god, you guys made so many 'wrong' statements that I nearly puked - topped by a good amount of misunderstanding imo.

wrote:

It is a player decision whenever to use client-side delag or not. Some might have a better experience with that, others may not. That's why it is configurable.

We are actually talking about the phenomena people have while having xp_delagweapons 0 - means people just receive info thats validated from the server as true.

wrote:

There is another implementation called "Zero Ping". In contrast to "Unlagged", the client sends information to the server whether it hit another player or not. However this is highly abusable by malicious clients, as they could just send a hit while they really did not.

Ofc this is highly abusable - however whoever has coding skills to code something like that can code a cheat too.

I won't say which of both methods is better since both have their flaws - and combining both of them isn't an advantage either.

wrote:

This is the most extreme example of Unlagged's skip correction. Maybe you still remember these days without unlagged. You could clearly see a player "skipping around".

Please differ between unlagged hitscan and unlagged players - first is about compensating ping up to 17 server frames - on e+ common value of sv_fps 30 this means a lag compensation of 566.6 msec

Unlagged players is if I remember right an baseq3 feature and simply predicts enemy movement based on their last state send and the state before.

wrote:

Unlagged reduced this effect by sending predicted movement changes to you while the real skipping player actually did not send any updates to the server and thus did not move at all. This helps you to track his movement and most probably hit him once he sends an update again.

But while it sends you the movement change, the player actually does not move on the server, his hitbox will remain on his old position where he started skipping. In general this is not a big deal because skipping only happens for a very few frames, however, when the connection is really interrupted (e.g. the player will timeout after "sv_timeout" defined time) this becames a problem, as you will see the player in his advanced position, where he (most probably) would be once his skipping ends, while his hitbox remains on the old position.

The marked part actually means that we got the problem that client sees what servers predicts - while server checks hitscan not with predicted information but with true information.

wrote:

Skip correction can be disabled by the server with /set g_smoothClients 0.

Beside the fact it doesn't work proper (since people with packetloss still warp - a warpfix for packetloss less then 5% would be cool o") I couldn't recognize a big difference between 0/1 - maybe I didn't test it out enough. (or it is latched)

I never experienced it that extreme with xp_delagweapons 0 - a demo would be truly helpful.

Anyways, lost track of my ideas - so end of post for me till I remember. D: