Because of those massive ddos attacks it is hard to tell what the culprit is for all the higher pings and lag spikes.. We still have this issue, pings for everyone is higher on the same server that they ping lower on as with myself.. I am still pinging over 60 on my server that I normally ping 28 at the highest! And the lag spikes are horrible..
But lowping tells me it could be the ddos attacks or a combination of those and the new net-code changes.. Either way it does not seem to be smoothing out much..
Jump to 8m50s -- the hyperlink isn't doing it right it seems.
Tots: You have been neck-deep in our "netcode" for a while now. I'd say you're probably our best, I would say, you know, currently with who's in the studio, you're probably our most knowledgeable person on the hit code of America's Army: Proving Grounds, right? Server side or client side?
Kartigan: Our game is built for client side.
Tots: So these comp guys that are running server side, do you think that is hurting their experience? Do you think it's making the games not as good? Is it that much of a difference?
Kartigan: I hate to work in absolutes, because... I don't, as a programmer. We don't work in absolutes.
Tots: But, you know, the comp guys are gonna want to run in the best, most accurate, competitive environment. And if that isn't server-side...
Kartigan: They are, I can say without a doubt, they are hurting themselves by running server-side hit detection with our game.
Tots: You heard it here first, folks. Send all hate-mail to... (laughter)
Nothing in this patch should have an effect on hit registration.
Now while I say no work went into hit registration, there was work on cleaning up animations in general:
When you finish vaulting, on the server you finish vaulting. This used to have a 2 to 3 packet delay in it.
Ladders had some location pops (teleports), we managed to squeeze out most of those.
Sliding used to have that odd flicker at the end. It was a consistent case of the rotations not applying properly.
And well, let's just say we went down the list, and every animation bit was touched. Whenever the animations had data out of sync, it may have nudged the pawn's location/rotation, causing a miss.
Now then, let's talk about how weapons function:
We use a custom physics based weapon system. Your "fire" button cycles the weapon into a state to initiate firing, it does not instantly pop out a round. The weapon responds to that fire command, after a tiny delay only a computer could fathom, and sends a round out. The round then travels at rate/second and checks for hits as it goes.
My crosshair was on X when I pressed the mouse button. Yes, it was. It is only a piece of the equation for hitting a target. If you are not scoped, some accuracy is lost when firing. When you are scoped, the scope's dot or sights or etc, whatever the type, does not change size based on target distance. Target's at further distance are harder to hit with the dot/sights being relatively larger versus their player model.
Spectators now have a reduced send rate to the server. There is no need for them to send packets at the same speed as live players.
What do spectators need to send to the server anyway? Is this, say, info on who they're spectating so the server can optimize what info to send back?
Fixed an issue where a running player looking left/right repeatedly could cause their hitbox to move significantly per frame. (Known as the Knox wobble)
Was the hitbox moving differently than the player mesh or would the two have still been linked appropriately? Do you think there are any situations now where those would ever uncouple -- for example, during large animations? There was a theory floating around for a *long* time that players could dodge bullets during, say, window vaults, that it sounds like this update intends to address.
Added weapon sway and recoil into replicate move. It was previously set to send continuously.
Were there any advantages to the continuous send, particularly for spectators? I'm thinking about impacts on casters here. How do lumped updates impact the accuracy with which spectators see another player's point of aim and recoil/sway control?
If there are any potential spectator inaccuracies, are there any server settings to prioritize spectator POV for the sake of casters?
The server needs to know where you are spectating from to determine what is relevant in your field of view. Also, for example, when you spectate someone from their view it sends you extra information with regards to where they are looking.
"a *long* time that players could dodge bullets during, say, window vaults". That's the simple explanation for it.
Continuous send has disadvantages associated with it. The server only updates so often, and if you send 7 updates during the server's one update, you are just needlessly flooding the server. The server sends data to spectators after that update, so the "7 updates", for example, has 6 updates that are not even relevant getting process by the server.
We also removed a lot of calls to the server in the process. From my understanding of the engine, the call to the server itself is the most expensive part, not the data in it.
" How do lumped updates impact the accuracy with which spectators see another player's point of aim and recoil/sway control?"
The worst offender for the spectator is the smoothing code, so you do not acquire motion sickness watching someone in first person. There are methods to avoid the need of smoothing code, but not in this engine.
Kartigan - Do you guys have in place the capability of verifying if a player is loosing X amount of packets within the last (ex. 20sec) of the match and then the ability to temporarily kick that player?
Because playing with certain players that are warping all over the map due to extremely high ping or because of packet loss ruins the game experience for all the players on the server. I have seen a server go from running completely smooth to a disaster in seconds of players like this joining. Is there any plan to get this under control on the official servers because right now there is no ping limit from my understanding?
This has happen to me on both Inner Hospital and Intercept a few times. It has also been on a non official server as well as official servers. But I rarely play any of the other 12v12 maps so not sure if it would occur for the rest.
The reason I think the server performance dropped drastically because of one individual bad player is because on inner hospital while I was playing we had a player join with a noticeably bad internet connection. We already played a few rounds with no issues and all of a sudden the server started lagging for everyone, fortunately for us the admins recognized the player that just joined had a crazy fluctuating ping and kicked him and by the next round everything was back to normal for the most part.
Thanks for watching the stream last night. I did end up having some issues with the new patch in how it relates to actual hit detection. Playing in a somewhat comp setting last night, i found it much more difficult to land kills. We were playing on a server with all US players, i was pinging around 35(everyone else should be around there) It seems somewhat more disconnect than it used to, I originally thought that I just had too many beers, but reviewed some of the shadowplay footage
It might not be related to the patch, but it feels quite a bit different. May just be the timing/ using patch as scapegoat.
I'm gonna go ahead and retract the statement above, seems it may have been related to something else as I have not had this issue since.
Thanks for watching the stream last night. I did end up having some issues with the new patch in how it relates to actual hit detection. Playing in a somewhat comp setting last night, i found it much more difficult to land kills. We were playing on a server with all US players, i was pinging around 35(everyone else should be around there) It seems somewhat more disconnect than it used to, I originally thought that I just had too many beers, but reviewed some of the shadowplay footage
It might not be related to the patch, but it feels quite a bit different. May just be the timing/ using patch as scapegoat.
I'm gonna go ahead and retract the statement above, seems it may have been related to something else as I have not had this issue since.
cheers
-Twitch
Is it something what might affect other players as well (e.g. some weird driver problem) or is it specific to your system? If it can affect others, may I ask what was the reason?
Theory and reality are not that different. In theory.
Thanks for watching the stream last night. I did end up having some issues with the new patch in how it relates to actual hit detection. Playing in a somewhat comp setting last night, i found it much more difficult to land kills. We were playing on a server with all US players, i was pinging around 35(everyone else should be around there) It seems somewhat more disconnect than it used to, I originally thought that I just had too many beers, but reviewed some of the shadowplay footage
It might not be related to the patch, but it feels quite a bit different. May just be the timing/ using patch as scapegoat.
I'm gonna go ahead and retract the statement above, seems it may have been related to something else as I have not had this issue since.
cheers
-Twitch
Is it something what might affect other players as well (e.g. some weird driver problem) or is it specific to your system? If it can affect others, may I ask what was the reason?
Nothing changed, guessing it was either server or network related. Playing last night in a pick up game, and it seems that hitreg is back on. Actually playing on this exact map and landed similar shots.
Will look into a few things on that one. Someone with a bad connection should only have a bad experience on their client.
I'm thinking that a higher ping also means higher ping variance / jitter and a higher probability of data loss (UDP no error correction). Most multiplayer games are able to predict/interpolate player movement by looking at the player's ping, but if this number keeps changing coupled with data loss, it would make it hard for the server to provide the right information to other players. In theory, higher ping shouldn't affect other players, but if you are getting garbage in, there will be garbage out. Anyway, that's what I think happens. If anything, the warping caused by these players make it hard for everyone else.
Most multiplayer games are able to predict/interpolate player movement by looking at the player's ping, but if this number keeps changing coupled with data loss, it would make it hard for the server to provide the right information to other players.
My understanding of the theory is that the server's predictions take precedence over that client's lost info in that kind of case. Parameter tuning becomes important there in terms of what degrees of difference are allowed etc. By forcing that laggy/lossy client to be corrected to the server's predicted position instead of passing on that "late" information to other clients, only the laggy person should be adversely affected.
Curious to hear Kartigan's thoughts on the matter.
Comments
But lowping tells me it could be the ddos attacks or a combination of those and the new net-code changes.. Either way it does not seem to be smoothing out much..
[Dev]Kartigan answered this in the Podcast, actually.
http://forum.americasarmy.com/discussion/5785/operation-podcast-episode-21-the-netcode-podcast
Jump to 8m50s -- the hyperlink isn't doing it right it seems.
Nothing in this patch should have an effect on hit registration.
Now while I say no work went into hit registration, there was work on cleaning up animations in general:
When you finish vaulting, on the server you finish vaulting. This used to have a 2 to 3 packet delay in it.
Ladders had some location pops (teleports), we managed to squeeze out most of those.
Sliding used to have that odd flicker at the end. It was a consistent case of the rotations not applying properly.
And well, let's just say we went down the list, and every animation bit was touched. Whenever the animations had data out of sync, it may have nudged the pawn's location/rotation, causing a miss.
Now then, let's talk about how weapons function:
We use a custom physics based weapon system. Your "fire" button cycles the weapon into a state to initiate firing, it does not instantly pop out a round. The weapon responds to that fire command, after a tiny delay only a computer could fathom, and sends a round out. The round then travels at rate/second and checks for hits as it goes.
My crosshair was on X when I pressed the mouse button. Yes, it was. It is only a piece of the equation for hitting a target. If you are not scoped, some accuracy is lost when firing. When you are scoped, the scope's dot or sights or etc, whatever the type, does not change size based on target distance. Target's at further distance are harder to hit with the dot/sights being relatively larger versus their player model.
What do spectators need to send to the server anyway? Is this, say, info on who they're spectating so the server can optimize what info to send back?
Was the hitbox moving differently than the player mesh or would the two have still been linked appropriately? Do you think there are any situations now where those would ever uncouple -- for example, during large animations? There was a theory floating around for a *long* time that players could dodge bullets during, say, window vaults, that it sounds like this update intends to address.
Were there any advantages to the continuous send, particularly for spectators? I'm thinking about impacts on casters here. How do lumped updates impact the accuracy with which spectators see another player's point of aim and recoil/sway control?
If there are any potential spectator inaccuracies, are there any server settings to prioritize spectator POV for the sake of casters?
Thanks!
The server needs to know where you are spectating from to determine what is relevant in your field of view. Also, for example, when you spectate someone from their view it sends you extra information with regards to where they are looking.
"a *long* time that players could dodge bullets during, say, window vaults". That's the simple explanation for it.
Continuous send has disadvantages associated with it. The server only updates so often, and if you send 7 updates during the server's one update, you are just needlessly flooding the server. The server sends data to spectators after that update, so the "7 updates", for example, has 6 updates that are not even relevant getting process by the server.
We also removed a lot of calls to the server in the process. From my understanding of the engine, the call to the server itself is the most expensive part, not the data in it.
" How do lumped updates impact the accuracy with which spectators see another player's point of aim and recoil/sway control?"
The worst offender for the spectator is the smoothing code, so you do not acquire motion sickness watching someone in first person. There are methods to avoid the need of smoothing code, but not in this engine.
Because playing with certain players that are warping all over the map due to extremely high ping or because of packet loss ruins the game experience for all the players on the server. I have seen a server go from running completely smooth to a disaster in seconds of players like this joining. Is there any plan to get this under control on the official servers because right now there is no ping limit from my understanding?
Are there any maps in particular that have the issue more than others?
The reason I think the server performance dropped drastically because of one individual bad player is because on inner hospital while I was playing we had a player join with a noticeably bad internet connection. We already played a few rounds with no issues and all of a sudden the server started lagging for everyone, fortunately for us the admins recognized the player that just joined had a crazy fluctuating ping and kicked him and by the next round everything was back to normal for the most part.
Will look into a few things on that one. Someone with a bad connection should only have a bad experience on their client.
I'm gonna go ahead and retract the statement above, seems it may have been related to something else as I have not had this issue since.
cheers
-Twitch
Is it something what might affect other players as well (e.g. some weird driver problem) or is it specific to your system? If it can affect others, may I ask what was the reason?
Nothing changed, guessing it was either server or network related. Playing last night in a pick up game, and it seems that hitreg is back on. Actually playing on this exact map and landed similar shots.
This has been a test of the emergency flame-fest system. Please do not adjust your set.
I'm thinking that a higher ping also means higher ping variance / jitter and a higher probability of data loss (UDP no error correction). Most multiplayer games are able to predict/interpolate player movement by looking at the player's ping, but if this number keeps changing coupled with data loss, it would make it hard for the server to provide the right information to other players. In theory, higher ping shouldn't affect other players, but if you are getting garbage in, there will be garbage out. Anyway, that's what I think happens. If anything, the warping caused by these players make it hard for everyone else.
My understanding of the theory is that the server's predictions take precedence over that client's lost info in that kind of case. Parameter tuning becomes important there in terms of what degrees of difference are allowed etc. By forcing that laggy/lossy client to be corrected to the server's predicted position instead of passing on that "late" information to other clients, only the laggy person should be adversely affected.
Curious to hear Kartigan's thoughts on the matter.