Newnet's dud hitscan shots - A Detailed Explanation

[Raffi_B]

http://raffi.beyondunreal.com/newnet.html

Note: this article is not meant to take one side or another. It was written for the sole purpose of spreading some knowledge that isn't commonly known. I do not wish to start a flame war. I only hope you read it and learn something from it.

Enjoy

[JohnDoe641]

I've been getting an extremely large amount of dud ltg shots lately at fragbu. I don't know if it's my connection, but atleast 25% of my shots are duds.

[T2A`]

Using your time away from home due to hurricanes wisely, eh?

[Raffi_B]

I actually wrote most of that in my hotel room when I evacuated. I finished it up in the past hour or so.

[hal]

Originally Posted by JohnDoe641

I've been getting an extremely large amount of dud ltg shots lately at fragbu. I don't know if it's my connection, but atleast 25% of my shots are duds.

And the other 75% hit me!

[haarg]

In order to simulate the ping-free environment, newnet checks player locations at the time of your shot based on a certain number of ticks ago, and not interpolation

How does the server know where the player was a certain number of ticks ago? Unless it is always retaining that information, it will have to be extrapolated from the player's current location and velocity.

[dXII][Pa]

Good read Raffi.

[Defeat]

>Does this happen on a LAN too?

[Taleweaver]

Interesting read. Comprehensive and objective, just like all articles should be written

Originally Posted by Defeat

>Does this happen on a LAN too?

What do you mean with "this"? Package loss is usually acquired somewhere between your computer and the server location, so on a Local Area Network, PL is as good as nothing.
Newnet still works on the same way, but since ping is so low, I doubt you'd even notice the effect.

[Sir_Brizz]

http://unreal.epicgames.com/Network.htm <-- not quite accurate

And I still disagree with the summary. Newnet wasn't written for the best servers the Internet can provide. If it WAS written for that, then it is being used incorrectly on just about every server it is being run on. AFAIK, and anyone could probably attest to this, UTcomp was written for the typical server config. Unfortunately, as your article accurately describes (and since packet loss occurs on ALL connections) newnet is several times worse than the standard netcode on the majority of servers.

Originally Posted by Haarg

How does the server know where the player was a certain number of ticks ago? Unless it is always retaining that information, it will have to be extrapolated from the player's current location and velocity.

I'm pretty sure that UTcomp saves the last certain number of ticks for each client. This adds to processing time, network usage, and memory usage among other things. Obviously, one major impact this can have is if you DID in fact get PL during the last tick then your player location can be vastly different from your actual location at that tick. In which case you could be shot in the head by someone lagging behind that much at a location you never actually existed at.

[bharsell]

Originally Posted by Haarg

How does the server know where the player was a certain number of ticks ago? Unless it is always retaining that information, it will have to be extrapolated from the player's current location and velocity.

It uses a timestamp from my client when I fire at you to determine your location at the time I fired IRC.

[Raffi_B]

Originally Posted by Sir_Brizz

And I still disagree with the summary. Newnet wasn't written for the best servers the Internet can provide. If it WAS written for that, then it is being used incorrectly on just about every server it is being run on. AFAIK, and anyone could probably attest to this, UTcomp was written for the typical server config. Unfortunately, as your article accurately describes (and since packet loss occurs on ALL connections) newnet is several times worse than the standard netcode on the majority of servers.

I'm pretty sure that UTcomp saves the last certain number of ticks for each client. This adds to processing time, network usage, and memory usage among other things. Obviously, one major impact this can have is if you DID in fact get PL during the last tick then your player location can be vastly different from your actual location at that tick. In which case you could be shot in the head by someone lagging behind that much at a location you never actually existed at.

No, the server has the final say in determining a hit or miss. If it checks the hit trace a certain number of ticks ago and the shot was a miss, it will count it as miss.

And I don't see how you can "disagree" with the article. I only put one sentence on the purpose of newnet and the rest simply described what is going on in terms of ticks.

[edhe]

OMG RUN AWAY UTCOMP THREAD DEATH.

p.s. i managed to get a non-utcomp game voted into a server once, with only a few players it was beautiful. The shots were right, the server was pluckily quick and all was good, until i realised why newnet was on - it was a ****e server and they were compensating.

[Capt.Toilet]

It was a good read and it definetly has given me a better understanding of how newnet works, but I still prefer stock netcode. It feels like newnet gives me a dud once a game, while stock netcode gave it to me once a week. It was really more random and I still believe to this day its a fault in the engine itself and not a gameplay gimmick(shove it CliffyB )

[Nunchuk_Skillz]

Excellent article, Raffi. What about including info on the "false positives" that people have complained about? It's only an extension of what you've already done and should be apparent to most, but it still might be good to include it, just for the sake of clarity.

[Raffi_B]

Well, it's exactly the same for "false positives". People with consistently poor connections (*cough*spineblaze*cough*) generally undergo this client-side interpolation more often, so players don't appear to be where they really are. When a false positive occurs, all that happened is that you missed the player on your screen because of client-side interpolation but when the server calculated the hit trace the shot was a hit.

Anyway, I've updated the article with some clarification on what I meant by packet loss as well as this info about false positives.

[Sir_Brizz]

Originally Posted by Raffi_B

No, the server has the final say in determining a hit or miss. If it checks the hit trace a certain number of ticks ago and the shot was a miss, it will count it as miss.

That's not what I was saying whatosever.

And I don't see how you can "disagree" with the article. I only put one sentence on the purpose of newnet and the rest simply described what is going on in terms of ticks.

Well, that's because I didn't disagree with the whole article. I said:

Originally Posted by Me

And I still disagree with the summary.

Which I do. You've often said that the only way to decide whether you like newnet or not is to play it on servers with high tickrates, which I totally disagree with.

What is there, maybe 10% or less of the total UT2004 servercount that has a high tickrate on it. Essentially you are saying that the only way I can decide if I like newnet is to play on one of those servers. And if I still don't like it? Have I not played with it enough? And if I don't like it then? Have I still not played with it enough? I can't be expected to go hunting for servers with excellent tickrates simply because they are the only servers where newnet is playable and newnet is on every other server. Chances are , if I don't like it on one, I'm not going to like it on another.

Additionally, raising the tickrate only relaxes the problem for excellent connections, it does not solve it. What I was talking about in your first response above is how much more adversely ANY packetloss affects a high tickrate situation. On top of that, high tickrates introduce more lag and packet loss on your connection if it is susceptible to it, because it sends data more often. Specifically, missing any tick introduces an area for a false negative or false positive when you may or may not have ever touched the spot that you could be hit at.

[-AEnubis-]

Yeah, the more I hear about this the more oxymoronic it get's. Why would you defend something designed to make a connection "feel better" if it requires a good connection, and jacked up server to use? Theoretically, if the server is that much better then the average server anyways, it shouldn't need it.

I also liked the way you skipped from 10 to 40, as though not to illustrate how 20-30 is prefectly acceptable as well.

I did however find TNSe's tick rate explanation very useful. A couple memerable moments.

Originally Posted by TNSe

Nah, if you can't hit with tickrate 20, you have no skillz. High Tickrate = no skillz.

Originally Posted by TNSe

I would suggest servers keeping the tickrate of 20 to avoid messing up the weapon balance.

After reading that I feel kinda confirmed on my theory of dud shots in normal net play, and It looks like we may be able to smooth out some net play with refreshrate/netspeed settings done by mathematical equation.

I'd also be curious too see how some of that information has changed for 2k4. I'd imagine the "ease of hit" reality hasn't changed at all, but can only hope and assume the "bullets per second" has been fixed. I've read the "link saw" has been fixed, and believe that, but...

[Raffi_B]

That graph was for concept purposes only. When I made it I just made a huge grid and used that to align all the lengths. In the real world nothing is neatly divided into evenly spaced units.

I also included tickrates 2 and 5, which are both insanely low. The lowest I've seen in 2k4 is 15.

I would have done 20 and 30, but it would have required smaller subdivisions when I was making the graph, and it would've been harder to keep track of everything.

If you're referring to the real world, though, I have several demos of myself playing on the same server with varying tickrates in 10-tick increments from 20 to 60. Tickrate does help reduce some of the glitches like false positives and negatives.

[-AEnubis-]

Provided the server can push it yeah... I know the effects of tick rate. I play LAN weekly, and play on the net enough to be very familiar with the differences. We still keep our LAN tickrate stock because of how it effects weapon balance, even though we have plenty of bandwidth and server power to do otherwise.

I just thought a comparison between stock, and something higher, would have been a more objective comparison, since as you say, no one uses tickrates that low. Or simply not numbering them at all, so's to just illustrate a relative difference.