Valve integrating parts of Z-Block?

[Hollanda]

Quote:TheUnknownfactor, co-author of Z-Block, a cvar blocker for the Source engine had an interesting discussion with Valve's main developer Alfred Reynolds about the new restrictions from server to client:

I've recently had some contact with VALVe in regards to zBlock and cl_restrict_server_command, I haven't gotten any concrete "we'll remove it or default it to 0", however I did get an "we plan to add some of zBlocks functions into SrcDS.

I'll start quoting emails where it becomes relavant, so I'm skipping a bunch of other stuff.

“Can you give me any details on what a "rate hack" is exactly? Are users changing there cl_cmdrate on the fly and causing bad server behavior? We want to protect servers from this problem directly in the engine.
- Alfred”

My response:

“I'll probally respond in an email a little longer then what you were hoping for and/or expecting, however, I believe it will be worth your time. To build up some credibillity, in case I still don't have this yet(if I do, feel free to skip to the next paragraph); I'm author of several netcode related articles and was in fact the person who notified VALVe regarding the problem where cl_interpolate did not have the userinfo flag. If you search the steam forums for the query "netcode +'the final quirks'" you should find my most recent article (admittedly already getting outdated, however the bugs described in it still exist in the netcode).

On the subject of "rate hacking"; this is an often misused term, a lot of people simply call players with low rate settings "rate hackers", even for rates as low as game defaults.
While I support the thought that default rates are far lower then what they currently should be (in part, because of the migration from 33Tick servers to 66Tick servers that has been underway the past ~year), people should not be considered rate hackers unless they're clearly trying to exploit the netcode (IMO).

What I mean by this is, setting cl_cmdbackup to values above 10 (which is quite obviously entirely unneeded, and while it should be innocent, it realistically causes worse hit registration), or more frequently creating a significant difference between the rate at which they request information and submit information. Rates such as, cl_updaterate 100; cl_cmdrate 10 are generally what we're looking at when speaking about the 'real' "rate hackers" (which is a terrible term if you ask me).
Both of these are commonly used methods to become more difficult to hit.

What's more IMO; is that the default rates should not be at 20/30, barely anyone is still limited to a net connection this poor, and 50/50 or above already brings a significant improvement in the situation.

I hope you can do something with this information; my suggestions would be;
-> Create a range on cl_cmdbackup of a minimum 0, and maximum 10.
-> Either combine update and cmdrate, or link their values together.
-> Increase the default values of rate settings.

Additionally, I still want to know if VALVe has any intrest in resolving the cl_restrict_server_command issue.

On this subject I suggest:
-> Default to 0
-> Create a server variable "sv_require_client_command&quo t;, which will bring up a "yes or no" field when a player tries to connect that has the client variable for it on 0.
-> Remove entirely
-> Intergrate zBlock like functionality into SrcDS”

To which I received the following response:

“Thanks for the detailed reply on rate issues you see. We are going to work on removing cl_cmdbackup (it does not need to be configurable) to prevent that issue. We are also going to enable servers to define limits for cmdrate so ops can choose the window of values allowed for users playing. We will look at updaterate vs. cmd rate, I am not sure that they should be uncoupled as they currently are. We are also working on restricting that list of cvars you sent me in the zBlock source (thanks for that!), if you find other cvars that should not be used on multiplayer servers please email the details to me.

- Alfred”

Which is most definitely excellent news, the exact problem for which I emailed doesn't appear to have much of any changes coming up to look forwards to, however these are definitely some of the problems that have plagued this game for far too long.

After which I emailed:

“Thank you for the response, that sounds like something great to look forward to; I hope you don't mind I'v taken the liberty to post snippets of these emails.

I definitely appreciate the positive response thus far, however still feel the need to ask if there's any discussion / thoughts being thrown around in regards to possible changes to cl_restrict_server_commands into a more "zblock friendly" solution.”

To which I received the following response:

“We are also investigating a cvar interogation interface so server side plugins can enforce configuration limits on connecting players (you will not be able to change user configs without user interaction however).

- Alfred”

Just to set a few few things straight, the method zBlock used to enforce a level playing field was never by any means "ideal", we however chose to accept a few "rough edges" as a sacrafice towards an improved playing field. What VALVe is looking into is one that goes into the game much more seemlessly, and will more then likely be extremely difficult to bypass when released.

Thanks for this interesting information TheUnknownFactor at Z-Block.

Bron: http://www.tcmagazine.com/comments.php?shownews=12979&catid=12

[Drocona]

hmm I'm not a zBlock fan, but if they implement the settings into the srcds it would be way better.