Hey there Guest,
The game servers have moved to semi-dedicated hardware and IPs have changed. Please see front page server widget for up-to-date game server information.
Discussion in 'Team Fortress 2 Talk' started by The Political Gamer, Jun 23, 2010.
this doesn't make sense.
so his point is that it reduces performance, and they didn't mean for the game to look better than it does at default?
And it doesn't fix the problem of people thinking higher numbers means more detail. They'll just end up thinking they're running at the lowest setting and that they can't do anything to fix performance.
Who gave the bull laxatives?
People thought that the lower picmip was, the worse the graphics would be and therefore the better their performance would be. They thought their performance was higher than it actually was.
People who did know that low picmip meant better graphics were unaware that this made Team Fortress unstable.
So? Remove mat_picmip entirely, and add mat_miplevel that uses a reversed scale.
I'm a little pissed about what they did to sv_showhitboxes and tf_debug_flamethrower as well.
Weren't they giving misleading information?
causing everyone to go OB engine hitboxes suck lololol
If they remove picmip, that means that they need to change every reference to it. It's easier to cap it instead of just getting rid of it and rewriting the whole renderer.
Why remove stuff so that noobs don't get confused?
I'm seriously worried with the direction they are going...
That wasn't the only reason, it just contributed to it. Because the resources were never made to appear at those settings, they became unstable and could cause random and severe drops in performance and would cause some crashes.
The issue here is that Valve never told anyone to apply the commands, or even suggested that it would help. I used them to make my TF2 look like Crysis.
Ah get over it, I've barely noticed a difference.
Who said anything about rewriting? Just make it a "locked" cvar.
Yea, that's what i thought too. The hitboxes shown with that command weren't the actual hitboxes used to figure out damage.
Ah, why use GUI when there is good ol' command line? Right? It's all going into the way of usability and intuitively understandable (read: even complete noobs with no brain can use it) way.
Actually, they were the right hitboxes but they weren't affected by interpolation. So they appeared to lag behind, while in reality they worked fine.
So clueless idiots made youtube videos of this trying to prove a point, that hitboxes were broken when they weren't.
With the command gone, we can no longer prove cases where the hitboxes are infact broken though. Like taunts for example (the hitboxes does not move at all when taunting).
Anyway, they removed the command because some people got confused. Which is a shame because It's a very useful command.
So how do you "lock" the cvar?
Takes mp_waitingforplayers_time for example. It's a cvar but it's locked and cannot be changed, or even seen. But things like sourcemod can change these. This is why our servers have 60 seconds of wait time, I raised it from 30 with sourcemod because we regularily have new maps for download. Other examples include all the scout function variables we messed with for Scout Madness.
As Booj said, it's still there, you just can't see or alter it via normal console means... you need a plugin, and you need to know the variable's name in advance.
Another example would be the curvature, "jitter", lifetime, and travel speed flamethrower projectiles.
I still don't understand why this nessescitated REMOVING -2 to -10 entirely though, it's an unnessescary punishment almost for all the people who liked the increased graphical quality, like myself, surely they could simply have placed some text when you submitted the command saying "LOWER NUMBERS MEAN HIGHER GRAPHICAL QUALITY" or "YOUR FRAMERATE WILL BE NEGATIVELY IMPACTED BY LOWER NUMBERS" or something.
The game really looked beautiful on Mat_picmip -10.
Separate names with a comma.