I'm having this issue too, with like 90% of the Virginia servers. No trouble with LA.

EDIT: Nevermind, troubles with LA. Whenever a round ends in a mapchange, I just get an infinite dialog box:

http://i.imgur.com/yPaXAXv.png

I already have access to anywhere between 90 and 120 using my exploit that I showed off above, and I feel like 110 is a good compromise between situational awareness and balance. At the very least, we should have 100.

I already mentioned that when I stated how players sit on the couch. However, the reason games use it is because of performance. The reason they get away with it is because it isn't bad since you're sitting on a couch.

There is a pretty big GPU hit in regards to increasing the FOV, because you are literally rendering more of the world, more players, more projectiles, etc, at least assuming the game in question used proper occlusion culling to begin with. Speaking of which, there's a pretty big bug in regards to having a high FOV (over 100) in TF2, since Source uses a form of occlusion culling called PVS, or "Potentially Visible Set". This breaks the world into "visleaves" that determine what parts of the map are rendered based on player positioning. However, something I've noticed when playing with an FOV over 100 is that these visleaves are rendered and compiled based on an assumption of a maximum of 90 FOV. When playing with anything higher, you're going to start seeing clipping, object unloading, and sometimes complete occlusion culling bugs where there isn't a visleaf loaded and you just see skybox in the corners of your vision. Here is an example of this happening in Black Mesa when the FOV is uncapped.

Here's a demo I just recorded on mvm_decoy showing off instances of both skybox bugs and object unloading due to occlusion culling.

Yes I meant it's asymmetrical, not nonlinear, as opposed to something like Quake that isn't class-based. A detriment to both sides is technically equal, but it's still a detriment to a class. For example, you can't say that Scouts should have 300 base health instead of 125 if your argument is "Well, both BLU and RED will get this buff, therefore it's balanced", because it's equal, but not balanced.

Again, I'm not at all arguing that the max FOV should be 90. In my opinion it should be 110. I'm just arguing against an uncapped value.

For the record, FOV directly impacts performance. Higher FOV = lower performance, on a pretty big scale. There's a reason consoles have such a low FOV - it isn't because console players sit on the couch, it's because consoles are weak and so they lower FOV, which they can afford to do because players sit on the couch, in order to gain back some performance.

That being said, FOV doesn't cause much of a performance hit in TF2 for the same reason that graphics configs don't really do all that much in regards to performance, in the majority of cases. TF2 is not GPU-bound, and increasing the FOV is (mostly) only going to hit the GPU. Performance won't change much in TF2 because of this.

i didn't know making a class useless was "slightly nerfing" it

regardless of how you feel about scout, it doesn't change the fact that a technical setting should not interfere with game balance. 90 is too low, but uncapping it is even worse.

having good awareness can definitely mitigate the issue, but that's a skill counter to the class, and there shouldn't be a literal checkbox that does the same thing for bad players, making the class bad against everyone.

Because in a non-linear game like TF2, having a FOV over a certain amount will actually harm game balance. For example, if a certain player has a higher FOV (and they actually take advantage of it), it's much easier for them to spot spies and avoid them, effectively nerfing spy as a class. Same for scout, a class that relies on being able to flank.

Regarding refresh rates and FPS, while having a higher FPS and higher refresh rate will definitely help a player's performance (assuming they aren't an idiot and can actually notice the difference), those variables don't directly impact balance, it just improves the overall experience. The same can be said for getting a better mouse, or better audio so you can hear footsteps.

shhhhh

r u srs?

regarding my exploit's proof, sorry for the delay, vacation made it hard for me to get a demo

proof

recorded on a valve server on pl_upward

alright I was going crazy searching the tf2basehud diffs for this, thanks

pushed fix for scoreboard issues and also reverted medal tweaks, favoring the regular scoreboard not being broken while breaking the mvm scoreboard

known bugs from tough break overall:
scoreboard has darkened fields under player names
ping shows up as a graph instead of number

pushing a fix for this soon

so kevin are you going to get no sleep for a week?

that's commitment

dvorak?

https://upload.wikimedia.org/wikipedia/commons/thumb/2/25/KB_United_States_Dvorak.svg/2000px-KB_United_States_Dvorak.svg.png

seriously benefit of the doubt here because k and m aren't close on dvorak

What? That's not the issue here.

The issue is that server-side plugins can install .dll files to clients and then launch them - think plugins like Sourcemod or Metamod. These are things a server admin has to install manually, a server can't be hijacked unless someone actually gains root access to the server. Not even phishing for an rcon will give them the level of access they need. You'd need either access to the admin panel from a host that lets you mess with plugins, or if they have SSH access you'd need their key.

TL;DR this isn't usually something that can be done from simple hacking or hijacking, this needs to be intentional from the server owner. This is why Valve servers should be okay - because you can trust Valve (le memes). You can't always trust others, so be careful.

In regards to competitive, this is dangerous in situations like TF2Center and UGC, because you don't always know or trust the server you're connecting to. This is not a problem in ESEA because ESEA provides its own servers - or at least, it's not a problem assuming that you trust ESEA.

These will not spare you from this exploit, most likely. It might, and if you don't mind the side effects then by all means use these cvars, but I'm fairly certain that an engine-level bug like this would disregard simple cvars.

Okay when I get home Thursday night I'll push a fix

still on vacation until Friday, is the scoreboard broken?