frootloopsI think you're fundamentally missing where the prediction happens.
For me, source prediction happens on the client, based on what was last given by the server.
frootloopsFor 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.
Nah, the server doesnt care about this stuff. it computes a game state however it likes, then sends that game state to every client. What counts is that what is displayed on each client is as smooth and reactive as possible.
Therefore here I am not discussing "shifting away game state calculations to clients", I agree that it's not feasible and pointless.
frootloops 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.
Thats the point of having everyone use the same interp value : everyone would see the prjojectile appear at the same place. The lower the interp, the farther from the shooter the projectile will appear.
Hence, with everyone at high interp and playing in the past, the downside of the projectile spawning farther away could be mitigated, as everyone would be rendering frames related to the same tick and have an array of more recent ticks received stored waiting for eventual rollbacks. So if that array is big enough compared to the connection quality of the worst player, all the netcode shenanigans are resolved before anyone renders the tick, and every client renders the same thing.
With all that you said I still dont see how this wouldnt work.
frootloopsThe 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.
I am not talking about any delay-based netcode such as what is done in fighting games not using rollback, because that's out for FPS for reasons stated in the valve documentation.
SetsulIf the client can only see the entities the server already knows about it can't "predict spawn" its own projectiles either.
Why not? I believe most of the time when a client requests to spawn an projectile it is allowed to do so. If the client dies after predict spawning a projectile but before the projectile existence is confirmed by the server, then only that dead client will see some kind of visual artifact. And that client's dead anyway, no big deal.
SetsulThey don't add a delay. They do teleporting/warping by simply jumping to the actual position and because the only thing that will be skipped with decent ping are the startup frames they call it good enough.
Note that this is a horrible idea in any game with hitscan weapons.
I thought I've heard the KI dev talk about it but here is smth else instead :
https://arstechnica.com/gaming/2019/10/explaining-how-fighting-games-use-delay-based-and-rollback-netcode/
articleTurns out, we can eliminate this by combining delay-based and rollback solutions. In fact, every modern fighting game that uses rollback is built on a delay-based framework, with the important caveat that the delay is fixed at the start and never changes. If you pick a suitably small delay and keep it fixed, it should give enough time for “many" of your opponent’s inputs to reach you without needing to trigger a rollback on every state change. If there are network spikes, rather than increasing input delay or pausing and waiting, instead rollback takes over for any input that takes longer than the chosen delay. As long as the delay is small and consistent, players will quickly adapt, and many will not even notice a difference from offline play.
What number to set this delay at is up to the discretion of the developer. Some games, like 3rd Strike Online Edition, Darkstalkers Resurrection, Skullgirls and Samurai Shodown V Special, allow the user to set their own delay, usually between zero and eight frames. Other games, like Killer Instinct and Injustice 2, universally choose the number for all players (three frames, in the case of these games) and provide no option to change it.
Could you elaborate on why this is a bad idea for hitscan things?
SetsulEither projectiles spawn instantly locally and teleport for everyone else (GGPO, if prediction fails) or they appear everywhere at the same time at their actual spawn point which means they guy who pressed the button has to wait until everyone knows about the projectiles before they get to see their own projectile (source). You can't have both at the same time.
Sure, my question now is, if it's the first case, can you mitigate how much the projectiles teleport by increasing what i believe is named interp, which is delay between what state is computed by server and what state is rendered by clients?