First of all, thanks a lot to everybody who has commented in this thread. Of course, I cannot incorporate all the comments (I do need to keep the book at certain level of general approaches, omitting singular solutions which are difficult to generalize). Also, the point of this chapter is indeed not to claim that this is an exhaustive list, but to say that well, before trying to go beyond these things listed, one needs to understand them very well (and now I've added a sentence to this effect).
That being said, I've learned quite a few things from your comments, and added quite a few things (more on it below), thanks a lot!
As for didntwant's criticisms, an advanced reader might get less frustrated it the wording is slightly edited to make it more clear that you're building up a picture by laying out broad strokes first, which contain issues, and then addressing those issues later. The bits that he's misquoted for example could be more clear that these problems lie with the simplistic algorithms introduced so far, and the solutions lie further ahead in the text.
TBH, I've already tried to do it before (Fig VII.1 and Fig VII.2 had notices that they're not optimal, from the very beginning), but given the feedback you're right - it wasn't enough. I've added more disclaimers to this effect, THANK YOU!
Two cars being piloted, and colliding, would both seem to be reacting correctly, but in different time frames on different player machines, and would, post-collision, end up in the same locations. This was because each player informed the server and other players of client-side detected collisions -- but those collisions would, on the other player's machines, only affect that player's object. Meanwhile, if the server detected a collision but the client hadn't requested it, the client got corrected, so you couldn't cheat (much) by disabling the "send a collision event" code.
As I read it, it can be seen as a variation of Client-Side Prediction (with both clients predicting their own collisions and reconciling with the server later). Do you agree with such interpretation or am I missing something?
use the archers model to help mask communication times. They can enqueue and broadcast the command while showing a 45+ms trigger pulling animation. They can communicate to the player that bullets take time to fly through the air by showing a tracer line for another 3 or more frames and a small puff of smoke, buying another 45ms-60ms. The local animations give the player a feeling of immediate responsiveness but also allow some time for machines to communicate
Good one, I didn't think about it in these terms, and is sufficiently generic too. THANK YOU, I've added a mini-section on it ("Taking a Bit Back").
I'd advise against the (naive) assumption that server authority is a binary switch.
One simple illustration of it is that even Lag Compensation takes a bit of server authority away, with the associated cheating. OTOH, I'd argue that client-side-simulations-which-dont-affect-gameplay (which - depending on gameplay - MAY include such things as particle effects, exact positions of limbs in a ragdoll simulation, exact trajectories of the cars after collision as long as they end up in the same places, etc. etc.) are not really passing authority from the server (that is, as long as they have no "game changer" effects on the world); this is a terminology issue, but on intuitive level I feel it easier to separate these two things (first one, client affecting gameplay, which does pass some authority to the client, and second one, purely visual client-side effects). And if we accept such interpretation, I'd try to argue that most of the serious MMO games out there are "mostly authoritative server" ones :-).
