Account Details
SteamID64 76561198042353207
SteamID3 [U:1:82087479]
SteamID32 STEAM_0:1:41043739
Country Germany
Signed Up December 16, 2012
Last Posted January 13, 2021 at 10:49 AM
Posts 3162 (1.1 per day)
Game Settings
In-game Sensitivity
Windows Sensitivity
Raw Input  
Refresh Rate
Hardware Peripherals
1 2 3 4 ⋅⋅ 211
#3786 PC Build Thread in Hardware

Like I said 4.7 is the stock boost clock so your current cooler should be able to handle that, probably slightly more.
There's always delidding...

The MSI Z370 A-PRO is as bad as it gets for Z370, so any Z370/Z390 you can get will be at least as good. It might even be worth to use the "new" used mobo for the 9900KF instead. Yes, if you can find an Intel fanboy who is upgrading to a 10900K and selling a 9900K(F) that wasn't overclocked insanely high + mobo it might be an even better deal.
Remember that a 9900K(F) is simply the best you can get that would fit your mobo, but a 9700K or 9600K would still be an upgrade by 100/50% in multithreaded.
For SSDs or other guides.
You should be able to find entry level 500GB NVMe SSDs around 50-60€ and mainstream starting at around 65€.
For the 8350K any 120mm or more single tower cooler should be more than enough.

10700K vs 5600X is a slight tradeoff on multithreaded vs singlethreaded. There's only so much 6 cores can do if that program doesn't show vastly better SMT scaling on AMD.
Z490 mobos are slightly more expensive and don't have PCIe 4.0 though.
10700K is basically a 9900K, very similar power draw, 5600X would be less.

EDIT: Just so we're clear: I didn't forget about mobo recommendations, I just didn't feel like doing a whole bunch of them for different levels of overclocks, depending on how much are willing or able to afford depending on how much you're spending on the SSD and RAM and other stuff for the second pc and doing it twice for both 10700K and 5600X.
You're smart and motivated enough to make a decision on those on your own, which will give me a much clearer budget and narrower restrictions to work with, drastically reducing the time and effort needed.
me lazy

posted 1 week ago
#3784 PC Build Thread in Hardware

It's a 450W PSU and it isn't trash so you can actually draw 450W. There's no need for a 100W buffer. It's supposed to be within spec at 100% load and will be completely fine with spikes to 110% since spikes from the sustained load are expected. Non-oc with a FE 1070 you'd be at <350W under full load, "normal" aftermarket 1070 (~180W) + lightly oc'd 9900K would be around 400W for the whole system. Even with some spikes that's well within the PSU's capabilities.

You'd need RAM for the secondary PC or buy new one for your primary, obviously.
10700K would be within budget, but it would be very weird since the ridiculous prices for Z490 mobos mean a 9900KF (same speed) + a cheap quad core including mobo might actually be cheaper, let alone just a cheap-ish used mobo for the 8350K.
5800X is expensive enough that I don't think a cooler and mobo good enough for a decent overclock would leave enough for an SSD without maxing out the budget completely.
5600X would be a tradeoff, slightly slower in multithreaded than a 9900K, but faster singlethreaded, though obviously more expensive since you need a new mobo and cooler.
3700X would be definitely weird, if you can even find one for a reasonable price. Multithreaded about the same as the 5600X, maybe slightly better, but at best the same singlethreaded as the 8350K you already got.

posted 1 week ago
#3782 PC Build Thread in Hardware

5.0 single core boost, 4.7 all core seems good enough to me. The cooler is good enough that it shouldn't overheat on stock clocks (especially if you undervolt it a bit) and I doubt the VRMs will burst into flames at stock either. Wouldn't expect much of an OC, but it's faster than what you've currently got at stock speeds so I don't see that being an issue.
You don't have to go all out and get a 9900K(F) either, that's just the fastest (and most expensive) CPU you can get without replacing the mobo.

Depends on the 1070. Reference design/FE is 150W, aftermarket goes up to 250W in theory, but most are 180W, with peaks to 190-200W.
Yes, overclocked you can push the 9900K to 250W on a dedicated CPU stresstest like Prime95 and that's awfully tight with your PSU (though barely doable), but actual, real-world all core loads at stock? 120-150W, plenty of headroom there. Light OC like permanent 4.7 all core instead of only boost for x seconds is fine.

posted 1 week ago
#3780 PC Build Thread in Hardware

If you're running out of RAM you need more, otherwise it's fine.
PSU should still be fine.
Same with the GPU.

