Account Details
SteamID64 76561197981944988
SteamID3 [U:1:21679260]
SteamID32 STEAM_0:0:10839630
Country Tonga
Signed Up April 19, 2014
Last Posted March 17, 2021 at 8:34 PM
Posts 1373 (0.5 per day)
Game Settings
In-game Sensitivity
Windows Sensitivity
Raw Input  
Refresh Rate
75 Hz
Hardware Peripherals
Mouse Razer Copperhead
Keyboard Packard Bell wireless AA powered
Mousepad ikea gaming desk
Monitor Packard Bell 17" CRT
1 2 3 4 ⋅⋅ 92
#20 talking about pl_badwater in Videos

the deep good part of youtube

posted 4 weeks ago
#14 POLL: which tftv subforums do you actively browse? in Off Topic

i dont browse any but just look at recent activity

posted 1 month ago
#18 ETF2L Season 38 and Preseason Cup announced in News
dbkcoyo_geezerwhy is iron bomber not banned ?please dont make demo worse than he already is in teamfights

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

posted 1 month ago
#14 no pistol spread in Projects

give this to pyro or heavy instead

posted 1 month ago
#11 when are yall making a new league in TF2 General Discussion

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

posted 1 month ago
#34 What happened to the old STAR_? in Videos
BeaterIt really is interesting how the amount of effort that you put into a video has almost no bearing on whether or not it will be successful. There's a reason why there are so many garbage channels out there that just follow the same tired, low effort formula that they know work (reaction channels are obvious examples of this). Clearly that isn't the route Ster wants to take his channel since making good content is more important to him than success. Good for him I say!

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.

posted 2 months ago
#27 Übersaw is overrated trash imo in TF2 General Discussion

TIL vitasaw isn't banned

posted 2 months ago
#15 how do i get rid of this shit in Q/A Help

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

posted 3 months ago
#25 pogchamp is dead in World Events
dbku didnt do any research at all did you lmao

edit: wait u didnt even read the original post about it getting removed, they fucking spell it out for you

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

posted 3 months ago
#22 pogchamp is dead in World Events
twitchWe've made the decision to remove the PogChamp emote following statements from the face of the emote encouraging further violence after what took place in the Capitol today.

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

posted 3 months ago
#311 TF2 Players that went on to greater adventures. in TF2 General Discussion
Maxi-Nesh (old prem german sniper main signed for Navi's Apex team

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

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

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

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

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?

posted 3 months ago
#161 What mouse do you use? in Hardware
Phoenix21Twiggything 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 ofthese features are a part of the sensor spec, lower spec than hero sensor might have smoothing, very high lod or just spin out so you you are right with not going for anything cheaper.

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.

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

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

frutloopsAs 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,

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.

SetsulI'd guess they don't want to deal with the mess that that creates. Firstly allowing the client to predict a projectile that may or may not ever be created in case the player dies before it actually happens but doesn't know it yet (the joys of latency) means they have to clean up "dead" projectiles. Projectiles seeming to spawn and then being deleted is also going to create a lot more salt than projectiles always spawning late if your ping is shit.

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.

SetsulSecondly if the time of creation is based on what the shooter sees then everyone else is only going to see them after they have already traveled for ping from shooter to server + processing time + ping from server to everyone else. In other words: teleporting projectiles. Would you rather have someone with 900 ping have a suboptimal experience or have the projectiles he shoots suddenly appear in someone's ass without any chance of dodging?

Yes, this would be a problem.
In this GGPO article 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 :

valve wikiBy default, the client receives about 20 snapshot per second. If the objects (entities) in the world were only rendered at the positions received by the server, moving objects and animation would look choppy and jittery. Dropped packets would also cause noticeable glitches. The trick to solve this problem is to go back in time for rendering, so positions and animations can be continuously interpolated between two recently received snapshots. With 20 snapshots per second, a new update arrives about every 50 milliseconds. If the client render time is shifted back by 50 milliseconds, entities can be always interpolated between the last received snapshot and the snapshot before that.

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

setsulLast but not least there is no agreement as such, it is simply expected that everyone will arrive at the same state with the same inputs. That requires that no one deviates accidentally (no RNG allowed) or maliciously (cheating). No idea how they deal with packet loss. Allowing resynchronization by simply sending your own state/position sounds very exploitable.

Quoting this article :

articleYou can send multiple frames worth of input data for each frame, so that when one frame gets lost you don’t need to wait for a full resend cycle to complete in order to continue with the game. Input data’s pretty cheap so it doesn’t cost much to include 5-10 frames worth of data in a packet, so might as well include it. This is something that you should pretty much always do.

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

posted 3 months ago
1 2 3 4 ⋅⋅ 92