TwiggyIsn't it what "client side prediction" is?
TwiggyWhat I meant by predicting projectiles would be to do exactly what is done with client side prediction, i.e. let the player do his inputs first and (maybe) roll them back later.
Because this could let a player perform a rocket jump and feel the blast effect immediately instead of having it delayed by whatever lag there is.
I am not talking about predicting that an opponent is going to spawn a projectile at your face.
I think you're fundamentally missing where the prediction happens. The prediction that happens in peer-to-peer rollback is for missing inputs of OTHER players based on the last received input. With two clients, Client A and B, if Client B drops packets it was supposed to send to Client A, rollback netcode takes the last known inputs of Client B that it receives, and Client A then predicts missing data based on that. For rollback to work on a source server setup, the server would have to do that same "prediction" (which would most likely just be a movement direction), and then send that prediction to every client except for the one dropping packets. So the other 11 players would receive predictions from the server and display that, and then once the new inputs are received, they would be retroactively synchronized into the game state.
Shifting game state calculations away from the server and onto each individual client is also a theoretical way of implementing that, but when managing a 1 on 1 peer to peer synchronization is already hard enough, you would essentially leave the server with the task of managing a 12 or 18 person way essentially peer to peer connection where if one person's game state is slightly different from the rest the server has to send them corrected data from every other client, which just generates WAY more input delay due to the increased amount of traffic that would be involved.
TwiggyThe way I understand that, all clients are more or less in the past depending on their interp value. So if everyone agrees to be a fixed amount of time in the past, and that amount is great enough to mitigate teleporting projectiles issues, this problem should not arise most of the time
The 50ms mentioned in the documentation is separate from the ping you have to the server as well afaik, as the server has to receive an initial input (lets say at an example 40ms ping), allow the 50ms buffer to receive the next snapshot, and then start allowing clients to render afterwards. Fighting games don't have this extra rendering delay due to being locked at 60fps, and they simply send an input for each frame.
For source/general fps games, the equivalent of fighting games' 2-3 frame delay is like everyone playing at a set buffer based on say 50 ping. If you set everyone to 50 ping buffer on a server, it doesn't magically make the person at 150 ping send his inputs any faster, and that person will still have to send their inputs and data 100ms later. In a fighting game, you can cover up that extra delay by interpolating the new animations through the startup frames that are involved in pretty much every action you do. However in any FPS game, you very rarely have any example of startup, outside of something like switching weapons where you are inactionable. When you click, your gun shoots immediately, there's no room to interpolate the old action with the new. Rollback means you would have projectiles be spawning halfway through their travel time on people's screens, or have people suddenly teleport halfway into their rocket jump, which already does happen.
The only surefire way to avoid having something like this happen, would be to have the input delay be equal to that of the highest ping player on the server ALONGSIDE a rendering buffer of the same length, and if everyone else in the server has 40-60 while one person has 150+ ping, it makes absolutely 0 sense to punish everybody else.