Depends when in February it's happening maybe cu@

where were u at riptide bro me and fleskore were looking for ur ass

https://www.youtube.com/watch?v=XEzRXkwHsyQ

pretty sure RGL LAN was supposed to be at this exact venue, and it's in a fairly good location for tf2 as well considering the dense population of players around the NJ area

No problem man, if you ever wanna discuss it more I'm down, netcode is a really interesting topic to think about for me. Glad you learned some things from all the talk

Rollback netcode at its root is a delay based netcode system though, only due to the ability to rollback dropped packets they can set a low fixed delay instead of requiring a variable delay in order to ensure the inputs go through properly. By using inactionable frames, rollback can seamlessly interpolate the old game state with the actual game state.

The interp can only account for so much when the person is still 100ms behind everyone else, unless you also want to force everyone else to play at a noticeably higher input delay. The larger the difference between the interp and the ping, the more rollbacks will occur. Rollback's largest benefit is that it helps deal with packet loss, not general large ping differences like you first mentioned. Sure your inputs feel like offline, but that doesn't mean the person with 150 ping still isn't laggy as fuck and teleporting fairly often. In Melee, which probably has the most similar pace to TF2, 150 ping 3 frame is barely playable against any mobile character as they start micro teleporting every other movement and you have to try and pin them down.

Since all hit detection occurs server-side, if a client predicts the movement of someone else incorrectly, than they'll simply be shooting at ghosts. Alternatively if you were to change lag compensation to reflect compensating for false predictions, you would have people getting hit for moving in a way they never did. In the first scenario, a scout will be shooting at the ghost of a soldier who's already rocket jumped, and then have to react to them teleporting and adjust to hit them as they fly towards them much closer. In the latter scenario, a scout will win a 1v1 solely because the other scout dropped a packet and started running in a straight line.

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.

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.

Rollback only works in a Peer to Peer system because the whole nature of it is that it allows users to input their inputs without having to worry about delay, making execution much more consistent. The main benefit of the system for fighting games is that it lets your execution be uninterrupted, as dropping a combo holds much more substantial weight than missing a shot 99% of the time. But since general execution is much more often prioritized in fighting games and the fact that a majority of the time you aren't actually inputting any specific inputs, rollback works perfectly for fighting games. In Source games, you aren't required to hit sometimes frame-perfect inputs constantly to execute what you want to like in fighting games.

In fighting game rollback, they don't necessarily "predict" anything, they simply continue to hold down the previous input. This works out in a lot of fighting games due to the amount of time where you're not actually able to act (blockstun/hitstun when hitting or blocking moves, jump start up frames, etc.). Without a machine learning system it's pretty much impossible to genuinely predict any future inputs. In an FPS game its much more detrimental to have that happen since you never really have "dead time" where you can't input anything.

As for predicting projectiles, it can't simply predict spawning a projectile because it would mean predicting a spawn on every missing packet, and then retroactively correcting that input, despawning the rocket and undoing any damage that might have happened, on every client connected to the server. The amount of load that would bring on the server, let alone the individual clients constantly correcting itself would become way too much to handle for 12 different players. Damage calculation is just rerunning some cached numbers, whereas projectiles require physics calculations and actual entity spawning, etc.

Yea it pretty much comes down to youtube nuking the bitrate on anything 1080p60 and lower, remember dealing with this kind of thing on some melee videos i worked on before.

If you just upscale to 1440p60 and upload it'll already look better, on top of all the things Adnurak mentioned. Youtube's compression is super intensive, raw 1080p footage looks similar in quality (usually better) compared to 4k footage uploaded and watched on youtube due to compression, and it gets even worse if the video is uploaded at 1080p. This is the reason a lot of youtubers will say to watch the videos in 4k even on 1080p monitors n such

trust me man i play with a keyboard literally anything is viable as a controller as long as u can map all the keys to it

Paging PA gamers

Starting comp sci at University of Pittsburgh this August

it's just gonna get nuked by nintendo again lol

Every other Round Robin-esque ranking system/bracket in games has always used W/L over both H2H and Points/Game % in almost every example you could possibly bring up, I don't know why points being the main decider was ever considered a good idea to begin with.

https://www.youtube.com/watch?v=wGW8GIrfj7A friend of mine, kind of sick at the game