Ex_interp Locked To 0.1, Bug Or "feature"?
matchbox
Join Date: 2003-10-31 Member: 22179Banned
Join Date: 2003-10-31 Member: 22179Banned
ex_interp is to be set as the reciprocal of your cl_updaterate, playing with an ex_interp of 0.1 would require the player to use an updaterate of 10 to keep the smoothest gameplay. This is not the case with the majority of players, especially at the competitive level where updaterates of 50 to 100 are the most common. This difference in updaterate and interp creates the effect of lagged hitboxes and jittery players that can be felt quite often.
More info at : <a href='https://webspace.utexas.edu/jmm258/netcode.doc' target='_blank'>https://webspace.utexas.edu/jmm258/netcode.doc</a>
Not really sure flayra locked this in the first place, prephaps he was misinformed on the subject, as ex_interp is no "exploit" as many would have it.
More info at : <a href='https://webspace.utexas.edu/jmm258/netcode.doc' target='_blank'>https://webspace.utexas.edu/jmm258/netcode.doc</a>
Not really sure flayra locked this in the first place, prephaps he was misinformed on the subject, as ex_interp is no "exploit" as many would have it.
This discussion has been closed.
Comments
ex_interp should be set to 0 at all times, so that it automatically calculates what your interp should be.
It used to be an exploit at anything other than 0.1
It used to be an exploit at anything other than 0.1 <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Depends on what you consider exploit <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
I'm just wondering if CD still does cvar blocking for it, I remember it use to, it's just it might cause a problem even if it was unblocked you wouldnt be able to use it with CD in CAL.
Actually, steam locks the interp to a range of 0.1 to 0.05.
Had ex_interp set at 0.1 and updaterate 60 and i was fricking wondering if i really got THAT bad as skulk :> Now i changed interp to 0 and updaterate to 101 and steam sets interp for me, which works awesome now <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html//emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif' /><!--endemo-->)
Thanks again.
Actually, steam locks the interp to a range of 0.1 to 0.05. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Actually, no it doesn't... (anymore <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->)
Is this really accurate? Ok, so we know interp 0 -> interp = 1/updaterate.
BUT the key thing here is, does it set interp based on your client updaterate, or what the server is currently forcing it to? In other words, if you have cl_updaterate 100 and interp 0, is your actual interp always .01, or is it calculated each time you go to a different server for that server's max updaterate, a la "steam sets interp for me"??
Is this really accurate? Ok, so we know interp 0 -> interp = 1/updaterate.
BUT the key thing here is, does it set interp based on your client updaterate, or what the server is currently forcing it to? In other words, if you have cl_updaterate 100 and interp 0, is your actual interp always .01, or is it calculated each time you go to a different server for that server's max updaterate, a la "steam sets interp for me"?? <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
it "forces" it to 9 msecs
the question is, does it stay at the level steam put it, or does it actually change back, because ex_interp tells me 0.1 after a few seconds =D
Actually, steam locks the interp to a range of 0.1 to 0.05. <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
Afaik its not steam but a serverside setting that determines the cap - I'm not sure though. Might have been an outdated source. Generally command and updaterates could use some mod-specific limitations though to prevent minor exploits, like inducing choke for a warping effect - and forcing interp to your 1/updaterate would then also be practicly feasible.
<!--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--> Doesnt ex_interp set how far the hitbox should lag behind the playermodel? AFAIK VALVe locked it to 0.1 in version 1.6 of cs on ALL half-life modes (via the engine, that is) since it was considered an exploit in the cs-community since it made a BIG difference (esp. on the headshot factor) if the hitbox lagged behind a little more. If the hitbox lags just a bit more its a lot easier to headshot, and therefore they locked it to 0.1<!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
No, interp was never about getting headshots. You used to set crazy low interp values to screw your side of the connection and let your own hitbox sit in never-never land while you ran right into the opposition and opened up. To be quite honest, how the funcionality of ex_interp and the effect super-low settings had was supposed to make any sense is still a mystery to me though.
Anyway, what interp currently does is define the amount of rendered frames based on network input, and not clientside estimation. That means, at ex_interp 0.1, 10 frames per second are "real" - everything in between (at an FPS of 100, 90 frames) is estimation. Meaning in a cycle of 100 MS, you'd currently be seeing 9 estimated frames and 1 based on what the server is sending you. This is done to present movement as visually smooth - but obviously, to prevent extreme exploits (like you said, it would be silly if you could determine the hit-area based on what your client sees), the server uses a history backlog and checks if there was a player in your line of fire the time you pulled the trigger. So it does indeed leave room for error - especially with fast-moving targets like Celerity Skulks, where one update per 100ms is fairly slow.
K, so much for my laymans understanding of things. In short, changing that setting cannot confer you any unfair advantage right now - it being locked is definitely not the source of all current hitbox issues, but can be part of whats causing some minor discrepancies.
Edit : Missing the word "rendered" where it was important <!--emo&;)--><img src='http://www.unknownworlds.com/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo-->
Finally, thought I was the only one! Just yesterday I went on the LoC server around 1:00 pm when no one was on. I connected my other computer and decided to test out some issues. I found that 1 of 10 bites DID NOT REGISTER and this was on a target standing still!! Also I found that biting from up top (on the head hitbox) is often not counted too! These experiments were done on a stationary non-upgraded marine. Cleary there is a severe problem with bites NOT registering and is considerably annoying when suddenly marines appear to have armour 3 in the first 2 minutes of a game :S
P.S. my updaterate was 50 and cmdrate was 45; rate was 12000.
<!--QuoteBegin-matchbox+Jun 6 2004, 03:30 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (matchbox @ Jun 6 2004, 03:30 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Anyway, what interp currently does is define the amount of rendered frames based on network input, and not clientside estimation. That means, at ex_interp 0.1, 10 frames per second are "real" - everything in between (at an FPS of 100, 90 frames) is estimation. Meaning in a cycle of 100 MS, you'd currently be seeing 9 estimated frames and 1 based on what the server is sending you. This is done to present movement as visually smooth - but obviously, to prevent extreme exploits (like you said, it would be silly if you could determine the hit-area based on what your client sees), the server uses a history backlog and checks if there was a player in your line of fire the time you pulled the trigger. So it does indeed leave room for error - especially with fast-moving targets like Celerity Skulks, where one update per 100ms is fairly slow.
K, so much for my laymans understanding of things. In short, changing that setting cannot confer you any unfair advantage right now - it being locked is definitely not the source of all current hitbox issues, but can be part of whats causing some minor discrepancies.
Edit : Missing the word "rendered" where it was important <!--emo&;)--><img src='http://www.natural-selection.org/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--> <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
You can change your ex_interp but it only stays that way for approx 5 sec then returns to the 0.1
OK i did some testing today, when you bring up ex_interp to lets say .8 it says it limits you to 100ms. The results where terrible I didnt hit one marine while leap biting.
Then I went down to 0 then it says its limits you to 9ms and leap biting couldnt have been easier. It seemed to register bites like as soon as you hit the button, It also seemed to remove the "I shot and died imediately and my shot didnt register"
I have a demo of this, but i dont have a place to host it. This is highly reproducable!
<!--QuoteBegin-matchbox+Jun 6 2004, 03:30 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td><b>QUOTE</b> (matchbox @ Jun 6 2004, 03:30 PM)</td></tr><tr><td id='QUOTE'><!--QuoteEBegin-->Anyway, what interp currently does is define the amount of rendered frames based on network input, and not clientside estimation. That means, at ex_interp 0.1, 10 frames per second are "real" - everything in between (at an FPS of 100, 90 frames) is estimation. Meaning in a cycle of 100 MS, you'd currently be seeing 9 estimated frames and 1 based on what the server is sending you. This is done to present movement as visually smooth - but obviously, to prevent extreme exploits (like you said, it would be silly if you could determine the hit-area based on what your client sees), the server uses a history backlog and checks if there was a player in your line of fire the time you pulled the trigger. So it does indeed leave room for error - especially with fast-moving targets like Celerity Skulks, where one update per 100ms is fairly slow.
K, so much for my laymans understanding of things. In short, changing that setting cannot confer you any unfair advantage right now - it being locked is definitely not the source of all current hitbox issues, but can be part of whats causing some minor discrepancies.
Edit : Missing the word "rendered" where it was important <!--emo&;)--><img src='http://www.natural-selection.org/forums/html//emoticons/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--> <!--QuoteEnd--></td></tr></table><div class='postcolor'><!--QuoteEEnd-->
You can change your ex_interp but it only stays that way for approx 5 sec then returns to the 0.1
OK i did some testing today, when you bring up ex_interp to lets say .8 it says it limits you to 100ms. The results where terrible I didnt hit one marine while leap biting.
Then I went down to 0 then it says its limits you to 9ms and leap biting couldnt have been easier. It seemed to register bites like as soon as you hit the button, It also seemed to remove the "I shot and died imediately and my shot didnt register"
I have a demo of this, but i dont have a place to host it. This is highly reproducable! <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Yup, thats why I bound ex_interp 0 to all my "movement" keys + jump =)
After reading an entry at the private part of the bug database, there was some discussion of locking ex_interp to 0.1, but it's unclear if the change was actually made. If we do lock the variable in the future, it'll be locked at 0. If it's already locked at 0.1, I'll change it to be locked at 0.
If all this is true it would explain alot. I can't wait to run some test myself.
tried that, doesn't work, it changes back instantly... but if i type it in to console it takes a few seconds to change back to 0.1 o_O
From what people are saying, it looks like ex_interp was locked. That probably should be fixed.
This could explain a LOT!
After reading an entry at the private part of the bug database, there was some discussion of locking ex_interp to 0.1, but it's unclear if the change was actually made. If we do lock the variable in the future, it'll be locked at 0. If it's already locked at 0.1, I'll change it to be locked at 0. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Very good to read, makes me happy.
Also is there a temp fix?
no
After reading an entry at the private part of the bug database, there was some discussion of locking ex_interp to 0.1, but it's unclear if the change was actually made. If we do lock the variable in the future, it'll be locked at 0. If it's already locked at 0.1, I'll change it to be locked at 0. <!--QuoteEnd--> </td></tr></table><div class='postcolor'> <!--QuoteEEnd-->
Wonderfull, I'm going to guess that the next build will have this change?