Account Details
SteamID64 76561198090484580
SteamID3 [U:1:130218852]
SteamID32 STEAM_0:0:65109426
Country United States
Signed Up December 23, 2017
Last Posted January 2, 2021 at 3:38 AM
Posts 71 (0.1 per day)
Game Settings
In-game Sensitivity
Windows Sensitivity
Raw Input  
Refresh Rate
Hardware Peripherals
1 2 3 4 5
#13 [netcode]Source vs GGPO style rollback in TF2 General Discussion

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

posted 3 months ago
#11 [netcode]Source vs GGPO style rollback in TF2 General Discussion
TwiggyI 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.

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.

TwiggyThats 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.

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.

TwiggyCould you elaborate on why this is a bad idea for hitscan things?

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.

posted 3 months ago
#7 [netcode]Source vs GGPO style rollback in TF2 General Discussion
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.

posted 3 months ago
#4 [netcode]Source vs GGPO style rollback in TF2 General Discussion

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.

TwiggySo for some reason it's not allowed to predict spawning a projectile. I don't get why, especially since the lag compensation system on the server is already able to go back in time to figure out when a command happened

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.

posted 3 months ago
#7 Help with video quality settings in Q/A Help

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

posted 6 months ago
#8 Melee Rollback Netcode in Other Games
Don't worry! Universal Controller Fix has been baked into the new Slippi launcher so you don't even need to worry about getting a super good controller, I play on a smash ultimate one I got brand new on release and with UCF I can hit all my shield drops and execute techskill.

do you think the Switch Pro Controller would function with UCF + this online netcode (I have a Pro controller already)? Can you play Melee through your PC via an emulator in the year 2020? I'm sure there's a whole lot of compatability shit the community has come up with but I don't pay super close attention to the scene

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

posted 9 months ago
#56 tf2 teams with players from the same state as you. in Off Topic

Paging PA gamers

posted 10 months ago
#100 CoLLeGe in Off Topic

Starting comp sci at University of Pittsburgh this August

posted 11 months ago
#3 Project +, a Project M mod in Other Games

it's just gonna get nuked by nintendo again lol

posted about a year ago
#15 RGL Points System in TF2 General Discussion

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.

posted about a year ago
#8 opinions on goldeneye N64 in Other Games friend of mine, kind of sick at the game

posted about a year ago
#8 The mcats Fragshow - Ep. 1 in Videos

Feel like some small velocity tweaks and introducing fast motion cuts instead of consistent fades will make this look even better, rly clean still and the cc looks great

posted about a year ago
#22 RGB LAN 5 + TooManyGames in LAN Discussion

cu@ LFT on projectile

posted about a year ago
#6 TF2 DOF in Videos

Reshade is probably your best bet for a really clean DOF implementation for a video

posted about a year ago
#4 EVO 2019 in e-Sports

Ultimate Top 256 upset thread, just look at this list man evo is nuts:

For DBFZ, that was such a heart stopping winner's finals/grand final's it's unreal, GO1 finally getting that evo win is nuts.
I also can't get over this damn clip:

posted about a year ago
1 2 3 4 5