PDA

View Full Version : Targeting of distant figures



John Jones
11-06-2017, 09:58 AM
October 28th - Update 82 Released!

- Experimental feature to reduce CPU load on both clients and servers by delaying the update of distant players by X amount of frames based on their distance to the client.

- Trusty

Probably just an obvious quick question concerning what I assume is a result of the experimental feature for reducing CPU load. I was playing as Union last night and particularly on Hooker's Push could see the CSA approaching from a fair distance. They had a markedly stuttering appearance at long range, disappearing in and out of view. As a number of us had Spencer rifles we did take some pot-shots but I don't know if anyone was hit. I was curious as to whether the 'stuttering' effect is purely a graphics workaround and assume that if you can lead the target correctly, it is capable of being hit at those longer ranges even if you can't actually see it?

Of course, I'm flattering myself that I can hit anything beyond 20 paces. Which I can't.

JohnDewitt
11-08-2017, 04:22 PM
Not sure that would explain it. It could, but only if the interpolation doesn't use a Lerp to transition between positions. Which it probably does as it is the standard practice. But I could be wrong, as the stuttering could be kind of smooth, just in chunks and then moving really fast. If the smoothing variable on the Lerp function is also set to become faster as the player if farther away from the client you could end up with a stuttering movement as described.

Normal interpolation: every frame the new position is determined and the movement between the cold and new position is done through a Lerp formula (which makes the transition smooth instead of at once).

Sped up Lerp interpolation: every couple of frames a new position is determined, to avoid making the transition look weird the Lerp is increased to compensate. Result would be a stuttering player which stands still, then moves abnormally fast, stands still again, loop.

John Jones
11-08-2017, 09:26 PM
Not sure that would explain it. It could, but only if the interpolation doesn't use a Lerp to transition between positions. Which it probably does as it is the standard practice. But I could be wrong, as the stuttering could be kind of smooth, just in chunks and then moving really fast. If the smoothing variable on the Lerp function is also set to become faster as the player if farther away from the client you could end up with a stuttering movement as described.

Normal interpolation: every frame the new position is determined and the movement between the cold and new position is done through a Lerp formula (which makes the transition smooth instead of at once).

Sped up Lerp interpolation: every couple of frames a new position is determined, to avoid making the transition look weird the Lerp is increased to compensate. Result would be a stuttering player which stands still, then moves abnormally fast, stands still again, loop.

I think I understand. Either with or without the Lerp, presumably there is a point at which the target would disappear and then reappear after the new position is determined. Would I be right in guessing this would normally be too quick to interfere with the ballistic calculation for travel of the bullet in terms of targeting, which is presumably handled server-side, regardless of range, or is there actually a period at the longer ranges at which I have noticed the 'stutter' effect, in which it would be possible to miss because the target is transitioning to the new position?

I will admit that this is not something I would normally be interested in but it has piqued my intellectual curiosity. The simpleton in me would have been happy with "thunderstick not see bad man so no kill."

Fancy Sweetroll
11-08-2017, 09:41 PM
The update loop of players does a lot of things. One of those things is updating their position. We are yet to determine if lerping/interpolating the players every frame is that costly (I assume its not) and may in a future either make the lerping update every frame or just increase the distance at which delaying of the updates starts to trigger (so its less likely players will notice it as players will first start to teleport, farther away).

Ultimately whether or not you hit another player, depends on the server. If the server is running crazy slow due to a high player count, you will have to hit the player at the position he is at, during one of the servers update loops. So technically for you, if the server is running crazy slow, even though for 0,2 seconds, the player appears to be moving on your screen. The player may technically be standing still on the server. That means that in order to hit the player, you will need to hit him at the point he is currently at, or more likely, the point he is at during the next update loop of the server. But with that said, we recently discovered a way to dramatically improve the performance of the server which makes a slow updating server less likely, though we are still to see what exactly happens when theres 80 players on a server with this new improvement.

John Jones
11-08-2017, 10:08 PM
The update loop of players does a lot of things. One of those things is updating their position. We are yet to determine if lerping/interpolating the players every frame is that costly (I assume its not) and may in a future either make the lerping update every frame or just increase the distance at which delaying of the updates starts to trigger (so its less likely players will notice it as players will first start to teleport, farther away).

Ultimately whether or not you hit another player, depends on the server. If the server is running crazy slow due to a high player count, you will have to hit the player at the position he is at, during one of the servers update loops. So technically for you, if the server is running crazy slow, even though for 0,2 seconds, the player appears to be moving on your screen. The player may technically be standing still on the server. That means that in order to hit the player, you will need to hit him at the point he is currently at, or more likely, the point he is at during the next update loop of the server. But with that said, we recently discovered a way to dramatically improve the performance of the server which makes a slow updating server less likely, though we are still to see what exactly happens when theres 80 players on a server with this new improvement.

Huzzah! An official explanation of why my game marksmanship is so poor!

Thanks both for taking the time to explain.

Dether
11-08-2017, 10:43 PM
The update loop of players does a lot of things. One of those things is updating their position. We are yet to determine if lerping/interpolating the players every frame is that costly (I assume its not) and may in a future either make the lerping update every frame or just increase the distance at which delaying of the updates starts to trigger (so its less likely players will notice it as players will first start to teleport, farther away).

Ultimately whether or not you hit another player, depends on the server. If the server is running crazy slow due to a high player count, you will have to hit the player at the position he is at, during one of the servers update loops. So technically for you, if the server is running crazy slow, even though for 0,2 seconds, the player appears to be moving on your screen. The player may technically be standing still on the server. That means that in order to hit the player, you will need to hit him at the point he is currently at, or more likely, the point he is at during the next update loop of the server. But with that said, we recently discovered a way to dramatically improve the performance of the server which makes a slow updating server less likely, though we are still to see what exactly happens when theres 80 players on a server with this new improvement.

