Re: [hlds_linux] Re: Re: Request a higher minimum value for cl_cmdrate.
the 100ms delay doesn't mean that latencies higher than 100ms are hopeless. Don't know how you gleaned that from it. The only time that would hold true is if the server operator had sv_maxunlag set to 0.1, but 1.0 is the default. Players with a lower ping/latency still have an advantage in some respects, but this 'unlag' feature takes a good bite out of that latency sandwich for you. On Thu, 14 Jul 2005 23:55:48, Dan Sorenson [EMAIL PROTECTED] wrote: Heck, I'm suprised I came so close on some of these assumptions I made, and thanks for the pointer. I was basing most of my logic on the old classic engine, and it's been about 4 years since I've investigated its behavior. However, I don't see where gaming the prediction and interpolation by cutting client-sent updates wouldn't throw off the results. Whether the engine would react by going more or less in favor of one client in this case is not mentioned, nor would I expect fine details of the server's logic. What has me more curious is where it states the Source engine does entity interpolation with a 100ms delay. I don't think I can get to my upstream tier 2 provider in under 100ms, let alone to a server, so right away interpolation is suspect. That explains a lot of the oddities I see in-game, actually. It's not the overall rate that's a problem -- I rarely see more than 64Kbit/s inbound from most servers, it's the latency. I'll have to experiment some, as we've a number of international players on our servers with pings in the 120-200ms range trying to take on 30ms players. Improving things such that interpolation remains accurate would be a good thing for them. -- Clayton Macleod ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Re: Re: Request a higher minimum value for cl_cmdrate.
What has me more curious is where it states the Source engine does entity interpolation with a 100ms delay. To quote: The Source engine does the entity interpolation with a 100-millisecond delay (cl_interp 0.1) Therefore the 100ms delay is adjustable client side. Dropping cl_interp to 0. 02 will reduce the delay to 20ms. Forcing an automatic system based on rates I just can't see being effective. What we are realistically saying here is take thousands of connection types, speeds and latencies and have the server automatically control their update rates. All that will be achieved would be no connection being tweakable and no advantage seen on faster connections, all sounds nice yes, but... You will have millions of players blaming Valve for enforcing their rates, everything from bad reg to lag will be blamed on this and uproar would definately occur. I pay a lot of money for my fast internet connections, the day game writers start to control my effective reaction times in games to accomodate dial-up users will be the day I quit and I suspect a lot more feel the same way. Control of client side rates must be maintained by the client, no other way would be widely accepted by the community. All that needs adding is the ability for server admins to enforce min and max cmdrate's. The truth of it is although we want to level the playing field and provide fairness between all connection speeds, doing so would annoy the masses, who are on broadband connections. You only have to look at how many ping restricted servers are around to see this. So, ultimately, it's not practical to accomodate dial-up users on a level playing field against broadband connections without hampering to a degree the broadband user, due to just numbers of players alone with each connection type this is not practical. Give the server admins this control, they can then create fair servers for different connection classes and communities themselves. All in all a much more effective solution which also offloads this responsibility from Valve to server admins. Just my 2 cents. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Re: Re: Request a higher minimum value for cl_cmdrate.
In reply to that Valve Developer link posted early in this thread: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking I found the information an incredible read from a players point of view. Is there a similar page somewhere for CS 1.6? I'm curious is 1.6 works the same way as far as the client updaterate/cmdrate and the server ticrate. I've always been at odds about what actually happens when setting such variables... On Thu, 14 Jul 2005 23:55:48, Dan Sorenson [EMAIL PROTECTED] wrote: At 01:00 AM 7/14/2005 -0700, you wrote: Dan look over this http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking Then give a rethink of some of what you said Heck, I'm suprised I came so close on some of these assumptions I made, and thanks for the pointer. I was basing most of my logic on the old classic engine, and it's been about 4 years since I've investigated its behavior. However, I don't see where gaming the prediction and interpolation by cutting client-sent updates wouldn't throw off the results. Whether the engine would react by going more or less in favor of one client in this case is not mentioned, nor would I expect fine details of the server's logic. What has me more curious is where it states the Source engine does entity interpolation with a 100ms delay. I don't think I can get to my upstream tier 2 provider in under 100ms, let alone to a server, so right away interpolation is suspect. That explains a lot of the oddities I see in-game, actually. It's not the overall rate that's a problem -- I rarely see more than 64Kbit/s inbound from most servers, it's the latency. I'll have to experiment some, as we've a number of international players on our servers with pings in the 120-200ms range trying to take on 30ms players. Improving things such that interpolation remains accurate would be a good thing for them. - Dan * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] * * Vikings? There ain't no vikings here. Just us honest farmers. * * The town was burning, the villagers were dead. They didn't need * * those sheep anyway. That's our story and we're sticking to it. * ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Re: Re: Request a higher minimum value for cl_cmdrate.
The closest thing I have seen for a CS 1.6 client is this http://home.covad.net/~k25125/SteamyThings/NetGraph_Steam.htm I hope that helps :) - Original Message - From: Philip Koshy [EMAIL PROTECTED] To: hlds_linux@list.valvesoftware.com Sent: Friday, July 15, 2005 3:56 AM Subject: Re: [hlds_linux] Re: Re: Request a higher minimum value for cl_cmdrate. In reply to that Valve Developer link posted early in this thread: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking I found the information an incredible read from a players point of view. Is there a similar page somewhere for CS 1.6? I'm curious is 1.6 works the same way as far as the client updaterate/cmdrate and the server ticrate. I've always been at odds about what actually happens when setting such variables... On Thu, 14 Jul 2005 23:55:48, Dan Sorenson [EMAIL PROTECTED] wrote: At 01:00 AM 7/14/2005 -0700, you wrote: Dan look over this http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking Then give a rethink of some of what you said Heck, I'm suprised I came so close on some of these assumptions I made, and thanks for the pointer. I was basing most of my logic on the old classic engine, and it's been about 4 years since I've investigated its behavior. However, I don't see where gaming the prediction and interpolation by cutting client-sent updates wouldn't throw off the results. Whether the engine would react by going more or less in favor of one client in this case is not mentioned, nor would I expect fine details of the server's logic. What has me more curious is where it states the Source engine does entity interpolation with a 100ms delay. I don't think I can get to my upstream tier 2 provider in under 100ms, let alone to a server, so right away interpolation is suspect. That explains a lot of the oddities I see in-game, actually. It's not the overall rate that's a problem -- I rarely see more than 64Kbit/s inbound from most servers, it's the latency. I'll have to experiment some, as we've a number of international players on our servers with pings in the 120-200ms range trying to take on 30ms players. Improving things such that interpolation remains accurate would be a good thing for them. - Dan * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] * * Vikings? There ain't no vikings here. Just us honest farmers. * * The town was burning, the villagers were dead. They didn't need * * those sheep anyway. That's our story and we're sticking to it. * ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] Re: Re: Request a higher minimum value for cl_cmdrate.
At 01:00 AM 7/14/2005 -0700, you wrote: Dan look over this http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking Then give a rethink of some of what you said Heck, I'm suprised I came so close on some of these assumptions I made, and thanks for the pointer. I was basing most of my logic on the old classic engine, and it's been about 4 years since I've investigated its behavior. However, I don't see where gaming the prediction and interpolation by cutting client-sent updates wouldn't throw off the results. Whether the engine would react by going more or less in favor of one client in this case is not mentioned, nor would I expect fine details of the server's logic. What has me more curious is where it states the Source engine does entity interpolation with a 100ms delay. I don't think I can get to my upstream tier 2 provider in under 100ms, let alone to a server, so right away interpolation is suspect. That explains a lot of the oddities I see in-game, actually. It's not the overall rate that's a problem -- I rarely see more than 64Kbit/s inbound from most servers, it's the latency. I'll have to experiment some, as we've a number of international players on our servers with pings in the 120-200ms range trying to take on 30ms players. Improving things such that interpolation remains accurate would be a good thing for them. - Dan * Dan Sorenson DoD #1066 A.H.M.C. #35 [EMAIL PROTECTED] * * Vikings? There ain't no vikings here. Just us honest farmers. * * The town was burning, the villagers were dead. They didn't need * * those sheep anyway. That's our story and we're sticking to it. * ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
