Dodgy Attacks? Client Prediction?
Sexy_Tool
Join Date: 2003-10-24 Member: 21896Members
Join Date: 2003-10-24 Member: 21896Members
<div class="IPBDescription">5 sg's to kill 1 skulk ? Look here .....</div> I've noticed a few threads about shots not registering etc, and i've decided to post here about a possible solution.
Let me first say what i've noticed about both steam games that i play, counter-strike and half-life / natural selection.
In counter-strike i've noticed that alot of shots simply don't register as hitting their target. The player i'm shooting at walks away with alot or full health, and if you look at the wall behind him you'll see bulletholes from my gun. The bullets seem to pass straight through the player, doing no damage what so ever.
In counter-strike also, when myself and the player i'm aiming are both standing still, i can fire a round and hit the enemy, yet the next round or other following rounds randomly don't register or do register. Considering that both players are standing still, this seems to be quite a problem. Again there are bullet holes behind the player i'm shooting at, yet the armount of bullets that don't register is the same amount of bulletholes behind the player.
In the natural selection mod for half life, i've noticed that aliens can use their melee attacks at point blank range, and their attacks are not registering. This is a major problem as most aliens are only suposed to have a point blank attack range.
Indeed, when disabling client side prediction in either counter-stirke or natural selectoin (cl_lw) i've noticed that it's more than a little "off". For starters, let me explain how client side prediction works.
With client side prediction on, you press the mouse button and on you're end the weapon fires. Say you have a ping of 200, the server receives the attack order 200ms later, and in actual fact you're shot towards other players doesn't count until the server has received that firing signal. It then forwards the required information onto the person you are shooting at. All up it seems to you like you're fired and hit someone when in actual fact the bullet hit 200ms after it appears to on you're screen. This is obviously what makes awp shots while running on 56k so hard to pull off, because you've fired and starting moving again before the server actually registers the shot, meaning the server thinks you were running WHILE you shot.
With client side prediction turned off (cl_lw 0) and an average ping of 200, this is more than likely what will happen. You'll press the fire key, and nothing will happen straight away. Up to 500 milliseconds later though, you're gun will fire and that's the acknowledgement from the server, stating that yes you have fired, but because of you're ping you fired (according to the server) 200ms after you pressed the mouse button.
This is obviously much better for people who have an average ping over 200, because then they can wait and not move while awping until their shot is registered by the server.
Client side prediction isn't "always on"... that is it's not constantly sending information to and from the server. Client side prediction only "samples" you're movements and actions a certain amount of times a second. In the WON version of half life etc this amount of samples per second was quite high, and thus there was no real large problems with shots registering properly.
In steam it seems that the client side prediction sampling rate has been reduced. I can safely say that this is a verifiable fact. Anyone willing to check my research only has to disable client side prediction themselves (cl_lw 0) to see that even with a ping of ADSL speeds, the shot isn't registered with the server until up to 300ms after you pulled the trigger. It's exactly the same sort of performance you would see if you were to have client prediction on and getting a max frames per second of under 20.
What does this reduction in client side prediction sampling rate mean ?
Take a half life death match player for example. Client prediction is on; Now this HLDM player has been playing for years. He bunnyhops all around the place and has an average accuracy of 80%. Under STEAM anyone spectating him bunnyhopping will see him jumping in an almost completely straight line. Yet if you watch the players' computer screen, you'll notice that the player is actually making quite large left - to - right movements in his bunnyhop technique. The client side prediction is not sampling fast enough to get a great detail of information about the players' movements to the server. Thus the other players in the server only see a minimal movement to the bunnyhopper's technique while the player himself is actually making quite large movements.
Apply this knowlegde to this situation;
Client prediction is on;
In counter-strike a player is strafing left and right quite a bit so that they can avoid being shot by an awp. They may in actuality be moving as far as 10 meters left, then moving back to where they come from. All the 56k awper that is trying to shoot him sees, is someone moving left and right on the spot slowly, perhaps even standing still. That's why the 56k awper is thinking "this is BS!" when he fires and, correct to the information on his screen, he DID hit the enemy he was aiming at. But he doesn't die, and there's a bullethole behind the person that is being targetted by the 56k awper.
Sound like a familiar occurence to you ?
Also take this case: (CP on)
There's a CT afk, and a Terrorist lining him up with an automatic rifle. The T lines up the CT's head and fires off 5 rounds. Because he's a 56k'er and has a ping of 200 by the time the server gets the firing signal, the T's crosshair is above the CT's head. Thus he misses. Mean while he's standing there, both him and the CT un-hurt, thinking "WTH is going on?!?!?!"
Now, seeing as these examples are only for 56k'ers, you may think that it doesn't effect ADSL and cable users. This however is where you would be most heinously wrong. Turn client side prediction off "cl_lw 0" and join an internet game. You're average ping is 90, yet when you press the mouse buton to fire, you don't actually fire until the server's confirmed you're firing request 300ms later. "WTH is going on?!" you're thinking, "I suddenly have a ping over 200ms on ADSL / Cable!!!".
This is where you would be wrong again. You're responce time to the server is in actuality 90ms. If you ping the server with CMD you'll notice the same ping shown as what CS says you're ping is when you hold TAB.
So what's causing this delay when you're firing you ask ? Because client side prediction sampling rate has been reduced, and it's causing large problems with shot registration.
Please valve, put the client prediction and net code back to how it was in WON. Things seemed much more stable and reliable in WON, and to prove how unpopular STEAM is compared to WON, simply update the server lists without a filter other than "Game - Counter-Strike" and you'll notice that there are only around 3 000 servers in the world for STEAM. This is compared to 3 HUNDRED thousand servers for WON version of CS before steam came out. STEAM is the reason CS is so un-popular now.
=====================================================
Above is the original message that i posted @ www.steampowered.com/forums
Please input any information you may have, as this looks like true answer to alot of "dodgy" business in NS. Hitbox problems considered, they wouldn't exist without client side prediction being **** like it is.
Let me first say what i've noticed about both steam games that i play, counter-strike and half-life / natural selection.
In counter-strike i've noticed that alot of shots simply don't register as hitting their target. The player i'm shooting at walks away with alot or full health, and if you look at the wall behind him you'll see bulletholes from my gun. The bullets seem to pass straight through the player, doing no damage what so ever.
In counter-strike also, when myself and the player i'm aiming are both standing still, i can fire a round and hit the enemy, yet the next round or other following rounds randomly don't register or do register. Considering that both players are standing still, this seems to be quite a problem. Again there are bullet holes behind the player i'm shooting at, yet the armount of bullets that don't register is the same amount of bulletholes behind the player.
In the natural selection mod for half life, i've noticed that aliens can use their melee attacks at point blank range, and their attacks are not registering. This is a major problem as most aliens are only suposed to have a point blank attack range.
Indeed, when disabling client side prediction in either counter-stirke or natural selectoin (cl_lw) i've noticed that it's more than a little "off". For starters, let me explain how client side prediction works.
With client side prediction on, you press the mouse button and on you're end the weapon fires. Say you have a ping of 200, the server receives the attack order 200ms later, and in actual fact you're shot towards other players doesn't count until the server has received that firing signal. It then forwards the required information onto the person you are shooting at. All up it seems to you like you're fired and hit someone when in actual fact the bullet hit 200ms after it appears to on you're screen. This is obviously what makes awp shots while running on 56k so hard to pull off, because you've fired and starting moving again before the server actually registers the shot, meaning the server thinks you were running WHILE you shot.
With client side prediction turned off (cl_lw 0) and an average ping of 200, this is more than likely what will happen. You'll press the fire key, and nothing will happen straight away. Up to 500 milliseconds later though, you're gun will fire and that's the acknowledgement from the server, stating that yes you have fired, but because of you're ping you fired (according to the server) 200ms after you pressed the mouse button.
This is obviously much better for people who have an average ping over 200, because then they can wait and not move while awping until their shot is registered by the server.
Client side prediction isn't "always on"... that is it's not constantly sending information to and from the server. Client side prediction only "samples" you're movements and actions a certain amount of times a second. In the WON version of half life etc this amount of samples per second was quite high, and thus there was no real large problems with shots registering properly.
In steam it seems that the client side prediction sampling rate has been reduced. I can safely say that this is a verifiable fact. Anyone willing to check my research only has to disable client side prediction themselves (cl_lw 0) to see that even with a ping of ADSL speeds, the shot isn't registered with the server until up to 300ms after you pulled the trigger. It's exactly the same sort of performance you would see if you were to have client prediction on and getting a max frames per second of under 20.
What does this reduction in client side prediction sampling rate mean ?
Take a half life death match player for example. Client prediction is on; Now this HLDM player has been playing for years. He bunnyhops all around the place and has an average accuracy of 80%. Under STEAM anyone spectating him bunnyhopping will see him jumping in an almost completely straight line. Yet if you watch the players' computer screen, you'll notice that the player is actually making quite large left - to - right movements in his bunnyhop technique. The client side prediction is not sampling fast enough to get a great detail of information about the players' movements to the server. Thus the other players in the server only see a minimal movement to the bunnyhopper's technique while the player himself is actually making quite large movements.
Apply this knowlegde to this situation;
Client prediction is on;
In counter-strike a player is strafing left and right quite a bit so that they can avoid being shot by an awp. They may in actuality be moving as far as 10 meters left, then moving back to where they come from. All the 56k awper that is trying to shoot him sees, is someone moving left and right on the spot slowly, perhaps even standing still. That's why the 56k awper is thinking "this is BS!" when he fires and, correct to the information on his screen, he DID hit the enemy he was aiming at. But he doesn't die, and there's a bullethole behind the person that is being targetted by the 56k awper.
Sound like a familiar occurence to you ?
Also take this case: (CP on)
There's a CT afk, and a Terrorist lining him up with an automatic rifle. The T lines up the CT's head and fires off 5 rounds. Because he's a 56k'er and has a ping of 200 by the time the server gets the firing signal, the T's crosshair is above the CT's head. Thus he misses. Mean while he's standing there, both him and the CT un-hurt, thinking "WTH is going on?!?!?!"
Now, seeing as these examples are only for 56k'ers, you may think that it doesn't effect ADSL and cable users. This however is where you would be most heinously wrong. Turn client side prediction off "cl_lw 0" and join an internet game. You're average ping is 90, yet when you press the mouse buton to fire, you don't actually fire until the server's confirmed you're firing request 300ms later. "WTH is going on?!" you're thinking, "I suddenly have a ping over 200ms on ADSL / Cable!!!".
This is where you would be wrong again. You're responce time to the server is in actuality 90ms. If you ping the server with CMD you'll notice the same ping shown as what CS says you're ping is when you hold TAB.
So what's causing this delay when you're firing you ask ? Because client side prediction sampling rate has been reduced, and it's causing large problems with shot registration.
Please valve, put the client prediction and net code back to how it was in WON. Things seemed much more stable and reliable in WON, and to prove how unpopular STEAM is compared to WON, simply update the server lists without a filter other than "Game - Counter-Strike" and you'll notice that there are only around 3 000 servers in the world for STEAM. This is compared to 3 HUNDRED thousand servers for WON version of CS before steam came out. STEAM is the reason CS is so un-popular now.
=====================================================
Above is the original message that i posted @ www.steampowered.com/forums
Please input any information you may have, as this looks like true answer to alot of "dodgy" business in NS. Hitbox problems considered, they wouldn't exist without client side prediction being **** like it is.
Comments
What effect does <b>increasing</b> the client side sampling rate have?
Does it remove some or all of the problem?
When the DoD team hailed the latest version as having much reduced server usage when it was released server usage was the same if not even using more CPU power. They had been testing using a vanilla server and had seen performance increases, when regular server owners piled on mod after mod and stats to their servers there was no change in performance.
Find yourself a vanilla server before you go blaming HLDS, also "In counter-strike i've noticed that alot of shots simply don't register as hitting their target. The player i'm shooting at walks away with alot or full health, and if you look at the wall behind him you'll see bulletholes from my gun. The bullets seem to pass straight through the player, doing no damage what so ever." the client makes bullet holes of where it 'thinks' bullets should land to give the illusion of no lag you should not trust them to comment on your accuracy.
Also, i only play on vanilla HLDS. Gamearena is a vanilla linux HLDS.
Under win32 i've noticed that the HLDS is not as dodgy. Perhaps it's only a linux server?
I host my own NSDS on LAN because i'm an admin @ a net cafe, so i have plenty of opportunities to test things out =]
In reply to Maverick's post, I'd say that increasing the client prediction sampling rate would give for much better attack registration; however it will reduce performance as client side prediction is a large part of the game engine. It may also cause high pings, as the server is now sending/receiving loads more movement / location / animation and rotation packets per second. If you're thinking of making a server side mod to fix it, then i suggest you tie it in with a performance booster / lag reducer. PM me if you want someone to test; i'd gladly put it on my LAN server.
However you are correct that client side prediction can make it look like you hit something when you actually didnt (if the weapon has a random modifier on its trajectory)
Turning cl_lw to 0 will show you where the bullets actually hit, but yes it will be lag x 2 later.
Of course a lot of other things could also be to blame. Over loaded boxes so server companys can sqeeze more money out of us. Or servers with low maxrates.
How many servers have you sampled to see if it is a general pattern?
As jabba said I too remember that no matter how laggy it is, it is always the instance a person shoots that's calculated to see if it hits hence the shooting people around corners situations.
Haven't noticed these problems in NS as much as CS though, which is a good thing I guess. Or I'm blind.
I played CS just 30seconds ago. Maybe these reasons ae true, but I registered none of them. The server had a ping like 90 and I had a ping like 60. I was CT and I stormed in the base. I was crouching and aiming like the T, the distance was like 4meters. We both had M4 and shot at each other. He killed me. His hp was at 100/100. I dont know what happened, but something is very strange. And dont tell me I didnt hit. I play that game for 4years and the distance was very very short, it was impossible not to hit.
You would be wrong there =]
Due to steam's anti-cheat system and steam auto-updating in the background this feature is not possable. If it was, then 56k'ers would have pings much higher than 200 i can guarantee that. If valve have applied what you are saying, then you are looking at on average a 25% increase in lag. Even if it was done server side, you're looking at an increase in required HLDS rescources, not decreased. What you are saying is simply not possible.
On a good pulsegaming server in the UK I get a ping of 20ms, perfect reg and the server runs at 500fps.
200fps = Perfect reg
100fps = Almost perfect reg
< 100fps = Problems
Most NS server have trouble running at 100fps and most hover around 40fps (because of high cpu usage) so there is your choke point, you may be running at 100fps with 101 updaterate, but effectively you are running at 40fps with 40updaterate, hence the poor reg.
This may be where the "sample rate" problem comes into it, with a server with low FPS the sample rate is adversly affected.
EDIT: To see what FPS your server is running at type " rcon stats " in console, obviously you need the rcon password.
However, you can learn to work around them until they are fixed (the steam one probably never). Take a look around the forum to see the shotgun's firing pattern, experiment with firing at different parts of the skulk to get a feel for where the hitbox actually is, etc.
On a good pulsegaming server in the UK I get a ping of 20ms, perfect reg and the server runs at 500fps.
200fps = Perfect reg
100fps = Almost perfect reg
< 100fps = Problems
Most NS server have trouble running at 100fps and most hover around 40fps (because of high cpu usage) so there is your choke point, you may be running at 100fps with 101 updaterate, but effectively you are running at 40fps with 40updaterate, hence the poor reg. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
after running several servers (both linux and windows) with various mods and tweaking them, i think i fully agree with this. the servers' framerate has a large impact on how readily hits "register" on other players, and since ns servers run <b>horribly</b>, it serves as a reasonable explaination for why ns has so many weird "hitbox bug" type problems.
<!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
This is just the most blatant of errors in your posts - bulletdecals are with prediction on, drawn entirely randomly. With it off, they should be drawn on the actual impact - but those are only a hit if you're able to lead your target in relation to your latency. Theres a few bugs with CoFs in ns not displaying correctly though with cl_lc and cl_lw 0, while they're actually registering correctly.
Furthermore, the time you'd see the firing confirmation is obviously not the time the server is able to first register it - its up to <b>double</b> that - the packet has to go to the server, be processed, and finally make its way back to you in an update. Its not anything near an accurate representation of whats happening.
And most importantly, <i>your latency below 500 ms (directly to the server, not back and forth) shouldn't impact your hit registration too heavily</i>. This is assuming ideal world conditions where you have no loss and are still getting the same amount of updates/second that an LPB is getting - theres this nifty thing called the server backlog, which is the <b>whole damn reason</b> we have clientside prediction. Your bullets have timestamps to go with them, and when the server receives them he checks on his own side wether the target was where you aimed (he also calculates CoF, which is why clientside decals are random). I don't know why you attempt to discard this fact, but I can gaurantee you if it were not so we'd never land fire on anything not standing still were it not so. The only real fault in the system is that only positions that were rendered on the server can be hit - so if the server runs a measly 10 updates/s, those are 10 spots in the course of a second that can be hit, and the predicted movement inbetween is prettymuch fake.
@Titanium:
NS supposedly runs horrible on Linux servers, which last I heard was what all NSPug servers use.
I saw the blood on my screen so they ought to have registered. What really surprised me was that one of the other marines also saw the blood, and yet the bites did not register despite the server obviously seeing them.
The closest thing to that I've seen is when players were lagging out and about to drop from the server, weird stuff like that would happen (or on players with the RC overflow bug joining a new game).
You would be wrong there =]
Due to steam's anti-cheat system and steam auto-updating in the background this feature is not possable. If it was, then 56k'ers would have pings much higher than 200 i can guarantee that. If valve have applied what you are saying, then you are looking at on average a 25% increase in lag. Even if it was done server side, you're looking at an increase in required HLDS rescources, not decreased. What you are saying is simply not possible. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
This has nothing todo with steam and I fail to see how auto updating and anti cheat effect this.
This was implemented as a patch back before I started playing half life. Originally yes you had to aim ahead of people to shoot them. Now what half life does is this...
client sends time data (to the millisecond) with its datapackets (at the very least this just happens when a weapon has been fired, at the very most with every datapacket, I dont know (would guess with movement and weapon firing))
When the server recives a weapon fired message from one of its clients, it works out if the shot hit at the time the shot was fired (it has saved the position of every client connected for a reasonable time into the past)
I believe (not sure on this) that the server stores 2 seconds of previous players locations etc.
Ok because it is only storing the data the increase in processing is only in accessing that data (which is a very small increase) the big increase comes in the memory imprint from the stored data, but since servers always have plenty of memory this is not a problem.
There have been an extreme amount of changes over the HLDS since steam was released. I hate to point it out, but even before steam was public official release the HLDS versions 3 and over were all STEAM HLD server's. Also, if you look in you're WON version instal of CS or HL you'll notice a hell of alot of STEAM related content in it. Steam has been around longer than you realise in both WON and HLDS environments, and i'll tell you now that there have been a few major changes in the way HLDS has been implemented in STEAM.
Jabba, also I would say that this backlog you are talking about it either buggy, or simply doesn't exist.
The reason behind this is; on counter-strike 1.6 servers i find that the server freezes often, for up to a second. Obviously there's no data going to and from the server, yet once it un-freezes there are bulletholes and indeed people have even died as if the server never froze, yet every client connecting to it solid locked for a second. In this respect the action that's happened in that second of frozen time is entirely fictional; that is to say that the server predicted it all, in it's entirety, without any feedback from the clients. And the reason for this is because the server doesn't realise it's frozen, it has no time stamps on events and so it simply beleives nothing wrong has happened and it continues doing prediction calculations right from the point before it froze. As a result players end up having moved several meters in that second that they were frozen, bullet shots are calculated and people die or end up being hurt when in fact there has been no fire signal sent to the server. If the server truly kept backlogs with timestamps, then this action woudln't happen. I'd simply notice that there's an error in the timeline of events and dis regard all information over that last second. If it didn't disregard it, then the server would crash!
Saltsbad, i'd like to see some kind of evidence to back that statement up... especially seeing as bulletholes are almot completely client side in NS. The only weapon that has bulletholes calculated server side is the shotgun, obviously because of it's very nature. Regardless of what the client chooses to display, consider watching someone else firing in NS and their bullets seem to go perfectly straight. If you turn cl_lw 0, then you notice that you'rs do not go perfectly straight. Is it a coincidence that the client displays something entirely different to what the server is receiving? This is only for NS it seems, in CS the bulletholes are going to the same location regardless of client prediction settings.
I cannot verify if a steam HLDS acts the same, because the steam hlds is vastly different to the WON. However, i can safely say that the STEAM dedicated server acts vastly different to the WON because of the new client prediction. An exmaple of this is the sparkler shotgun effect that still exists to a large extent in NS.
What i'm convinced happens there, is that the server is correcting client side prediction and not registering the shot. This can clearly be seen by leaping skulks when you have a high ping. You leap, and half way through you're leap you stop almost dead as the server corrects client side prediction and puts you're hitbox back where the server calculates you to be. This is especially buggy when the server is only updating at around 10 fps like you've said. This is why i think the entire client side prediction and server calculation procedure has to be re-written. The data that is being sent to the server in many circumstances is vastly different to what the server is calculating, and thus you get dodginess.
I realise that i didn't properly explain the update times in my original post, and you are correct that the firing confirmations seen by a client when cl_lw is turned off is entirely up to more than double you're ping. Yet that is not the point, the point is that with cl_lw off, that time gap between server shot registration and client side shot confirmation is echoed by the ping that the person you are shooting at has. All up you've got a reliable indicator of where you're shots are going and what you're hiting, as long as you have an average ping the same as the rest of the people in the server. This is why i found 56k'ers so hard to hit with cl_lw off, because the timegap difference was greater for the target's communication than it was for my connection.
In future posts, please explain the acronyms you are using. I am not a developer, and no matter how much i want to be i don't have the time to learn c++ to become one. The reason i know this much about the half life engine and steam etc is because i've been deeply involved in this sort of activity for the last 6 years, litterally since half life first came out. When you are playing with an average ping of 400 to 600 on 56k you try and figure out why you're missing shots when aiming at what you want to hit, and that's what sparked my curiousity about how the HL engine works.
I don't mean to cause offence to any of you, but regardless of developer / coder / modder knowledge, i've always found that my knowledge has been correct, so i may seem a bit stubborn in my findings as i have quite literally never been wrong.
ROFL. For your own sake stop posting until you learn that making stuff up because you don't know any better isn't the same as having a actual researched & verified facts. SaltzBad, rKnZ & JabbatheHunt explain the reality of how HLDS works and you carry on regardless with totally random stuff which is completely unsubstantiated.
This last post of yours has so much made up rubbish in it I could spend an hour proving you utterly wrong but there would be no point as you've not actually listened to anyone else so far why would I be any different?
You look like someone who has abolutely no idea what they are talking about, because you have stated i'm way off the mark, when i know for fact that i'm actually alot closer to understanding the HLDS more than most.
If you're a developer, then put down you're ideas and you're evidence that would prove the existence of what the other posters have been saying.
In case you didn't know, SaltzBad, rKnZ & JabbatheHunt are not developers / modders and if they were, they would give feedback with real evidence. I suggest you do the same or else look like a prepubescent wanktard that just posted to try and insult me.
However, you are forgetting that i have never been wrong in this respect, it's the reason why i'm an admin at a net cafe. I know the HL engine and the HLDS better than anyone except the coders who actually write it. If you are one of those people, then by all means post some evidence to prove me wrong as i would really like to get a clearer picture about how it works.
If you don't, well you're just what i said - someone trying to stir me up.
You've haven't substantiated you're claims what so ever, and personally i'm offended that someone has the gall to talk to another person like that, when i've put down logical assumptions and trains of thought that prove my points. You've done nothing of the sort and indeed try saying i've disregarded what others have posted.
I have thoroughly read through the other's posts, as well as considered what they are talking about, and found large flaws in their theories. So why don't you back up what you're saying? If i was just going to ignore what others have said in this thread, then i wouldn't be replying to you would I? and i wouldn't be taking the time to prove otherwise about the other posters' theories.
But meh believe what you want to believe.
If i evre get the time i am going to learn c++, and obviously my next step from there is going to be developing the HLDS + HL / STEAM clients.
So please give what ever information you can.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->In case you didn't know, SaltzBad, rKnZ & JabbatheHunt are not developers / modders and if they were, they would give feedback with real evidence. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--> I am not a developer, and no matter how much i want to be i don't have the time to learn c++ to become one. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Do less drugs next time, and <b>remember what you said 5 minutes ago.</b> Kthx.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->This is why i think the entire client side prediction and server calculation procedure has to be re-written. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
It does show you've never coded.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->And the reason for this is because the server doesn't realise it's frozen, it has no time stamps on events and so it simply beleives nothing wrong has happened and it continues doing prediction calculations right from the point before it froze.<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Information is re-sent, and is likely to be processed when the server recommences functioning. None of those symptoms indicate its 'predicting' anything - worse yet with your theory is that seeing as how the server is most likely locked up, it might not currently be doing anything at all (as its likely not a network issue, unless its on the LAN the machine is on or something).
HL servers do check back to where the player was when you fired. I'm not sure if it records actual positions or just linearly extrapolates back using the current velocity or something(just logging positions seems much smarter). To realise this you can note 2 phenomenoms, being "shot around corners" in a game like NS even though your ping time to the server is very low(the other players ping time being high), shooting ahead of targets you will ALLWAYS miss them, unlike the old netcode where you had to shoot ahead of them. This change happened back in 1999/2000 something(version 1.1.0.0).
There's still a few old archived news from this time if you google and alot of annoying broken links.
<a href='http://www.planetquake.com/rocketland/haqsau/hl1100.shtml' target='_blank'>This</a> one has all the relevant information summed up nicely.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin--># New net code:
* More efficient protocol -- less bandwidth required.
* Client frame rate is asynchronous from server frame rate -- you can now run high frame rates even on a low bandwidth client.
* Lag compensation for hitscan weapons -- allows high ping players to aim as if they were on a LAN connection (note that as of the date of the original patch release only Team Fortress and Counter-Strike made use of this feature).
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
ex_interp(now that it works correctly and isn't really exploitable for evil deeds) lets you choose the maximum amount of time extrapolations will be applied to playermovement. Default is 100 ms, every <100 ms it MUST get a new player position or the player will appear to stutter or freeze.
If I'm not mistaken server side lag compensation can still be turned off on the server for old style netcode.
I would guess that a lot of hit reg issues occur because most players have a low cl_updaterate(20 is default) but on your side their movement is extrapolated(unless you increase your updaterate and lower ex_interp) so you might aim at a position they have never even been in if they move fast(think skulks) and the server might not take extrapolation into account. Lowering ex_interp should relieve this problem if this is the case, and it seems to do so quite nicely.
<!--QuoteBegin--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> </td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Please valve, put the client prediction and net code back to how it was in WON. Things seemed much more stable and reliable in WON, and to prove how unpopular STEAM is compared to WON, simply update the server lists without a filter other than "Game - Counter-Strike" and you'll notice that there are only around 3 000 servers in the world for STEAM. This is compared to 3 HUNDRED thousand servers for WON version of CS before steam came out. STEAM is the reason CS is so un-popular now.
<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
****, there are 20000 CS servers right now, do as you yourself suggested and you will see. CS has NEVER had 300 000 servers, no chance in hell. In fact, CS is about as big if not bigger than it ever was on WON.
Just about every point i've tried to prove, this page on planetquake proves.
For starters if you read you'll notice that;
-The netcode for half-life games has changed under STEAM (Not there is no longer cl_lb, as blood is now server-side).
-+ Also no such thing as pushlatency anymore.
-If the client side prediction rate has been lowered, then it would cause magnification of the errors described in both my posts, and this article. I see these magnified errors every day.
-take the following extract from the article:
"As best as I have been able to determine, the target player will now have to deal with a prediction error correction (for the hitscan weapon attack only) corresponding to the average of his latency and the attacker's latency, whereas without lag compensation an attack would only have to be corrected by about half of the target player's latency. Take the situation where a high pinger with a latency of 300 msec is facing a low pinger with a latency of 50 msec. The average of these two is 175 msec. Half of the high pingers latency is 150 msec, half of the low pingers latency is 25 msec. If the low pinger attacks, the high pinger won't even notice the difference - his error correction changes from 150 msec to 175 msec for one single attack. But if the high pinger attacks, the low pinger's error correction is going to increase from 25 msec to 175 msec, which is a huge change. And since it is momentary and unpredictable, it is very difficult to deal with during play. For low pingers, it can literally make a cable connection feel like a 28k modem."
This is bad enough under WON perhaps? With the changes to the netcode under STEAM, perhaps this is the cause of the shotgun sparkler bug.
Lastly, Soylent Green where are you getting you're stats from?
Everytime i go to <a href='http://www.steampowered.com/status/status.html' target='_blank'>http://www.steampowered.com/status/status.html</a> i get these approx numbers:
current min max
n Player Count 70,176 49,361 107,328
n Server Count 48,221 41,269 51,941
you heard wrong
Steam game server list is reporting 18, 863 counterstrike servers for me.
By doing exactly as you suggested. Set the game filter to CS and untick all other filters and do a full update. Comes out to ~20000 CS servers right now, and it's mid day on a monday(well, here...) so it should go quite a bit higher.
(I still see ~20000 CS servers, certainly, it is much higher than a mere 3000 as you suggested. And where do you get the idea that WON HL ever had 300 000 servers? Also quoting all HL MOD servers and claiming them to be CS servers will inflate the actual number by quite a bit I'd imagine)