for your information.. last night I saw a fed aiming at me and I stepped behind a tee and dropped to a knee.. I could barely make him out at a distance of say 75 to 100.. yet he killed me.. he never moved and shot and killed me.. is this part of what you are speaking of?

TrustyJam
11-08-2017, 10:49 PM
for your information.. last night I saw a fed aiming at me and I stepped behind a tee and dropped to a knee.. I could barely make him out at a distance of say 75 to 100.. yet he killed me.. he never moved and shot and killed me.. is this part of what you are speaking of?

No, while players in the distance are being updated slower for you than people right next to you we are still talking update times of many times a second (unless you run the game with 1 FPS).

- Trusty

Dether
11-09-2017, 01:51 AM
No, while players in the distance are being updated slower for you than people right next to you we are still talking update times of many times a second (unless you run the game with 1 FPS).

- Trusty

ok ..so I have to be faster than what I see... I can deal with that for now

TrustyJam
11-09-2017, 02:06 AM
ok ..so I have to be faster than what I see... I can deal with that for now

Huh?

No, what I was saying was it can't have been the stationary guy killing you (if you were in cover) as he updates lots of times each second for you, even at a distance.

- Trusty

Dether
11-09-2017, 02:54 AM
Huh?

No, what I was saying was it can't have been the stationary guy killing you (if you were in cover) as he updates lots of times each second for you, even at a distance.

- Trusty

now I am confused... he was the only one I could see .. and shot! I saw his smoke as I died. however I could have missed someone,, but I doubt it being that big a coincidence.

TrustyJam
11-09-2017, 03:08 AM
now I am confused... he was the only one I could see .. and shot! I saw his smoke as I died. however I could have missed someone,, but I doubt it being that big a coincidence.

I am too. How could you see him firing if you were hiding behind cover?

- Trusty

JohnDewitt
11-09-2017, 03:36 PM
The update loop of players does a lot of things. One of those things is updating their position. We are yet to determine if lerping/interpolating the players every frame is that costly (I assume its not) and may in a future either make the lerping update every frame or just increase the distance at which delaying of the updates starts to trigger (so its less likely players will notice it as players will first start to teleport, farther away).

It is costly. But you're making an FPS so its one of the things you're going to sink cycles in by necessity. From what I'm gathering you're trying to limit the number of updates per frame of object transforms. But I'm not sure that doing this will make that much of a difference. I'm guessing you're using some kind of countdown to count a number of frames (X) depending on the range to the object. Are you then not, apart from the additional computation needed to do the countdown anyway, also introducing a distributed update at the runtime? Or,

At normal update, every object transform is calculated every frame and lerp is used for a smooth transition on screen as 1 calculation.

At the "hybrid" update, for every object, first the distance is checked, the number of frames to wait is calculated and the next update loop is assigned = essentially giving each individual object its own update along with calculations.

This could potentially be a multitude of different updates running parallel as many players will all be at (slightly) different distances and would all requires a different formula running parallel to one another. So what you might gain per frame, you might lose per frame due to the additional load.

Edit: another thing that came to mind, how do you solve the issue of a moving player changing its distance to you and thus requiring an updated "frames to wait" pretty much constantly. If the code is checking for the distance to a player per frame and updating as this value changes, does the code update the frames to wait and as a result reset the countdown? This could cause the stuttering as well.

Dether
11-09-2017, 04:03 PM
I am too. How could you see him firing if you were hiding behind cover?

- Trusty

I didn't see any thing but him bring up the rifle and I got behind the tree kneeling and looked up and saw the smoke just as I fell. the sound of the shot, the smoke and me falling was instantly. as I said I could have been hit by another but, the guys said it was him behind the tree and they got him. (he was behind another tree, but when he fired he was not) It could have been a lag issue, we had a like situation last nite from only a few feet apart, but this time I prevailed. he missed me and I missed him, we were very close, then I clubbed him to death. but neither of us should have missed those shots, it was as if we were not where we seemed, and when I clubbed him he seemed to be looking in a different direction from where I was. he also said something about lag as I clubbed him.

TrustyJam
11-09-2017, 04:25 PM
I didn't see any thing but him bring up the rifle and I got behind the tree kneeling and looked up and saw the smoke just as I fell. the sound of the shot, the smoke and me falling was instantly. as I said I could have been hit by another but, the guys said it was him behind the tree and they got him. (he was behind another tree, but when he fired he was not) It could have been a lag issue, we had a like situation last nite from only a few feet apart, but this time I prevailed. he missed me and I missed him, we were very close, then I clubbed him to death. but neither of us should have missed those shots, it was as if we were not where we seemed, and when I clubbed him he seemed to be looking in a different direction from where I was. he also said something about lag as I clubbed him.

That is most certainly to do with differences between first person animations and third person ones, not lag.

In short, the first person aim animation is slightly quicker than its third person one currently allowing the player to aim and fire before you can see he’s finished playing the aiming animation.

- Trusty

Dether
11-10-2017, 01:48 PM
That is most certainly to do with differences between first person animations and third person ones, not lag.

In short, the first person aim animation is slightly quicker than its third person one currently allowing the player to aim and fire before you can see he’s finished playing the aiming animation.

- Trusty

ok.. now I do understand,,, so as I said before I got to be a bit quicker than what I see... if they are aiming.