<!--quoteo(post=1995935:date=Oct 24 2012, 06:46 AM:name=Argathor)--><div class='quotetop'>QUOTE (Argathor @ Oct 24 2012, 06:46 AM) <a href="index.php?act=findpost&pid=1995935"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Especially considering his reply was to a blatant and hostile troll.
Anyway, these are very complex changes to be making a week before release and shows how dedicated UWE are to giving us the best user experience possible, exciting times!<!--QuoteEnd--></div><!--QuoteEEnd-->
I thought the last patch made a pretty big leap as far as performance. I've never really had any issues with frame rate but I can tell other people have cause a lot of marines became better shots over night with that last patch.
I am just a random observer but I found myself overly curious about the specifics of why he got banned. Anyone care to elaborate for me in a PM? I am genuinely interested not to have something to laugh at but I would like to know the basis and reasoning.
As for the topic in CS:S If i remember correctly even server admins were not all that knowledgeable about it. I remember people getting banned over having there personal settings not as the admins wanted them to be.
There were people who felt that being able to manipulate your personal Cmdrate and Tickrate was a violation of fair gaming tactics. Or rather more aptly put the Baseline that all players starting out have the same tools/chances as the next person with exception to the speed of there personal rig/distance to the server. I can't reliably remember if any of it was confirmed 100% but essentially people were complaining about the following.
#1 purposefully lowering the settings to essentially create lag involving there character to obtain easier kills. #2 having a higher rate then other members of the server who were unaware that it could be changed, therefore creating a skill gap that shouldn't exist. #3 Foolish manipulation of these settings by users who really had no idea what they were for/did and caused issues in games.
Ended up forcing a config /check to ensure settings were in line with the servers if i do recall. If you didn't allow the config check the server wouldn't let you in. This also ended up in admins exploiting the feature by essentially erasing all data in the config file like key binds. This would force the user to delete the config file and re-download from steam forcing the person to re-setup there configurations, key binds, ect lol. I remember one event specifically where the admins would bind all keys but backwards for any person joining to type kill in the console.
I will tell you what though from a person who used to play CS:S all the time Cmdrate, and tickrate/servmaxtickrate can definatly make a huge difference on gameplay outcomes especially when everyone on the server has different values. I can't remember the name of it but there was one other console command cs:s had that was always messed with i think it was bandwidth allowed or something like that.
One thing I would like to add to my ramblings is that when CS:S did force all clients to adhere to the same cdmrate/tickrate as the server I noticed that the gameplay became much more even. There were far fewer players that would just dominate every round, and it almost seemed for a time that it worked. Servers became less laggy, and the tick rate of a server meant the tick-rate of all it's inhabitants as well.
<!--quoteo(post=1995946:date=Oct 24 2012, 07:12 AM:name=Sherwood)--><div class='quotetop'>QUOTE (Sherwood @ Oct 24 2012, 07:12 AM) <a href="index.php?act=findpost&pid=1995946"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I will tell you what though from a person who used to play CS:S all the time Cmdrate, and tickrate/servmaxtickrate can definatly make a huge difference on gameplay outcomes especially when everyone on the server has different values. I can't remember the name of it but there was one other console command cs:s had that was always messed with i think it was bandwidth allowed or something like that.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think the rate hacking from NS1 showed us that giving players the ability to customize the way they send and receive data is not a good idea. Furthermore it provides absolutely no necessary utility.
I looked it up the command I was thinking of Was Rate which was specifically to do with determining the speed of your internet. I.e. if you were on 56k it might be 3000, but people would set it to 50,000 which meant a T1/T3 internet connection lol. I know I always did.
Interp I had forgotten about though I can't remember exactly what it modified.
Google search came up with a Guy going in to detailed explanation.
<!--quoteo(post=1995955:date=Oct 24 2012, 07:44 AM:name=Sherwood)--><div class='quotetop'>QUOTE (Sherwood @ Oct 24 2012, 07:44 AM) <a href="index.php?act=findpost&pid=1995955"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I looked it up the command I was thinking of Was Rate which was specifically to do with determining the speed of your internet. I.e. if you were on 56k it might be 3000, but people would set it to 50,000 which meant a T1/T3 internet connection lol. I know I always did.
Interp I had forgotten about though I can't remember exactly what it modified.<!--QuoteEnd--></div><!--QuoteEEnd-->
Even better, you set it really low, because in practice it is horribly biased towards the upload rather than the download. I don't know if it was the same everywhere, but during NS1's heydays, where I'm from, internet bandwidth was massively divided. We had about 30% of players on 56k, 60% on ISDN 64-128k, and the rest on ADSL lines ranging from 1 meg to 10 meg. This meant that simply capping the rates off wasn't really an option. Thus you got people who had 10 meg connections, warranting rates of 20k + who would instead use values around 3000-4000. What they saw from their side was close to unchanged, but what other people saw... my god... it was an abomination. The truly fast players would teleport so much that you would have about 3 discrete positions to shoot at every 20 or so meters.
Let the core system parameterize itself automatically. Let the user change what kind of anti aliasing they like to see.
Yea I would hate to see that level of customization in NS2 via console just simply because having access to those commands is going to allow the same kind of rate/tickrate exploitation we saw in CS:S.
Ironically while I was doing a search for the old command I ran across some forums for the new game CS:GO and there were a large number of people discussing the same commands CL_rate, CL_cmdrate, CL_Interp, CL_Interp_Ratio, CL_Updaterate
Seems like CS:GO is just as open to the rate exploitation as CS:S was.
I don't know if people might be like why is this guy bringing up CS over and over, well NS1 was based on the HL engine as a mod and so was CS they were both birthed from the same game so to speak. They also contained many of the original console commands from HL, and it is a very potent correlation to compare how they were abused(in NS1 and CS/CS:S) to this game NS2. But that is where the similarities stop NS2 having a completely knew engine and all =), with as some have pointed out new ways of computing that information.
For the many of you that were already aware of this and are like Duh... please disregard lol.
<!--quoteo(post=1995946:date=Oct 24 2012, 01:12 AM:name=Sherwood)--><div class='quotetop'>QUOTE (Sherwood @ Oct 24 2012, 01:12 AM) <a href="index.php?act=findpost&pid=1995946"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I am just a random observer but I found myself overly curious about the specifics of why he got banned. Anyone care to elaborate for me in a PM? I am genuinely interested not to have something to laugh at but I would like to know the basis and reasoning.<!--QuoteEnd--></div><!--QuoteEEnd--> His post was interpreted as "I'm an angsty, arrogant competitive player," which goes against the first commandment of the uwe forums. In reality he called out either a troll or a fool who presented his post in a matter-of-fact manner and corrected him with useful information. Banning someone that has been an asset to the community for years (notice demo detective under his name indicating he was essential in spotting hackers) is more important than someone who <i>is</i> wrong being corrected in a blunt manner because they could possibly get their feelings hurt over an internet comment that was automatically censored. But similar comments, like the one in his signature, are allowed to slip by on a daily basis due to a community and moderation bias.
<!--quoteo(post=1995946:date=Oct 24 2012, 01:12 AM:name=Sherwood)--><div class='quotetop'>QUOTE (Sherwood @ Oct 24 2012, 01:12 AM) <a href="index.php?act=findpost&pid=1995946"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->#1 purposefully lowering the settings to essentially create lag involving there character to obtain easier kills. #2 having a higher rate then other members of the server who were unaware that it could be changed, therefore creating a skill gap that shouldn't exist. #3 Foolish manipulation of these settings by users who really had no idea what they were for/did and caused issues in games.<!--QuoteEnd--></div><!--QuoteEEnd--> All of these can be a non-issue with proper coding, while still allowing people to tune their connection settings if they aren't optimal.
<!--quoteo(post=1995958:date=Oct 23 2012, 11:09 PM:name=Sherwood)--><div class='quotetop'>QUOTE (Sherwood @ Oct 23 2012, 11:09 PM) <a href="index.php?act=findpost&pid=1995958"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Ironically while I was doing a search for the old command I ran across some forums for the new game CS:GO and there were a large number of people discussing the same commands CL_rate, CL_cmdrate, CL_Interp, CL_Interp_Ratio, CL_Updaterate
Seems like CS:GO is just as open to the rate exploitation as CS:S was.<!--QuoteEnd--></div><!--QuoteEEnd-->
The problem is, these commands also have a legitimate purpose. Changing those settings to match your internet connection really does improve the feel of the game.
today it is less important then it used to be because broadband is prevalent, so games rarely run into bandwidth problems.
If done correctly, the engine should be able to test the connection and set the numbers properly, or adjust them dynamically based on packet loss / choke / ping, but with any automatic system you have to develop it, and you have to make it fool proof. Imagine how mad you would get if the game decide you needed to reduce your rates and the game suddenly felt much less responsive?
I agree, an automatic solution is best if you can make it work, and it seems like that is what UWE is doing. I just wanted to point out it isn't as cut and dry as you might believe.
BTW, I don't think Comprox banned Underwelmed, it looks like that was just a warning. Also before Comprox made the edit to the post, there was a much more direct personal attack at the bottom. I feel like the troll is trolling pretty hard, but at the same time I agree that underwelmed made a pretty mean spirited attack.
<!--quoteo(post=1995970:date=Oct 24 2012, 01:45 AM:name=Pyromaniac)--><div class='quotetop'>QUOTE (Pyromaniac @ Oct 24 2012, 01:45 AM) <a href="index.php?act=findpost&pid=1995970"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Banning someone that has been an asset to the community for years (notice demo detective under his name indicating he was essential in spotting hackers) is more important than someone who <i>is</i> wrong being corrected in a blunt manner because they could possibly get their feelings hurt over an internet comment that was automatically censored. But similar comments, like the one in his signature, are allowed to slip by on a daily basis due to a community and moderation bias.<!--QuoteEnd--></div><!--QuoteEEnd-->
Show me where Underwhelmed got banned? All I can see is where Comprox edited his post to replace a personal attack with a <b>warning</b> that another similar attack would earn a ban.
<!--quoteo(post=1995970:date=Oct 24 2012, 08:45 AM:name=Pyromaniac)--><div class='quotetop'>QUOTE (Pyromaniac @ Oct 24 2012, 08:45 AM) <a href="index.php?act=findpost&pid=1995970"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->His post was interpreted as "I'm an angsty, arrogant competitive player," which goes against the first commandment of the uwe forums. In reality he called out either a troll or a fool who presented his post in a matter-of-fact manner and corrected him with useful information. Banning someone that has been an asset to the community for years (notice demo detective under his name indicating he was essential in spotting hackers) is more important than someone who <i>is</i> wrong being corrected in a blunt manner because they could possibly get their feelings hurt over an internet comment that was automatically censored. But similar comments, like the one in his signature, are allowed to slip by on a daily basis due to a community and moderation bias.
All of these can be a non-issue with proper coding, while still allowing people to tune their connection settings if they aren't optimal.<!--QuoteEnd--></div><!--QuoteEEnd-->
How you allowed yourself to use <i>is</i> in that manner and then condemn a supposed "matter-of-fact" attitude is amazing and brought me much joy. Thanks for brightening my day.
<!--quoteo(post=1995976:date=Oct 24 2012, 08:57 AM:name=Katana-)--><div class='quotetop'>QUOTE (Katana- @ Oct 24 2012, 08:57 AM) <a href="index.php?act=findpost&pid=1995976"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If done correctly, the engine should be able to test the connection and set the numbers properly, or adjust them dynamically based on packet loss / choke / ping, but with any automatic system you have to develop it, and you have to make it fool proof. Imagine how mad you would get if the game decide you needed to reduce your rates and the game suddenly felt much less responsive?<!--QuoteEnd--></div><!--QuoteEEnd-->
Imagine an online banking system lost all your money. Yes, these things <i>can </i>happen, but luckily computers are practically infallible, and mistakes which are devastating practically never happen, and mistakes which are annoying are usually easily reversible.
InsaneAnomalyJoin Date: 2002-05-13Member: 605Members, Super Administrators, Forum Admins, NS1 Playtester, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, NS2 Map Tester, Subnautica Developer, Pistachionauts, Future Perfect Developer
<!--quoteo(post=1995970:date=Oct 24 2012, 06:45 AM:name=Pyromaniac)--><div class='quotetop'>QUOTE (Pyromaniac @ Oct 24 2012, 06:45 AM) <a href="index.php?act=findpost&pid=1995970"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->His post was interpreted as "I'm an angsty, arrogant competitive player," which goes against the first commandment of the uwe forums. In reality he called out either a troll or a fool who presented his post in a matter-of-fact manner and corrected him with useful information. Banning someone that has been an asset to the community for years (notice demo detective under his name indicating he was essential in spotting hackers) is more important than someone who <i>is</i> wrong being corrected in a blunt manner because they could possibly get their feelings hurt over an internet comment that was automatically censored. But similar comments, like the one in his signature, are allowed to slip by on a daily basis due to a community and moderation bias.<!--QuoteEnd--></div><!--QuoteEEnd-->
The relevant portion of the post was <i>edited out</i>, which has been standard policy for a long time. We still have a record, however, and the response was totally justifiable. Please stop derailing this thread. If you have a problem with what happened, PM an admin.
Major engine architecture change a week before release is a audacious move indeed, I hope it doesn't cause hit-reg and similar problems. Some might remember it took mounts to debug the ones we had.
<!--quoteo(post=1996005:date=Oct 24 2012, 04:25 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Oct 24 2012, 04:25 AM) <a href="index.php?act=findpost&pid=1996005"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Major engine architecture change a week before release is a audacious move indeed, I hope it doesn't cause hit-reg and similar problems. Some might remember it took <b>mounts</b> to debug the ones we had.<!--QuoteEnd--></div><!--QuoteEEnd--> I don't remember the mounts. Looking forward to the patch.
I firmly deny all responsibility, and blame my orthographic corrector for this one; I just typed some letters that vaguely look like the word I wanted to type and took the first correction it gave me.
But seriously, yes, the concern is there that things will be severely glitchy and broken for a long time considering this kind of fundamental change. Not a good time to do this 1 week before release, but then again better late than never :-) .
Sherwood, I think you should remove that link you posted on interp because it is nonsense. You interp setting has nothing to do with what your ping is.
As for rate hacking, source servers had 2 commands for each rate setting, min and max that allowed them to control how low/high your settings were. It was never a big deal on properly configured servers. I don't really think having a rate command is really necessary these days though because almost everyone has fast enough internet to receive 30kb/s
Yeah, the only problem with the netcode in CS was two fold.
Being too low and thus players would rubberband like mad, or the biggest issue being interpolation.
I am not 100% on the technical side of interpolation, but it essentially moves the player model a metre or so infront of where the server is telling the client the player is.
If you think about the fact that when a player moves forward it takes time for the information to reach another client, so what you see is not technically where that player currently is on his PC. So to counter that, the client bumps the player model forward a few steps to allow for this.
This was particularly great for snipers if you turned it up. When you saw the player model and got in the reaction shot (say 0.3/0.4 seconds delay) the hitbox would have lined up perfectly with your crosshairs. Double doors on dust2 is a great example.
<!--quoteo(post=1996005:date=Oct 24 2012, 04:25 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Oct 24 2012, 04:25 AM) <a href="index.php?act=findpost&pid=1996005"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Major engine architecture change a week before release is a audacious move indeed, I hope it doesn't cause hit-reg and similar problems. Some might remember it took mounts to debug the ones we had.<!--QuoteEnd--></div><!--QuoteEEnd-->
Unless I've guessed wrong, it isn't a major engine architecture change. It's more of a tweak with a big payoff.
The player movement system can already handle any input rate, it's just that UWE can't control the input rate separate from the client's framerate. This change just means they can control it separately, and so they will cap it to save the game doing extra work for not much benefit. All the rest of the movement code should continue to work as it used to. (They might need some extra code in client prediction/interpolation)
The input rate limit will presumably go in a config var so it can easily be adjusted to get the best balance between performance and accuracy.
<!--quoteo(post=0:date=:name=Runteh)--><div class='quotetop'>QUOTE (Runteh)</div><div class='quotemain'><!--quotec-->I am not 100% on the technical side of interpolation, but it essentially moves the player model a metre or so infront of where the server is telling the client the player is.<!--QuoteEnd--></div><!--QuoteEEnd-->
You've got it backwards. Interpolation is not the amount your character is <b>ahead</b> of the server, it is the amount you see everything else in the world <b>behind</b> the most recent update from the server. The client needs to draw a slightly delayed version of the world so it can smoothly animate everything - it constantly animates the other objects in the world moving from where they were in the previous update, to where they are in the most recent update.
If it just rendered the most recent update as it received it you'd see the other players jump from place to place as each update arrived. This makes moving objects hard to track. Instead the client waits until it has at least two updates to smoothly animate between. That wait is the interpolation amount (usually 100ms for internet games, can go lower on a LAN).
When you fire a shot, the lag compensation code on the server knows you are seeing a delayed version of the world, and adjusts for it when it 'rewinds time' to see if your shot hit.
<!--quoteo(post=1995986:date=Oct 24 2012, 09:17 AM:name=Imbalanxd)--><div class='quotetop'>QUOTE (Imbalanxd @ Oct 24 2012, 09:17 AM) <a href="index.php?act=findpost&pid=1995986"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Imagine an online banking system lost all your money. Yes, these things <i>can </i>happen, but luckily computers are practically infallible, and mistakes which are devastating practically never happen, and mistakes which are annoying are usually easily reversible.<!--QuoteEnd--></div><!--QuoteEEnd--> Safety critical systems get a lot of money spent on mathematically proving correctness and other such overhead to become infallible (since the software is made by fallible humans)... but yeah I'd expect setting them automatically works better than not doing anything at all.
<!--quoteo(post=1996024:date=Oct 24 2012, 06:24 AM:name=Wilson)--><div class='quotetop'>QUOTE (Wilson @ Oct 24 2012, 06:24 AM) <a href="index.php?act=findpost&pid=1996024"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Sherwood, I think you should remove that link you posted on interp because it is nonsense. You interp setting has nothing to do with what your ping is.<!--QuoteEnd--></div><!--QuoteEEnd-->
irreguardless of whether he was right or wrong, I felt it was accurate to display the length of time people would put into these settings and most of the time would get them wrong lol.
So, based on the patch notes it suggests the input rate is only capped for move commands sent to the server. But that would contradict Flayras statement about improvement for high ping players. Is the client using the same timestep as the server, or still sampling input every frame?
Best option is probably for the client to use the server timestep except for the last frame or two of prediction (where it might not have a move command ready).
Not sure if this made it into the changelog properly, but Matso has been working very hard on multithreading client side prediction. This is what Charlie meant by improvements for high ping players. It decouples ping and server tick rate from client FPS and in general it should give a 25%-50% increase in FPS.
The network improvements are a separate thing which was needed because the higher player FPS meant the servers got swamped with updates from clients. Input is still sampled each frame but the moves are merged in a clever way on the client and sent to the server at a (variable) rate of ~30 per second.
<!--quoteo(post=1996689:date=Oct 25 2012, 01:42 AM:name=Agiel)--><div class='quotetop'>QUOTE (Agiel @ Oct 25 2012, 01:42 AM) <a href="index.php?act=findpost&pid=1996689"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Not sure if this made it into the changelog properly, but Matso has been working very hard on multithreading client side prediction. This is what Charlie meant by improvements for high ping players. It decouples ping and server tick rate from client FPS and in general it should give a 25%-50% increase in FPS.
The network improvements are a separate thing which was needed because the higher player FPS meant the servers got swamped with updates from clients. Input is still sampled each frame but the moves are merged in a clever way on the client and sent to the server at a (variable) rate of ~30 per second.<!--QuoteEnd--></div><!--QuoteEEnd-->
So the client incrementally 'builds' a move from input sampled every frame. When enough time has passed (depending on the input rate), this is sent to the server, but in the meantime it has something to use during the prediction phase so there is no delay in applying input to your predicted position. That should still provide a client speedup on it's own as the prediction phase can use the longer server timestep for all predicted frames for which it has already built move commands.
Still wrapping my head around multithreaded prediction. More details would be great.
<!--quoteo(post=1996139:date=Oct 24 2012, 04:05 PM:name=shader)--><div class='quotetop'>QUOTE (shader @ Oct 24 2012, 04:05 PM) <a href="index.php?act=findpost&pid=1996139"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You've got it backwards. Interpolation is not the amount your character is <b>ahead</b> of the server, it is the amount you see everything else in the world <b>behind</b> the most recent update from the server. The client needs to draw a slightly delayed version of the world so it can smoothly animate everything - it constantly animates the other objects in the world moving from where they were in the previous update, to where they are in the most recent update.
If it just rendered the most recent update as it received it you'd see the other players jump from place to place as each update arrived. This makes moving objects hard to track. Instead the client waits until it has at least two updates to smoothly animate between. That wait is the interpolation amount (usually 100ms for internet games, can go lower on a LAN).
When you fire a shot, the lag compensation code on the server knows you are seeing a delayed version of the world, and adjusts for it when it 'rewinds time' to see if your shot hit.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well I did say I wasn't 100% :P But close enough for a gamer! Heh.
Comments
Anyway, these are very complex changes to be making a week before release and shows how dedicated UWE are to giving us the best user experience possible, exciting times!<!--QuoteEnd--></div><!--QuoteEEnd-->
*tune to I'm Still Standing*
As for the topic in CS:S If i remember correctly even server admins were not all that knowledgeable about it. I remember people getting banned over having there personal settings not as the admins wanted them to be.
There were people who felt that being able to manipulate your personal Cmdrate and Tickrate was a violation of fair gaming tactics. Or rather more aptly put the Baseline that all players starting out have the same tools/chances as the next person with exception to the speed of there personal rig/distance to the server. I can't reliably remember if any of it was confirmed 100% but essentially people were complaining about the following.
#1 purposefully lowering the settings to essentially create lag involving there character to obtain easier kills.
#2 having a higher rate then other members of the server who were unaware that it could be changed, therefore creating a skill gap that shouldn't exist.
#3 Foolish manipulation of these settings by users who really had no idea what they were for/did and caused issues in games.
Ended up forcing a config /check to ensure settings were in line with the servers if i do recall. If you didn't allow the config check the server wouldn't let you in. This also ended up in admins exploiting the feature by essentially erasing all data in the config file like key binds. This would force the user to delete the config file and re-download from steam forcing the person to re-setup there configurations, key binds, ect lol. I remember one event specifically where the admins would bind all keys but backwards for any person joining to type kill in the console.
I will tell you what though from a person who used to play CS:S all the time Cmdrate, and tickrate/servmaxtickrate can definatly make a huge difference on gameplay outcomes especially when everyone on the server has different values. I can't remember the name of it but there was one other console command cs:s had that was always messed with i think it was bandwidth allowed or something like that.
One thing I would like to add to my ramblings is that when CS:S did force all clients to adhere to the same cdmrate/tickrate as the server I noticed that the gameplay became much more even. There were far fewer players that would just dominate every round, and it almost seemed for a time that it worked. Servers became less laggy, and the tick rate of a server meant the tick-rate of all it's inhabitants as well.
I think the rate hacking from NS1 showed us that giving players the ability to customize the way they send and receive data is not a good idea. Furthermore it provides absolutely no necessary utility.
Interp I had forgotten about though I can't remember exactly what it modified.
Google search came up with a Guy going in to detailed explanation.
<a href="http://www.freefrag.com/team-fortress-2/9950-cl_interp-you.html" target="_blank">http://www.freefrag.com/team-fortress-2/99...interp-you.html</a>
Interp I had forgotten about though I can't remember exactly what it modified.<!--QuoteEnd--></div><!--QuoteEEnd-->
Even better, you set it really low, because in practice it is horribly biased towards the upload rather than the download. I don't know if it was the same everywhere, but during NS1's heydays, where I'm from, internet bandwidth was massively divided. We had about 30% of players on 56k, 60% on ISDN 64-128k, and the rest on ADSL lines ranging from 1 meg to 10 meg. This meant that simply capping the rates off wasn't really an option. Thus you got people who had 10 meg connections, warranting rates of 20k + who would instead use values around 3000-4000. What they saw from their side was close to unchanged, but what other people saw... my god... it was an abomination. The truly fast players would teleport so much that you would have about 3 discrete positions to shoot at every 20 or so meters.
Let the core system parameterize itself automatically. Let the user change what kind of anti aliasing they like to see.
Ironically while I was doing a search for the old command I ran across some forums for the new game CS:GO and there were a large number of people discussing the same commands CL_rate, CL_cmdrate, CL_Interp, CL_Interp_Ratio, CL_Updaterate
Seems like CS:GO is just as open to the rate exploitation as CS:S was.
I don't know if people might be like why is this guy bringing up CS over and over, well NS1 was based on the HL engine as a mod and so was CS they were both birthed from the same game so to speak. They also contained many of the original console commands from HL, and it is a very potent correlation to compare how they were abused(in NS1 and CS/CS:S) to this game NS2. But that is where the similarities stop NS2 having a completely knew engine and all =), with as some have pointed out new ways of computing that information.
For the many of you that were already aware of this and are like Duh... please disregard lol.
His post was interpreted as "I'm an angsty, arrogant competitive player," which goes against the first commandment of the uwe forums. In reality he called out either a troll or a fool who presented his post in a matter-of-fact manner and corrected him with useful information. Banning someone that has been an asset to the community for years (notice demo detective under his name indicating he was essential in spotting hackers) is more important than someone who <i>is</i> wrong being corrected in a blunt manner because they could possibly get their feelings hurt over an internet comment that was automatically censored. But similar comments, like the one in his signature, are allowed to slip by on a daily basis due to a community and moderation bias.
<!--quoteo(post=1995946:date=Oct 24 2012, 01:12 AM:name=Sherwood)--><div class='quotetop'>QUOTE (Sherwood @ Oct 24 2012, 01:12 AM) <a href="index.php?act=findpost&pid=1995946"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->#1 purposefully lowering the settings to essentially create lag involving there character to obtain easier kills.
#2 having a higher rate then other members of the server who were unaware that it could be changed, therefore creating a skill gap that shouldn't exist.
#3 Foolish manipulation of these settings by users who really had no idea what they were for/did and caused issues in games.<!--QuoteEnd--></div><!--QuoteEEnd-->
All of these can be a non-issue with proper coding, while still allowing people to tune their connection settings if they aren't optimal.
Seems like CS:GO is just as open to the rate exploitation as CS:S was.<!--QuoteEnd--></div><!--QuoteEEnd-->
The problem is, these commands also have a legitimate purpose. Changing those settings to match your internet connection really does improve the feel of the game.
today it is less important then it used to be because broadband is prevalent, so games rarely run into bandwidth problems.
If done correctly, the engine should be able to test the connection and set the numbers properly, or adjust them dynamically based on packet loss / choke / ping, but with any automatic system you have to develop it, and you have to make it fool proof. Imagine how mad you would get if the game decide you needed to reduce your rates and the game suddenly felt much less responsive?
I agree, an automatic solution is best if you can make it work, and it seems like that is what UWE is doing. I just wanted to point out it isn't as cut and dry as you might believe.
BTW, I don't think Comprox banned Underwelmed, it looks like that was just a warning. Also before Comprox made the edit to the post, there was a much more direct personal attack at the bottom. I feel like the troll is trolling pretty hard, but at the same time I agree that underwelmed made a pretty mean spirited attack.
Show me where Underwhelmed got banned? All I can see is where Comprox edited his post to replace a personal attack with a <b>warning</b> that another similar attack would earn a ban.
All of these can be a non-issue with proper coding, while still allowing people to tune their connection settings if they aren't optimal.<!--QuoteEnd--></div><!--QuoteEEnd-->
How you allowed yourself to use <i>is</i> in that manner and then condemn a supposed "matter-of-fact" attitude is amazing and brought me much joy. Thanks for brightening my day.
Imagine an online banking system lost all your money. Yes, these things <i>can </i>happen, but luckily computers are practically infallible, and mistakes which are devastating practically never happen, and mistakes which are annoying are usually easily reversible.
The relevant portion of the post was <i>edited out</i>, which has been standard policy for a long time. We still have a record, however, and the response was totally justifiable. Please stop derailing this thread. If you have a problem with what happened, PM an admin.
I don't remember the mounts. Looking forward to the patch.
How about marines though?
So by Mounts I was meaning years of course.
But seriously, yes, the concern is there that things will be severely glitchy and broken for a long time considering this kind of fundamental change. Not a good time to do this 1 week before release, but then again better late than never :-) .
As for rate hacking, source servers had 2 commands for each rate setting, min and max that allowed them to control how low/high your settings were. It was never a big deal on properly configured servers. I don't really think having a rate command is really necessary these days though because almost everyone has fast enough internet to receive 30kb/s
Being too low and thus players would rubberband like mad, or the biggest issue being interpolation.
I am not 100% on the technical side of interpolation, but it essentially moves the player model a metre or so infront of where the server is telling the client the player is.
If you think about the fact that when a player moves forward it takes time for the information to reach another client, so what you see is not technically where that player currently is on his PC. So to counter that, the client bumps the player model forward a few steps to allow for this.
This was particularly great for snipers if you turned it up. When you saw the player model and got in the reaction shot (say 0.3/0.4 seconds delay) the hitbox would have lined up perfectly with your crosshairs. Double doors on dust2 is a great example.
Unless I've guessed wrong, it isn't a major engine architecture change. It's more of a tweak with a big payoff.
The player movement system can already handle any input rate, it's just that UWE can't control the input rate separate from the client's framerate. This change just means they can control it separately, and so they will cap it to save the game doing extra work for not much benefit. All the rest of the movement code should continue to work as it used to. (They might need some extra code in client prediction/interpolation)
The input rate limit will presumably go in a config var so it can easily be adjusted to get the best balance between performance and accuracy.
<!--quoteo(post=0:date=:name=Runteh)--><div class='quotetop'>QUOTE (Runteh)</div><div class='quotemain'><!--quotec-->I am not 100% on the technical side of interpolation, but it essentially moves the player model a metre or so infront of where the server is telling the client the player is.<!--QuoteEnd--></div><!--QuoteEEnd-->
You've got it backwards. Interpolation is not the amount your character is <b>ahead</b> of the server, it is the amount you see everything else in the world <b>behind</b> the most recent update from the server. The client needs to draw a slightly delayed version of the world so it can smoothly animate everything - it constantly animates the other objects in the world moving from where they were in the previous update, to where they are in the most recent update.
If it just rendered the most recent update as it received it you'd see the other players jump from place to place as each update arrived. This makes moving objects hard to track. Instead the client waits until it has at least two updates to smoothly animate between. That wait is the interpolation amount (usually 100ms for internet games, can go lower on a LAN).
When you fire a shot, the lag compensation code on the server knows you are seeing a delayed version of the world, and adjusts for it when it 'rewinds time' to see if your shot hit.
Safety critical systems get a lot of money spent on mathematically proving correctness and other such overhead to become infallible (since the software is made by fallible humans)... but yeah I'd expect setting them automatically works better than not doing anything at all.
irreguardless of whether he was right or wrong, I felt it was accurate to display the length of time people would put into these settings and most of the time would get them wrong lol.
<a href="https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking" target="_blank">https://developer.valvesoftware.com/wiki/So...ayer_Networking</a>
<a href="https://developer.valvesoftware.com/wiki/TF2_Network_Graph" target="_blank">https://developer.valvesoftware.com/wiki/TF2_Network_Graph</a>
Best option is probably for the client to use the server timestep except for the last frame or two of prediction (where it might not have a move command ready).
The network improvements are a separate thing which was needed because the higher player FPS meant the servers got swamped with updates from clients. Input is still sampled each frame but the moves are merged in a clever way on the client and sent to the server at a (variable) rate of ~30 per second.
The network improvements are a separate thing which was needed because the higher player FPS meant the servers got swamped with updates from clients. Input is still sampled each frame but the moves are merged in a clever way on the client and sent to the server at a (variable) rate of ~30 per second.<!--QuoteEnd--></div><!--QuoteEEnd-->
So the client incrementally 'builds' a move from input sampled every frame. When enough time has passed (depending on the input rate), this is sent to the server, but in the meantime it has something to use during the prediction phase so there is no delay in applying input to your predicted position. That should still provide a client speedup on it's own as the prediction phase can use the longer server timestep for all predicted frames for which it has already built move commands.
Still wrapping my head around multithreaded prediction. More details would be great.
If it just rendered the most recent update as it received it you'd see the other players jump from place to place as each update arrived. This makes moving objects hard to track. Instead the client waits until it has at least two updates to smoothly animate between. That wait is the interpolation amount (usually 100ms for internet games, can go lower on a LAN).
When you fire a shot, the lag compensation code on the server knows you are seeing a delayed version of the world, and adjusts for it when it 'rewinds time' to see if your shot hit.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well I did say I wasn't 100% :P But close enough for a gamer! Heh.