Unless you need more than 8 cores/16 threads keeping everything and only getting a new CPU would be the cheapest. Even a new 9900KF is cheaper than a 10700KF/3700X/5800X + mobo.

A new SSD should be easily within budget, so why not?

posted 2 weeks ago
#9 Bad routing to chicago servers + somewhat high ms in Hardware

It's a bit late but I have to correct Pete's explanation:
Routing is not to blame here, Comcast is.

There is a fairly direct, nice and fast fiber connection Seattle-Denver-Dallas. I think Level 3 (now owned by CenturyLink) owns that. And that is the problem. You see, usually an ISP would send any traffic that goes outside their local network to an interregional/international carrier with all those nice, fast fiber routes and they'd pay them for it so they can maintain and expand that network and everyone is happy. Except Comcast doesn't want to do that. Comcast wants the tier 1 carriers to pay them for the privilege of getting access to Comcast customers. It makes no sense, wouldn't be a sustainable business and is generally going nowhere. So while Comcast can bully local ISPs into those deals and sometimes even companies that depend on their traffic getting to Comcast customers with decent bandwidth (like Netflix) the tier 1 carriers won't ever agree to a deal that will only ever cost them money. The reason why Comcast can get away with that is that they've got local networks everywhere and simply connected them to pretend that they can do everything a tier 1 carrier can do. The quality of that substitution is what you can see.

Basically this:
Has been going on for years.

Good connection exists, Comcast wants to get paid for using it instead of paying.

Comcast bad.

posted 2 weeks ago
#3778 PC Build Thread in Hardware

Depends on your definition of 10/10 and whether it's exclusively for TF2, but it should be less than 1600$.

Unless manage to find a GPU older than 10 years, not really. 1660S is very much overkill.

posted 3 weeks ago
#10 Is kaidus the only one who can do this? in TF2 General Discussion

It's the same as expecting someone whose feet you shot with a rocket to be launched upwards. Demo mains have simply learned to think in 3D instead of 1D.

batemanits just standard demo main autism dont think too hard about it

Sometimes our brains just go full billiards simulator, perfectly predicting any and all movement paths including knockback.

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

There's a fundamental misunderstanding here. Source does not predict, it interpolates because it already knows what's going to happen. The client is always so far behind the latest packet it recieved (well, not if the interp is too low) that it does not have to predict the future. E.g. the client got packets from time t and t+1 and is rendering time t+0.5. It doesn't have to guess where everything will be, it can interpolate that it'll be halfway between the positions at 0 and 1. By the time the client gets around to rendering t+1 it should have recieved the packet from t+2. This would be interp_ratio 1, the bare minimum, usually it's even more packets so the guess can be better than "halfway" and account for changing movement speeds.

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

Yes, it's much less of a problem in games without stuns but you still have to clean up the dead projectiles (more code), generate more salt because the player sees his own projectiles spawning and then disappearing and the teleporting problem still exists. It's not worth the trouble.

TwiggySure, 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?

If everyone is living in the past and a projectile instantly spawns locally then it has spawned in the past exactly as far behind the present as the player is. Except no one but the player knows about it. Everyone else will see it after the usual delay that ping/transmission time and server processing time adds. If you want everyone to see the same thing then at that time it must appear where it has already traveled to on the shooters side, meaning it has to teleport.

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

frootloops already answered the technical side but I think I should add something you're missing: These are completely different use cases.
Fighting games have predetermined animations that will always play out the same and fixed framerates.
TF2, or any fps for that matter, has neither. Any movement can be canceled or even reversed at will. That is a fundamental requirement for dodging. In a fighting game you get an input an know what will happen for the next 20 frames. Fps don't get that. Anything could happen in the next frame. Any attempt to predict when which input will happen is doomed to fail.
On top of that no one will have the same framerate. A delay of 3 frames is meaningless when someone could be dropping to 30 fps and someone else might still be at 300 fps. You're not even in sync with the server's fps. So instead you get another problem: You can't use the server's snapshots directly. Your 144 fps are not in sync with the server's 66.6667. You will not get a snapshot for every frame you render and even when you do get one it isn't necessarily from the exact same time that your current frame will be. So you need to guess for possible states between the servers snapshots. Prediction is useless so extrapolating from past snapshots towards the future is a fool's errand and should only be done when there's no other choice because guessing movement will continue as is is at least better than freezing everything. So what do you do? You don't render the latest snapshot, you put your personal time at least one snapshot behind the latest one recieved and interpolate between it and older snapshots.

The end result is that you have to interpolate and you can't predict others' inputs so you might as well use interpolation for that as well. (see first paragraph)

