spamming heavy-sized hitboxes across a control point counts as teamfight?
weapon perk is already the much more useful rollers

give this to pyro or heavy instead

i remember the last attempt by tftv circle to create a league it ended well

i think it hits harder when one starts out of passion, and then makes it a job. for a while you enjoy both the passion and the success it receives from the public. But then it diverges.
For such people it's harder to make content that works if the passion isn't there, and as soon as what you are passionate about is rejected, you are hit personnally.
Whereas "garbage channels" may consist of people who never viewed making videos as a passion project, but solely as a way of making money.
Ultimately those who stick to what they are passionate will see personal growth and deal better with negative feedback as they age.

TIL vitasaw isn't banned

firefox does not leak anymore but it will use just as much ram as chrome does =)

calm down i'm not a native speaker;
i did not think "the face of the emote" referred to the actual person, rather that somehow the image of this guy was a symbol of violence. It makes more sense now, thanks to the much more helpful post by det-. Way to go, det-.

So something is used as a rallying image, therefore it is censored? are all the pepega emotes related to 4chan haters also censored?

I don't get how it solves the idea at the cause of that (mis)use of the emote

uh nice, I think I played a season with him back in the days

Okay. I can't say I'm out of the fog but I learned things thanks to you, so cheers =)

For me, source prediction happens on the client, based on what was last given by the server.

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.

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.

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.

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.

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/

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

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?

Okay. All i'm saying is that I would be fine with an older spec optical sensor. "Innovation" and new products in this market seem very artificial to me.

Isn't it what "client side prediction" is?

What 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 did not understand that part. If we agree that a client cant "predict spawn" projectiles of opponents, how is that an issue? A client would still see on its display whatever entities the server tells him exist.

Yes, this would be a problem.
In this GGPO article https://drive.google.com/file/d/1cV0fY8e_SC1hIFF5E1rT8XRVRzPjU8W9/view the dev explains that in practice it can hide the move starting late during the startup frames. We don't have that in shooters.

However, just as GGPO adds a fixed number of frame delay to mitigate for this, I believe what is rendered on client side in source is "the past", for the server :

The 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.
I believe this is why interp is 100ms by default as well, if only jumping wasnt so sluggish, and everyone was forced to the same value, there would be no downsides to keeping it

Quoting this article :
http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking.html

-> looks like a client must keep some history of past input data sent, to be able to give it to another client that lost a packet.

Not quite, verlet swing looks like it's only swinging whereas cyber hook is mostly pulling, plus shenanigans like wall running and double jump

thing is, even those cheap mice have those useless features like 8000 dpi where everyone uses 1600 at most and rgb, but there is nothing below g203 that I could buy without those features that i'm aware of