Anti-Cheat proposal

[joevano]

Personally, I would see that as a natural progression to a fully authoritative server. Once the simulation can report on those kinds of issues; and statistics are gathered as to the accuracy, the model can be tweaked. Then a fully authoritative server would be the next step, or so it would seem to me.

[Mucho Maas]

Well, take for example the speed detection. There are server configurations that check if the client tank's maximum speed is not violated. And it is not that seldom that client's get kicked from a server, because the server has identified a false positive.
Another thing is the discrepancy between package frequency (not sure how to call it) and the client's frame rate.
And moving certain physics validation to the server also doesn't address prevention of the more subtle cheats (those cheats that do not modify a tanks physics). Personally I am more concerned about the latter.

[JeffM]

Foo
that is because the server does not have an accurate state. That is the problem we are trying to fix.

The current speed checks are bad, you are correct. But that is not because ALL speed checks are bad, but because the current checks simply don't have the required data.

The current tasks for all of this is to get a server side state and THEN LOOK at how it compares to the client state. At that point we can run comparisons and see how many falses we'd get, positive or negative.

It would only be after that research is done that we'd decide how much of the server info would be used and to do what. No one has ever said that we'd just blindly move "collisions" over to the server and let the game suffer.

You are making a great number of poor assumptions and extrapolating them to the entire development process.

[Mucho Maas]

It would only be after that research is done that we'd decide how much of the server info would be used and to do what. No one has ever said that we'd just blindly move "collisions" over to the server and let the game suffer.

Blindly is a big word. I also wasn't intending to take as a final state comments that have been produced so far regarding moving collision detection to the server. I am sure it will include lag unrolling etc etc. and a million of other specifics I haven't regarded yet.
Just from an architectural point of view I was assuming (and only assuming) there will be "differences" in how the game will feel like.
True is however as you noted, that discussing these "differences" only makes sense for the non-involved, like I am, after research has been done and publicized/alpha tested.

If I made the impression that I think things are done "blindly", I apologize. That was not my intention, and it is also not how I think the developer team is doing it.

You are making a great number of poor assumptions and extrapolating them to the entire development process.

I am sorry if it came over as a critic on the developer team. It was not supposed to be one. I am already thankful for all they have done so far.

What is true however is, that I still think that an authoritative server will not deal with cheats of the more subtle kind. But you have addressed this already in another post and stated your priorities, which are, IMHO very acceptable.

[FiringSquad]

With an authoritative server, there will certainly be instances of "Hey! I dodged that", but that's fine.
It will be the same for everybody so it will be fair.
At the moment some cheating is hidden behind apparent lag/jit. With an authoritative server it will be in the interest of people to improve their connection and it's only fair that the better the connection then the better the advantage.
Besides, I suspect that it will be possible to anticipate which dodges will not be recognised by the server and modify your skills accordingly.

As for my suggestion about a method for the client to self-validate, in a way that would be extremely difficult to circumvent...
Well, I was a little frustrated when I wrote it and upon mature reflection I would not like it to be introduced into BZFlag (even if it was allowed).
It's never a good idea for an application to make such specific assumptions about the underlying ABI and it could cause consequences for developers that they could not possibly be expected to foresee. For example, if a developer moved a routine further up the source file to allow it to be shared, it could drastically alter the binary code produced. Config files that worked fine beforehand would no longer be valid just because a minor bug was fixed and the code recompiled.
No. It would be nice to be able to get the client to prove itself to be official, but the cost in complexity of the finished design and distribution would be too high a price to pay.

[Skeeve]

While chatting #bzflag I had an idea of how to take out the fun in cheating. It's not elaborated and you might say it's a stupid idea or object for other reason.

If I understand it correct, each client sends his shot information to the server. The server then forwards it to all connected clients.

So how about a server option to suppress all shots send by a cheating client except to the client himself (maybe) so that the cheater doesn't notice at once, that he is ignored? That way he will still drive around but won't be able to kill anyone. Until he notices, he might have already wasted a lot of time.

The cheat detection could be similar to a poll, but right now polls are often ignored by others because they either don't notice or don't care. Or a poll is not possible because not enough players are around.

The new command /cheater CALLSIGN could be counted by the server and if more than half of the players (except for the cheater, entered it, it is assumed to be true.

Yes! Not very elaborated I admit the second time. But maybe a starting idea?

[JeffM]

if you can detect it, then just ban the guy.

anything else is just petty revenge.