Also something I should've added when you asked about TF2 being deterministic, but thought it would be complicated and unnecessary in this case. Thankfully Taat (#9) reminded me that it is relevant in this case.
TF2 should be deterministic, but isn't in practice because the source engine's physic calculations are fps dependent. Now that isn't good, but it is unavoidable because when your fps fluctuate and aren't in sync with anything sometimes you have to calculate 0.0034782378623425 of the movement per second because that's just what fraction your framerate is and there's only some much precision you have and then the rounding errors add up. This isn't a problem in a server based game because the errors are tiny and the server can assert its authority and bring everyone back on the "right" track (the slightly wrong track it has chosen instead of the other slightly differently wrong tracks everyone else has chosen) by the next snapshot. In a peer-to-peer game that assumes every input has to same result from everyone's perspective however you are fucked. Everyone's game state would drift further and further apart. Even if you try to synchronize regularly there's no way to decide on a "correct" state. Everyone is wrong, just in different ways.

Fighting games and fps are fundamentally different use cases, using netcode made for one in the other would have terrible results.

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

If the client can only see the entities the server already knows about it can't "predict spawn" its own projectiles either.

TwiggyYes, 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 :

They 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. It's not ideal in their case either because you're losing a couple frames worth of reaction time, which was kind of the point of having startup frames instead of the damage starting immediately but there's always drawbacks one way or the other.
The whole selling point of their method is that there is no delay to your actions, making it feel just like a local game and the tradeoff is that if prediction fails (that is part two of their strategy) you get warped to the correct state but as long as prediction is right everything is exactly as it would be in a local game.

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.

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

posted 3 weeks ago
#30 Packet Choke issues. in Customization

I suspect that your ping jumping from 18ms to over 300 is neither ideal nor TF2's fault.

posted 3 weeks ago
#5 [netcode]Source vs GGPO style rollback in TF2 General Discussion
TwiggyAlso the GGPO document mentions that games have to be 'deterministic' in order to use it. Is source engine deterministic?

With random spread disabled, probably.
The point is anything that involves a random number generator would be a problem since everyone would get different results.

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

I'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.
Secondly 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?

TwiggyThe only difference I see is that fighting games are peer to peer while fps are client-server, but for me it only changes the agreement on what is correct frame data. How does it change anything related to prediction?

They don't sent state data, they send only inputs, which cuts down a bit on the bandwidth but most importantly peer-to-peer means instead of the client taking the inputs, rendering a frame (with predictions and data from the server for what everyone else does), sending their inputs to the server, the server rendering a frame, then sending the current game state to everyone who then renders the frame again they can instead send the inputs straight to everyone who can then start rendering their frames. That removes about half the latency.
They also don't have any centralized game state so every time a prediction turns out to be wrong they have to instead execute all frames from the point of divergence again with the right inputs without rendering it visually to catch up to the correct state.
Last 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.

posted 3 weeks ago
#26 Packet Choke issues. in Customization

Doing things you don't like to get things you do like is an experience not necessarily limited to your teenage years.

Then again I found a job I did like to pay for my first pc, I very much recommend that option.

Anyway, that's the end of the line for me. Sorry I didn't do anything but spread despair about the inescapable suffering of TF2 on a laptop but that's just how it goes. I played TF2 on a laptop with a 1.4 GHz single core Celeron from 2004 so I can tell you it could be much worse.

posted 4 weeks ago
#24 Packet Choke issues. in Customization

1.6 GHz baseclock sure is a treat huh. At least with only 15W it shouldn't overheat.
Could probably get more out of it if you manage to raise the TDP but laptop BIOS are usually fairly locked down.
Either way that goes beyond the scope of the choke problem.

posted 4 weeks ago
#22 Packet Choke issues. in Customization

Oh, shitty laptop suffering. Either way, 100%, you need all the fps you can get. Unless it's overheating, but that would be kind of embarrassing for a laptop that new.

posted 4 weeks ago
#19 Packet Choke issues. in Customization

Defragging actually "damages" SSDs, but you do you. They can only sustain a limited number of write cycles and there are no mechnical parts so unlike with an HDD it really does not matter where the data is located. Not that defragging could do anything about that since they lie to the OS about where they put the data anyway. Wouldn't help with fps either, only loading times, but you do you.

Do you want the CPU to outlive you? I guess it's kind of old judging by the fps you're getting but anything not overclocked or otherwise abused should last for 20-30 years.

posted 4 weeks ago
1 2 3 4 ⋅⋅ 211