Hit reg, or, why I am sick of dying around a corner.
BloodyIron
Join Date: 2009-11-09 Member: 69321Members, Reinforced - Shadow
Join Date: 2009-11-09 Member: 69321Members, Reinforced - Shadow
Comments
Heheh he keeps dying around corners and thinks we can fix it with our current technology
If this guy was alive in this day and age he could tell you all about why this is happening and why we're not going to fix it with our current technology any time soon... Hmm come to think of it, if he was alive today, we'd probably already have huge advancements in the field of quantum mechanics...
If you want to try and understand the jest of it, watch this video.
Generally, dont play above a ping of 100, as that is what interpolation is set at (100).
What you are describing is latency which is a completely different story.
http://www.ra.is/unlagged/faq.html#IJGSAAC
Trust me, the rage would be even higher
It's absolute trash, there was an internal build many yonks ago which had no compensation when specific network perimeters were met, it felt like playing counterstrike with no headshot hitbox and random crouch exploits. Then again on lan it wasn't exactly too bad, just that you had to actually be very accurate, lerks overpowered and gorge spits never hit.
Go record some demo's in Spark to see what your game would look like if you remove the lag compensation...
But it's also the send rate/ interpolation delay. It adds an extra 100ms + some other small things
While other games have interpolation, it's typically not as high because the server can afford to send updates at a more frequent rate, (ns2 has a lot of entities comparatively + Lua) and here's the big one: they're often far slower entities.
High velocity movement will highlight/exaggerate any interp delay in a game.
Q3 had around 20ms IIRC?
That's basically what you'd end up with in NS2 (all games), if you remove lag compensation. Which is a huge deal in a fast, twitch based game like NS2. So tell me, do you want to shoot where you think your target will be? Basically shooting at the air in front of it... That is if it doesn't suddenly change direction, then everyone loses their mind...
Compared to the way it currently is, the tried and true quake/UT like tracking the target's movement by aiming at the model. An interpolation of what you see and what your target sees, based on server checks...
@IronHorse, isn't Spark's interpolation lag around 150ms, or did ya lot get it down to 100ms?
Result is when you play with people lower than 20 ping it still feels like playing with 100 ping laggers and it's not a fatality nor is it due to lag compensation but rather the value it's set at.
Lag compensation is set according to what the maximum desirable ping should be. It's set to 100 because that's a nice safe number. If we were to lower it to say... 50... that would mean that anybody with 75 ping would be extrapolated 25ms each update.
Think about it this way: if we were to set interp to 0, and therefore just have every client immediately display the most current snapshot, and perhaps just extrapolate from that, you'd get MASSIVELY buggy-looking movement. Say you're observing a marine going ADADADADADADA, left,right, left right... etc. Well you'd see them basically teleport back and forth because at each snapshot, you're being told the marine is moving the opposite direction. If you elected to just not extrapolate, that would mean you would see other player's moving at about 30 fps (and inconsistently due to dropped packets, etc)... which looks awful and wouldn't be very fun to play against anyways.
EDIT: Wow I was really tired when I wrote that... IronHorse has his head on straight... listen to him...
It was small but it really helped in competitive matches..
@Archie pls read the PM
That is really hard without being able to look into the future, though.
It's a bit of situational awareness and balls of steel and a flux capacitor
I can't speak for every single element of how the NS2 engine works, but what I do know is hit reg as it is now is problematic. Laugh at me all you want, I don't care, I'm not the only person taking issue with this either.
When I'm a skulk and I jump around the corner to retreat and I die half way down the hall anyways, that's not only not fun, that's not fair. I can't plan around that, so saying things like "oh just play better" is irrelevant and not helpful.
There are plenty of games out there with much better hit reg that work across the internet, including TF2, CSGO, and as pointed out various Battlefield titles, just to name a few. So, why is this kind of behaviour acceptable for NS2? I'm saying it's not.
So we've got NS2 adding all of these to the problem:
- NS2 pushing loads and loads of data though the net, way more than other games (probably the biggest root of the problem)
- Spark running at only 30 ticks and on Lua
- In engine latency of 100Ms? (other engines tend to have around 50-100Ms as well)
- Very fast moving aliens, compared to other games
- The physical distance between players (light speed/router hops)
Now compare that to NS, which ran at 33 66-100 ticks and had A LOT less data to push through, even that mod had some rare around corner issues with higher latency and it was even faster paced. NS2 aliens kinda got fat and slow
Also this goes for any game, light speed is simply too slow as it can't move any faster through the glass fibers. Not even mentioning the router hops/network distribution time, and the back and forth ping/pong between:
[client X <-> Server interpolation <-> Client Y]
All of which contribute to the "lag" (net lag+router lag+engine lag)
Also it IS netlag, not hitreg. Hitreg is on your screen and has to do with your crosshair and the target. Being shot around a corner means that on the enemy screen at high latency, you are still on their screen. While you, yourself are around the corner on your screen. If anything, if there are hitreg issues that has more to do with client side prediction than server side interpolation. And dem devtype people would request video proof for that
The high speed of NS2 (which is still slower than quake/UT likes, running at 60ticks or more), exaggerates this issue. its exponentially visible for higher latency...
I see but hasnt ping generally dropped lower throughout the years?
Does server use all the cores properly?
Why this isnt in NS2, hardware limitation?
In general ping has improved a small bit through the cables with higher bandwidth and mostly inside server centers which have much faster servers now. But in the end, the actual physical distances between people is still the same. So we kinda reached the limit of our ping improvements. No amount of increased in bandwidth or faster routers/servers is going to change that, unless we finally get a grasp of "predictive quantum computing"
AFAIK NS2 uses ~1.25 core per server? So ie: on an overclocked quad Intel iCore, you could potentially run 3 servers. That tickrate is still abysmal in any case for a bandwidth/CPU hog like NS2
And yeah @antou has a very valid point. Your butt sticks out, especially on that big fat space cow
Source: was a scout main
Source w/ TF2, which is in general faster paced than most other games running on it, has always been crap at netcode. Unlike GoldSrc ironically
And that's not only ironic but weird as well, I mean isn't Source based on GoldSrc/Quake 2?
Yea or if we put cables through the earth lol
So its not taking advantage of the CPU total power, seems like an optimization bottleneck.. maybe with 64 bit multicore optimization that will be adressed.
Except multithreading isn't a magic bullet. NS2 wasn't designed for it and it's also hard to do for multiplayer games in general, mostly running into diminishing returns, more potential bugs and even less performance in some cases, where the engine has to wait on other threads to get it's complete data for something it had to do.
This isn't video encoding with it's predictive nature, easy to track frames, which is made to thread into the world of multithreading
It's not hit reg, as said already.
It's from a slower update between client and server that has to be that way due to performance reasons.
@BeigeAlert
Correct me if I'm wrong but as I understand it, interpolation has less to do with player latency and more to do with send rate. It's to account for interrupted packets between a player and a server, essentially a safety net to always make the player move smoothly and ensure data is delivered.
@Kouji_San mentioned tick rate, but that is just the gate keeper and what people are used to from source engine; it's the send rate that determines what interpolation can be used.
The more frequent you update the player position, the less overlapping coverage you need. (But the tick rate will always need to be set as high or higher than other settings like move rate or send rate.)
For instance, if you double the frequency that you update the player position to the server, you don't have to have the interp safety net as wide because packets can just be resent if one is missed.
The default settings are:
Tick rate 30
Send rate 20
Move rate 26 (used to be 30, but really was 27 in reality due to a bug, and true 30 causes performance issues)
Interp 100 (used to be 150)
Interp was lowered to 100 from 150 due to me pushing the team to do so a few years ago. It can't be lowered until the send rate is increased.
And that can't happen until servers can handle the work load.
Were dynamic rates ever considered?