May 10th Beta Changelog

[Eisprinzessin]

Originally Posted by SQBsam

ricochets

[MrHello]

Originally Posted by SQBsam

The reason they think a high pinger has an advantage is because in a high paced game the high pinger exacerbates the "shot around wall" effect. They think they're being shot around corners by the high pinger. In reality, the high-pinger shot him before he got to cover, it was just as skilful a shot, and the guy would've died anyway if the high pinger had low ping. Basically, it's an excuse for dying some people come up with when they're not going well.

This; the amount of times I've had to explain this to people. Those who do not come to terms with this themselves seem to indefinitely just not get it.

[SQBsam]

Originally Posted by MrHello

This; the amount of times I've had to explain this to people. Those who do not come to terms with this themselves seem to indefinitely just not get it.

Good to see some people are capable of thinking it out, it's definitely a quite complex problem, akin to working with basic relativistic principles, but with a little effort the various server systems can be understood.

[Proud_God]

Originally Posted by SQBsam

The reason they think a high pinger has an advantage is because in a high paced game the high pinger exacerbates the "shot around wall" effect. They think they're being shot around corners by the high pinger. In reality, the high-pinger shot him before he got to cover, it was just as skilful a shot, and the guy would've died anyway if the high pinger had low ping. Basically, it's an excuse for dying some people come up with when they're not going well.

That statement is not always true. Here's an example, just a little sample: Player A (low ping) is stationary looking down a 'T'-hallway. Player B (high ping) is coming around the corner at the end of the hallway. Instantly while coming around the corner, B will see A. However, it will take some time until A sees B -> high pinger B has the advantage over low pinger A. Note: B will always have an advantage over A, but it increases with B's ping.

[m_0_r_0_n]

Proud_God, good explanation and your re right. That s why I always say, we need a ping limiter Get automatically kicked when ping average is greater than 120. This option was even implemented on first Half Life servers (ping average was 90-110 at that times, now its 40-60).
On the last days there is a player on the beta cold steel server, called --ffr--sarkis. He s playing with an estimated ping average of 260. When other player have 6-10 kills he already has 20 kills! As a player with a good ping you get his data much too late.
I also saw the effect, that player with very high ping appears all of a sudden like a ghost (may be missing data)


I can live with that, but, please, fix the audio bug "missing steps"! Two days ago on the event session when playing also against the developers, I was behind a mg on russian side in mamayev. Suddenly someone began to shout very loud behind me. A player tried to attack me. I turned around and shot him. It was DrGuppy ;-) I couldn't hear his steps, but because I could hear his shouting I had a chance to react! If someone is too loud, he gets killed And heavy boots on snow or on wooden floor are loud.
Please please please, I will accept all other modes than classic but fix the 3D sound

[=GG= Mr Moe]

Originally Posted by MrHello

This; the amount of times I've had to explain this to people. Those who do not come to terms with this themselves seem to indefinitely just not get it.

That is only true from the SHOOTER's perspective, not from the TARGET's perspecitve. Just because you choose to go with what the shooter sees, does not invalidate how the target sees himself. It is you who seems to think there is only one side to the issue when at least the others realise there are two sides and choose to agree with one of them.

[m_0_r_0_n]

Originally Posted by MrHello

This; the amount of times I've had to explain this to people. Those who do not come to terms with this themselves seem to indefinitely just not get it.

Your explanations are worthless if you dont validate it against practical experience.

[=GG= Mr Moe]

Originally Posted by SQBsam

The reason they think a high pinger has an advantage is because in a high paced game the high pinger exacerbates the "shot around wall" effect. They think they're being shot around corners by the high pinger. In reality, the high-pinger shot him before he got to cover, it was just as skilful a shot, and the guy would've died anyway if the high pinger had low ping. Basically, it's an excuse for dying some people come up with when they're not going well.

I could also counter that argument, and say that a Higher pinging player is having a frustrating day and actually missing in most cases, yet thinks too much of him/herself and uses the lag excuse. Now that may or may not actually be the case, but I would guess that there are those out there who use it as an excuse. Afterall, not everytime someone points a weapon at another person in game are they actually on target when they fire.

[Cwivey]

Originally Posted by m_0_r_0_n

On the last days there is a player on the beta cold steel server, called --ffr--sarkis. He s playing with an estimated ping average of 260. When other player have 6-10 kills he already has 20 kills! As a player with a good ping you get his data much too late.

He was the commander and had a series of very good artillery strikes. :P

[Alphons Alphahane]

