Server issues don't explain why some people don't seem to have those problems and kill what they shoot at in no time. I think client performance advantages explain my case better.
Thanks for all the input.
@ZeroEarTh: I play on EU servers - YO, SEK and Thirsty Onos mostly.
GhoulofGSG9Join Date: 2013-03-31Member: 184566Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Reinforced - Supporter, WC 2013 - Supporter, Pistachionauts
Still name and shame is not allowed here, you should know that by now. Also since build 272 the send-rate gets lowered dynamically in case that the cpu can't keep up with the default one.
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
wait, what... update rate is automaticly lowered on high cpu usage?
Wouldnt it be more efficient to let the server die so all know its crap?
Also at which % does this kick in?
AsranielJoin Date: 2002-06-03Member: 724Members, Playtest Lead, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow, Subnautica Playtester, Retired Community Developer
No it wouldnt be more efficient for the players. This leads to a better user experience (but a bad performance rating in the server browser). There might be a post from matso somewhere in the forum explaining the technical details
DC_DarklingJoin Date: 2003-07-10Member: 18068Members, Constellation, Squad Five Blue, Squad Five Silver
No I meant that lowering the update rate 'fixes' server performance a bit, instead of causes more interp overruns. So it would keep the server from getting a bad score longer
I seriously believe there's a bug/quirk of the netcode so
* certain players
* sometimes an entire team
get advantaged regarding 'effective' latency.
Sometimes i can't hit ****/bites don't register, and the next game there's a huge difference.
Sometimes a team does not get many kills and loses badly, and the next game (similar teams, because shuffle) suddenly they rock.
It is too pronounced to explain otherwise. And i' ve never seen anything like it in other games.
Just wanting to voice my opinion but only with anecdotes so f*** it. Played for about 4 hours last night on multiple servers all of them performing fine, in every alien game I played as skulk/fade. I averaged about 5 failed regs per game. The bite/swipe registers as a hit graphically but no damage registration even when the target is 100% hit on my screen and FULLY in my crosshair, direct center, the bite/swipe fails, even parasites don't register at times.
As marine, it seems less obvious but I did notice a few blatant hit reg problems. Shotgun for me has generally been reliable up to this point, I actually haven't had a problem with it in the past and never really noticed my shots not registering but I did get a taste of the issue @schu had, a full shotgun blast hitting a skulk and zero damage. I noticed a few rifle problems in the same vein as my previous comment on this thread.
I think I have to start streaming/recording my gameplay because either its some sort of pseudo-placebo effect since the recent patches or there is a problem and I need to evaluate it. Speaking to some regulars among multiple servers, some good pub players have noticed a significant positive correlation associated with increased hit reg problems. Multiple servers that I've very rarely seen performance or latency issues on leads me to believe its not likely to be server specific. It's getting pretty frustrating.
I seriously believe there's a bug/quirk of the netcode so
* certain players
* sometimes an entire team
get advantaged regarding 'effective' latency.
Sometimes i can't hit ****/bites don't register, and the next game there's a huge difference.
Sometimes a team does not get many kills and loses badly, and the next game (similar teams, because shuffle) suddenly they rock.
It is too pronounced to explain otherwise. And i' ve never seen anything like it in other games.
Glad I am not the only one. I've played so many hours of this game, sometimes I feel like I notice subtleties like this. Aside from personal inconsistencies (playing while sick, hungry, hungover), it really does seem that servers can perform differently on different rounds. It might have something to do with a server restart/map change, player count or all of the above. Other times a round feels beautiful.
And I don't think I experience much of this on lower player count servers.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
@RaZDaZ
If you CAN record ways to reproduce hit reg issues, that'd be great, but we definitely are able to reproduce at least one issue so far that we think is related to all of the edge case scenarios..
So just keep that in mind.
If you still want to help by providing videos showing other ways to reproduce the issue that would be very welcomed.
Keep in mind we need: 720p 30fps or better, with net_stats enabled. Bonus points for having collision on (don't try to play a real game with this enabled, obviously)
I seriously believe there's a bug/quirk of the netcode so
* certain players
* sometimes an entire team
get advantaged regarding 'effective' latency.
Sometimes i can't hit ****/bites don't register, and the next game there's a huge difference.
Sometimes a team does not get many kills and loses badly, and the next game (similar teams, because shuffle) suddenly they rock.
It is too pronounced to explain otherwise. And i' ve never seen anything like it in other games.
THIS. A thousand times this. I've played several PUGs a day since the latest build was released and the above issue happens every. single. map.
I can't stress enough how blatantly broken and random this is.
I sincerely hope the CDT has some track of this issue.
@schu Not without netstats enabled as mentioned in every thread about hitreg ever.
Server tickrate drops, packet loss etc, network effects not related to NS2's hitreg can cause the issue like you see in that old old video.
Keep in mind we need: 720p 30fps or better, with net_stats enabled. Bonus points for having collision on (don't try to play a real game with this enabled, obviously)
Client performance WILL affect your hitreg - the minimum lag between what you see on the screen and what you shoot at are about 3 fps because of the way NS2 produces frames, so at fps 30 you need to think about 100ms into the future, at 200 fps it's just 15ms.
This is not unusual, most shooters have the same or even worse. What other shooters don't have is melee combat with aliens moving at 15m/s at point blank range (also, NS2 generally requires quite a bit more hardware to get high fps).
It is normal for developers to sacrifice input latency for the sake of taking advantage of multi-threading and for smoothing out rendering with 3 or more frames in a flip queue, but is it actually desirable to do so? If NS2 has to be pipelined like this across several frames for performance reasons, is it possible to defer player actions and add a pass just before rendering commences to take input, update view angles etc? This would certainly require less aggressive culling so that you could spin 5 degrees and still render the frame without visual discrepancies.
Once upon a time, 50 or 60 FPS was enough to have no discernible input lag; this was the time of super mario on the NES or delta on the C64. These games literally raced the beam; drawing occured just in time by special blitter hardware just as the electron beam swept across the line on the display where sprites were to be drawn.
Single-core games of the late 90's and early naughties were pretty close to this ideal and worked something like this:
All tasks not affected by user input is performed (updating world, AI, rag doll physics if present...)
Player input is processed and player is updated. Anything that can be predicted on the client is predicted on the client.
Occlusion culling is performed
Animations etc. are done on objects that are still visible after culling is performed.
Rendering is performed and the rendered frame is presented.
The result of the input is displayed on screen as soon as the screen updates.
The latency here is the latency in peripherals (due to sampling rates, debounce delays and such) + one frame of latency + display lag (which may be as high as 50 ms on crummy displays, but was pretty damned close to 0 ms on a CRT). I don't remember anyone complaining about input latency back then and I don't remember it being a concern for me either. It wasn't even on the radar.
The way most games actually work today is something more like this:
On the first frame you take input and you update the world, do physics.
On the second frame you do rendering in direct 3D.
On the third frame direct 3D talks to the device driver and the graphics card does the actual rendering.
On the fourth frame the finished frame languishes in the flip queue.
On the fifth frame it is finally presented on screen.
All these stages are occuring at once, but different frames are processed on each stage in the pipeline. This allows multiple cores and multiple graphics cards to eek out the very best framerate, but at a terrible cost of input latency. Most games have noticable and annoying input latency which is pretty insufferable in any kind of online, competitive environment; it is a frequent topic on the forum of any such game and there is much whining and gnashing of teeth. Can we fix this?
Train your aim "ahead" your target , reduce mouse sensivity to 5.0 , then increase if you feel tracking motion of enemy is "slow"
This is because your aim , not hit reg >> I see its fine comapre to Left4Dead2 when you have to shoot/ dead-stop Hunter while they flying
This analogy sucks because a hunter cannot change his trajectory while in the air in the same way a fade can or a skulk can with leap so there's not much prediction of movement, just timing a button. A hunter can wall-jump and change falling direction a bit but a fade has much greater control of air movement.
Marines are easy to hit as an alien in general but what matters is consistency. How often in a game are you going to be dead-stopping a hunter compared to how many times you will swipe/bite a marine? In addition, the key to victory is not dead-stopping a hunter over and over, it's an effective way to kill a hunter but its not the most important capacity to kill the survivor team. Aliens all rely on a similar model for dealing damage to a marine, melee bites/swipes/gores and they are so, so much more important than a dead-stop to eliminate hit-reg issues with.
When I see a fade swipe HIT the marine model, blood spatters/swipe sound effect changes but no damage that is not because of aim. That is purely, purely evident of a hit on YOUR screen but the server doesn't register it. It's much more difficult to accurately identify a hit registration issue in the case of dead-stopping a hunter because latency, game mechanics and human reaction speed are considerable confounding variables.
Today I missed a marine by a good 3-4 feet (behind him, from a distance of about 20 feet) and while he didnt become parasited, he made the OUCH noise as if it hit. EXPLAIN THAT ONE
Comments
Thanks for all the input.
@ZeroEarTh: I play on EU servers - YO, SEK and Thirsty Onos mostly.
But what made you think I have not contacted the operators already?
Has it been difficult to keep up with your tech support volunteer work? Somewhere I heard you're involved in other projects.
@GhoulofGSG9 So is that disallowed for CDT members, too, or is it based on individual mood? Please make up your mind. Thank you.
Wouldnt it be more efficient to let the server die so all know its crap?
Also at which % does this kick in?
* certain players
* sometimes an entire team
get advantaged regarding 'effective' latency.
Sometimes i can't hit ****/bites don't register, and the next game there's a huge difference.
Sometimes a team does not get many kills and loses badly, and the next game (similar teams, because shuffle) suddenly they rock.
It is too pronounced to explain otherwise. And i' ve never seen anything like it in other games.
As marine, it seems less obvious but I did notice a few blatant hit reg problems. Shotgun for me has generally been reliable up to this point, I actually haven't had a problem with it in the past and never really noticed my shots not registering but I did get a taste of the issue @schu had, a full shotgun blast hitting a skulk and zero damage. I noticed a few rifle problems in the same vein as my previous comment on this thread.
I think I have to start streaming/recording my gameplay because either its some sort of pseudo-placebo effect since the recent patches or there is a problem and I need to evaluate it. Speaking to some regulars among multiple servers, some good pub players have noticed a significant positive correlation associated with increased hit reg problems. Multiple servers that I've very rarely seen performance or latency issues on leads me to believe its not likely to be server specific. It's getting pretty frustrating.
I hope I'm wrong.
Glad I am not the only one. I've played so many hours of this game, sometimes I feel like I notice subtleties like this. Aside from personal inconsistencies (playing while sick, hungry, hungover), it really does seem that servers can perform differently on different rounds. It might have something to do with a server restart/map change, player count or all of the above. Other times a round feels beautiful.
And I don't think I experience much of this on lower player count servers.
If you CAN record ways to reproduce hit reg issues, that'd be great, but we definitely are able to reproduce at least one issue so far that we think is related to all of the edge case scenarios..
So just keep that in mind.
If you still want to help by providing videos showing other ways to reproduce the issue that would be very welcomed.
Keep in mind we need: 720p 30fps or better, with net_stats enabled. Bonus points for having collision on (don't try to play a real game with this enabled, obviously)
THIS. A thousand times this. I've played several PUGs a day since the latest build was released and the above issue happens every. single. map.
I can't stress enough how blatantly broken and random this is.
I sincerely hope the CDT has some track of this issue.
Or did I misremember?
This is because your aim , not hit reg >> I see its fine comapre to Left4Dead2 when you have to shoot/ dead-stop Hunter while they flying
@schu Not without netstats enabled as mentioned in every thread about hitreg ever.
Server tickrate drops, packet loss etc, network effects not related to NS2's hitreg can cause the issue like you see in that old old video.
It is normal for developers to sacrifice input latency for the sake of taking advantage of multi-threading and for smoothing out rendering with 3 or more frames in a flip queue, but is it actually desirable to do so? If NS2 has to be pipelined like this across several frames for performance reasons, is it possible to defer player actions and add a pass just before rendering commences to take input, update view angles etc? This would certainly require less aggressive culling so that you could spin 5 degrees and still render the frame without visual discrepancies.
Once upon a time, 50 or 60 FPS was enough to have no discernible input lag; this was the time of super mario on the NES or delta on the C64. These games literally raced the beam; drawing occured just in time by special blitter hardware just as the electron beam swept across the line on the display where sprites were to be drawn.
Single-core games of the late 90's and early naughties were pretty close to this ideal and worked something like this:
All tasks not affected by user input is performed (updating world, AI, rag doll physics if present...)
Player input is processed and player is updated. Anything that can be predicted on the client is predicted on the client.
Occlusion culling is performed
Animations etc. are done on objects that are still visible after culling is performed.
Rendering is performed and the rendered frame is presented.
The result of the input is displayed on screen as soon as the screen updates.
The latency here is the latency in peripherals (due to sampling rates, debounce delays and such) + one frame of latency + display lag (which may be as high as 50 ms on crummy displays, but was pretty damned close to 0 ms on a CRT). I don't remember anyone complaining about input latency back then and I don't remember it being a concern for me either. It wasn't even on the radar.
The way most games actually work today is something more like this:
On the first frame you take input and you update the world, do physics.
On the second frame you do rendering in direct 3D.
On the third frame direct 3D talks to the device driver and the graphics card does the actual rendering.
On the fourth frame the finished frame languishes in the flip queue.
On the fifth frame it is finally presented on screen.
All these stages are occuring at once, but different frames are processed on each stage in the pipeline. This allows multiple cores and multiple graphics cards to eek out the very best framerate, but at a terrible cost of input latency. Most games have noticable and annoying input latency which is pretty insufferable in any kind of online, competitive environment; it is a frequent topic on the forum of any such game and there is much whining and gnashing of teeth. Can we fix this?
This analogy sucks because a hunter cannot change his trajectory while in the air in the same way a fade can or a skulk can with leap so there's not much prediction of movement, just timing a button. A hunter can wall-jump and change falling direction a bit but a fade has much greater control of air movement.
Marines are easy to hit as an alien in general but what matters is consistency. How often in a game are you going to be dead-stopping a hunter compared to how many times you will swipe/bite a marine? In addition, the key to victory is not dead-stopping a hunter over and over, it's an effective way to kill a hunter but its not the most important capacity to kill the survivor team. Aliens all rely on a similar model for dealing damage to a marine, melee bites/swipes/gores and they are so, so much more important than a dead-stop to eliminate hit-reg issues with.
When I see a fade swipe HIT the marine model, blood spatters/swipe sound effect changes but no damage that is not because of aim. That is purely, purely evident of a hit on YOUR screen but the server doesn't register it. It's much more difficult to accurately identify a hit registration issue in the case of dead-stopping a hunter because latency, game mechanics and human reaction speed are considerable confounding variables.