Prediction is only possible for the local player and entities affected only by him, since prediction works by using the client's keypresses to make a "best guess" of where the player will end up. Predicting other players would require literally predicting the future with no data, since there's no way to instantaneously get keypresses from them.

This is from valve's article:

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

When another player presses W move forward, say 100 velocity in the forward direction is added to his character.That gets sent to the server, and applied locally on his machine.

If I know that from the server, why couldn't I just simulate the next frames, based on knowing that he had 100 forward velocity a while ago?

Yes, I'm aware that if there is a lot of latency, this sort of prediction will make everything look choppy, since the server will keep overriding the local prediction of a client, but still, claiming its impossible to predict other players positions seems a bit harsh.

I just perform physics-based dead reckoning, but with players it's different because a player could have released a movement key or started holding down a different one, which should cause a different outcome in their movement. I don't include the time a keypress started or ended in an update, so the accuracy is limited by the resolution of the updates, but it's sufficient for the purposes of my game at 15hz (67 msec).

In my game the local player's input is applied to their entity by the same code that applies the last-known input for all other players to their own entities as received from the server (along with their positions/velocities). The reason for this is because I just use the physics simulation to predict everything, and if the next update received has a new position for an entity that is different than what the physics has simulated locally then the client just interpolates across the error until the next update is expected to arrive.

Velocities are snapped to whatever is received from the server, but the difference between current position and received position is added to the entity's position along with its velocity over the period that elapses between updates being received, unless the difference is a few meters, then it just snaps the position as well. This means that clients are always simulating one update behind the server. EDIT: This is because one update arrives and it takes until the next one arrives before everything has interpolated to the corrected position, at which point the new update arrives and the whole system has to play 'catch-up' again... over and over...

This, ontop of a buffering delay that is used to smooth out network update jitter (updates arriving at irregular intervals), and the latency between client/server leaves clients with a minimum of 50+ msec delay between what's happening on the server and what they're actually seeing.

What that article is talking about is the fact that you can't just magically know which direction a player has chosen to move, or jump, or crouch, etc.. and you just have to wait until that information arrives because players are unpredictable. The best you can do is know what keys they were last holding, and generate the player movement for that particular input state, and hope for the best.

Prediction is only possible for the local player and entities affected only by him, since prediction works by using the client's keypresses to make a "best guess" of where the player will end up. Predicting other players would require literally predicting the future with no data, since there's no way to instantaneously get keypresses from them.

This is from valve's article:

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

When another player presses W move forward, say 100 velocity in the forward direction is added to his character.That gets sent to the server, and applied locally on his machine.

If I know that from the server, why couldn't I just simulate the next frames, based on knowing that he had 100 forward velocity a while ago?

Yes, I'm aware that if there is a lot of latency, this sort of prediction will make everything look choppy, since the server will keep overriding the local prediction of a client, but still, claiming its impossible to predict other players positions seems a bit harsh.

I don't see why you can't perdict the movement, It won't be accurate but it depends on your movement system.

If it can rotate itself 180* in just a flip then yeah, it would be hard to perdict it.

If the movement is somehow restricted to any rules, then I'd say it's a bit easier to perdict the movement by comparing the current state to these rules.

I'd say you have to compromise here, do you really need accurate perdictions? Or simple perdictions are enough for your behavior.

Based on statistics you collect and real time data, you could actually perdict the next movement.

If it can rotate itself 180* in just a flip then yeah, it would be hard to perdict it.

In a first-person-shooter game, players are not limited to facing one direction, nor are they limited to moving in that one direction they are facing. How do you suppose we should predict what forward/left/right/back/jump/crouch buttons they are pressing before they are pressing them, and then showing that result to all other players before the player in question has even pressed them?

If it can rotate itself 180* in just a flip then yeah, it would be hard to perdict it.

In a first-person-shooter game, players are not limited to facing one direction, nor are they limited to moving in that one direction they are facing. How do you suppose we should predict what forward/left/right/back/jump/crouch buttons they are pressing before they are pressing them, and then showing that result to all other players before the player in question has even pressed them?

As I said "It would be hard to perdict it".

Using statistics about a player you could actually perdict what he's going to do, and collecting these statistics and analyzing them, is not a hard process as it seems.

For example I know I have regular patterns that I use in fps games.

If the system can detect these patterns, it could actually perdict my next move.

The technology and algorithems already exist for this kind of system, the cost of having one is the other thing you should consider.

Have at it, develop the system. You'll be the first person in the world to do it. I think that alone makes it a worthwhile goal.