Originally Posted by Cwivey

He was the commander and had a series of very good artillery strikes. :P

I tryed to outsnipe him a couple of days ago and it was impossible. He was on fire yesterday on Mamayev. Sure, he has a lot of ping but this guy is seriously good. A pinglimiter would be nice but I don´t think we currently have the population to afford that.

[Mekhazzio]

Originally Posted by Proud_God

That statement is not always true. Here's an example, just a little sample: Player A (low ping) is stationary looking down a 'T'-hallway. Player B (high ping) is coming around the corner at the end of the hallway. Instantly while coming around the corner, B will see A. However, it will take some time until A sees B -> high pinger B has the advantage over low pinger A. Note: B will always have an advantage over A, but it increases with B's ping.

This is a common misconception, but it's wrong because you're looking at the sequence of events from a frame of reference (objective chronology) that has no relevance to event resolution. It makes no difference if the mover's sequence of events happens first, because the universe isn't arbitrating the game, the server is.

It might help to think of a multiplayer game as a series of recordings that start at different times for different people. What's important is what the final sequence looks like for the server, not for any given client.

For the sake of example, let's give Player B a 1 second ping and Player A a 50ms ping. Player B "records" his act of coming around the corner, aiming, and firing. That'll start our example, so we'll call that t=0 (ms). Let's say it takes him 300ms to aim and shoot at Player A. This means that at t=500 (half of B's ping, the outbound leg) the server receives and tells everybody else in the game, that B has come around the corner. At t=800, the server receives the message that B has shot A. B continues on walking down the hallway.

At t=525, A now sees B coming around the corner. But let's say he's already aimed in and expecting it, so it takes him only 150ms to fire. At t=700, the server receives the message that A has shot B, and dutifully kills B. At t=800, the server gets the message that B has shot A, but B is already dead, so that gets ignored. At t=1200, player B's client shows him suddenly dropping over dead in the middle of the hallway, killed by the guy that he thought he shot a second ago. He might even get to see himself rubber-banded back to location where he really died, which is 175ms of movement past the corner.

A is at a "disadvantage" only in that he has to react, and thus has to fight his inbound latency as well as his outbound, while B is only doing outbound, but that's the case for either networking model and is an unavoidable result of communications delay. This sequence of events plays out no differently if it's server-side or client-side hit detection. (Unreal's relevancy system throws a wrench into this and opens the possibility that B won't even get to -see- A when he comes around the corner, but I'm leaving that out here, for simplicity...)

Now, flip it around. Let's give Player A the 1 second ping and Player B the 50ms ping. Player A is now utterly screwed, because by the time he even sees B come around the corner (t=525), the server has already received his death (t=325). Even if he's aimbotting and fires instantaneously, it makes no difference.

High ping is never a good thing to have. (To be technically correct, there -are- edge cases where it can help, but they require essentially psychic knowledge of future events for a player to exploit, and are much more rare than the scenario described here).

That's is why a "ping limiter" is unnecessary and largely undesirable due to its enforced fragmentation of the community. I'd also like to note that my Antilag implementation, and I assume TWI's version will also, already has a discrepancy limitation function, so that if someone actually does have truly excessive ping, then it will rein in the outlier results, but only on the shots that it would actually make a difference for. The results are what are important, not the arbitrary value of ping...and while some people might find it hard to accept, the reality of the situation is that "high-pingers" are just as capable of getting legitimate kills as anyone else

[Proud_God]

Originally Posted by Mekhazzio

This is a common misconception, but it's wrong because you're looking at the sequence of events from a frame of reference (objective chronology) that has no relevance to event resolution. It makes no difference if the mover's sequence of events happens first, because the universe isn't arbitrating the game, the server is.

It might help to think of a multiplayer game as a series of recordings that start at different times for different people. What's important is what the final sequence looks like for the server, not for any given client.

For the sake of example, let's give Player A a 1 second ping and Player B a 50ms ping. Player A "records" his act of coming around the corner, aiming, and firing. That'll start our example, so we'll call that t=0 (ms). Let's say it takes him 300ms to aim and shoot at Player B. This means that at t=500 (half of B's ping, the outbound leg) the server receives, and tells everybody else in the game, that B has come around the corner. At t=800, the server receives the message that B has shot A. B continues on walking down the hallway.

At t=525, A now sees B coming around the corner. But let's say he's already aimed in and expecting it, so it takes him only 150ms to fire. At t=700, the server receives the message that A has shot B, and dutifully kills B. At t=800, the server gets the message that B has shot A, but B is already dead, so that gets ignored. At t=1200, player B's client shows him suddenly dropping over dead in the middle of the hallway, killed by the guy that he thought he shot a second ago. He might even get to see himself rubber-banded back to location where he really died, which is 175ms of movement past the corner.

A is at a "disadvantage" only in that he has to react, and thus has to fight his inbound ping as well as his outbound, while B is only doing outbound, but that's the case for either networking model and is an unavoidable result of communications delay. This sequence of events plays out no differently if it's server-side or client-side hit detection. (Unreal's relevancy system throws a wrench into this and opens the possibility that B won't even get to -see- A when he comes around the corner, but I'm leaving that out here, for simplicity...)

Now, flip it around. Let's give Player A the 1 second ping and Player B the 50ms ping. Player A is now utterly screwed, because by the time he even sees B come around the corner (t=525), the server has already received his death (t=325). Even if he's aimbotting and fires instantaneously, it makes no difference.

High ping is never a good thing to have. (To be technically correct, there -are- edge cases where it can help, but they require essentially psychic knowledge of future events for a player to exploit, and are much more rare than the scenario described here).

That's is why a "ping limiter" is unnecessary and largely undesirable due to its enforced fragmentation of the community. I'd also like to note that my Antilag implementation, and I assume TWI's version will also, already has a discrepancy limitation function, so that if someone actually does have truly excessive ping, then it will rein in the outlier results, but only on the shots that it would actually make a difference for. The results are what are important, not the arbitrary value of ping...and while some people might find it hard to accept, the reality of the situation is that "high-pingers" are just as capable of getting legitimate kills as anyone else

Ok, there are definately some mix-ups in your example making it very hard to follow (A has ping 1 sec in both examples, etc), but I think I got it. I was not aware that player A would be the victor in that case. I thought the shot with the oldest time stamp, as taken on the client's PC, would win. But, the timestamps are taken at the server, correct?

[Dionysos]

Originally Posted by Proud_God

Ok, there are definately some mix-ups in your example making it very hard to follow (A has ping 1 sec in both examples, etc), but I think I got it. I was not aware that player A would be the victor in that case. I thought the shot with the oldest time stamp, as taken on the client's PC, would win. But, the timestamps are taken at the server, correct?

Yes the server is the ultimate authority on what happens when. Client side detection only means that hit detection is done on the client, but whether that hit counts is up to the server (for instance as in the above case that the player with the high ping was already well dead according to the server when he made his subjectively good shot).

[m_0_r_0_n]

Another example I had today: a player was running from left to right at 20 meter from my point of view. I had him on ironsight. I just needed to press the fire button. While I was shooting at him, he stopped, made a 90° turn in my direction, aimed at me, and killed me with one head shot. He s ping was twice as hight as mine.

[Mekhazzio]

Originally Posted by Proud_God

Ok, there are definately some mix-ups in your example making it very hard to follow (A has ping 1 sec in both examples, etc), but I think I got it. I was not aware that player A would be the victor in that case. I thought the shot with the oldest time stamp, as taken on the client's PC, would win. But, the timestamps are taken at the server, correct?

Whoops, yeah. I had the initial one labeled backwards. Fixed that.

Anyway, there are no timestamps, in the sense that you mean them. Unreal does not attempt to closely synchronize its clients, because that would be impossible to do and still maintain any sort of quick action. The server resolves clients events in the order that it sees them happen and then broadcasts its event resolution, while the clients run their own local simulation of the game world.

[Mekhazzio]

Originally Posted by m_0_r_0_n

Another example I had today: a player was running from left to right at 20 meter from my point of view. I had him on ironsight. I just needed to press the fire button. While I was shooting at him, he stopped, made a 90° turn in my direction, aimed at me, and killed me with one head shot. He s ping was twice as hight as mine.

That's not a scenario where latency of either party has any bearing on the outcome at all, in either the stock networking model or client-side hit detection.

[Proud_God]

Originally Posted by Mekhazzio

Whoops, yeah. I had the initial one labeled backwards. Fixed that.

Anyway, there are no timestamps at all, in the sense that you mean them. Unreal does not attempt to closely synchronize its clients, because that would be impossible to do and still maintain any sort of quick action. The server resolves clients events in the order that it sees them happen and then broadcasts its event resolution, while the clients run their own local simulation of the game world.

Yeah, got it. There are other mix-ups in the first paragraph of your example: I think you mixed player A and B two times..