Launch options, remove -nosrgb

r_worldlightmin 0.0002

thankss <3. i honestly could have gone more in depth on the other stuff but I'm glad you liked it!!

and I would be glad to hear about it. I'm no longer working on mastercomfig, but that doesn't mean I'm stopping work on TF2 configs.

You can also use my rate calculator and confirm the values with me to further adjust your rate settings according to your specific Internet connection speed. These values are used to determine the rate at which Source can send packets to and from your PC without overloading your connection. I use net_maxcleartime, which is basically a cap on the packet delay between sent packets that doesn't depend on packet size like rate. This means you can effectively get higher send rates for client packets if they are larger. This is what CS:GO refers to as "surge rate", and they've implemented this functionality on the server as well. Unfortunately, this trick only works client side on TF2.

Well, first off, you have conflicting values of cl_interp and cl_interp_ratio. cl_interp and cl_interp_ratio are used to determine the client interp value, which is a single decimal value measured in seconds.

cl_interp_ratio sets the client interp value to be cl_interp_ratio divided by cl_updaterate, while cl_interp is a direct value for the client interp value. The client chooses the highest value among these two for the final client interp value.

You've seemed to flip the cl_interp_ratio value that is used conventionally for projectile and hitscan classes.

Now, let's talk about what interp actually is. Interpolation is an actual word, not just a Source Engine term. You may have also seen lerp in the net graph. This simply is short for linear interpolation, which is something you probably did in school when you calculated a line equation from the rise over run of two points. This is a way of determining a linear, continuous path from one discrete point to the next.

Now, in the real data that you recorded those points from, the actual continuous path might have been a zig zag, might have curved down, anything really. There's a large amount of realistic possibilities, but how large that amount is depends on the distance between the two points on some difference on an axis, let's call this delta x. For smaller and smaller delta x's, you can imagine approaching the point where the distance between the two points along that path is so small, where the delta x between the two points is practically zero and so the path could only really be a straight line (what we call dx).

For any delta x larger than that, there is a possible path error that could occur, and that possible error gets larger and larger as the delta x increases. So, when we do linear interpolation, we don't want to do it at a large delta x that would result in this kind of error. That will get us the best result.

Now, how does this stupid math stuff relate to Team Fortress 2? Well, the server runs its game logic every 0.015 seconds, and the results of the game running logic at those discrete steps get sent to your PC through the Internet at an interval of cl_updaterate times a second. So you're (theoretically) getting discrete points of data at a delta x of 0.0151515151 seconds if you have cl_updaterate set to 66.

The result would be players teleporting around from point to point at a refresh rate above 66Hz. So, interpolation needs to be done by the game so that these players smoothly travel along a linear path from point to point. But, people with even 60Hz monitors need interpolation at this amount, because the Internet isn't perfect. Sometimes packets are sent out of order, delayed, or dropped completely and the server can even slow down its own tick interval from 0.015 seconds to something higher that results in maybe even 40 packets a second instead of the commonly requested 66 due to high CPU load. In addition to interpolation being needed for rendering updates, interpolation also smooths out these irregularities in update intervals.

Let's expand on this imperfection in the Internet further. Interpolation requires two points to estimate the linear equation between two points, obviously. So, these delays where the effective update rate drops below 66 will change when you'll get these two points of data to do your interpolation. If you have your client interp set to 0.0151515151, and the next packet doesn't arrive in that time, then your game has no second data point to interpolate between the last one and this one. So instead, it has to entirely guess the second data point through a process known as extrapolation. Source uses linear extrapolation, where it takes the current velocity of the player and just assumes that the player continues with that velocity for the next required seconds. Since this can have a huge error, it's limited to 0.25 seconds of extrapolation, after which it just freezes movement.

Interpolation is obviously better than extrapolation, because of what we discussed previously about delta x's. These update intervals within TF2 are small enough, with velocities slow enough, for the linear approximation between two real data points to not have a large error. However, extrapolation is not going off of any real data of where the player is in the future for its prediction, so it will have a much larger error.

In order to avoid this issue, you need enough packets in your buffer queued up for interpolation so that the game can use a spare packet instead of guessing very inaccurately. This is why it's generally recommended nowadays to have your interp above 0.01515151, so that there is that extra packet if you need it at least some of the time. To guarantee a spare packet in the interpolation buffer all the time, you'll need your interpolation at 0.0303030303.

Now, a lot of people argue that interpolation adds a visual delay on where players are and that you need the lowest delay possible, ignoring any extrapolation risks. This is true for projectiles, but the visual delay is fully lag compensated for hitscan. This is why they recommend 0.01515151 interp for projectiles and the far safer 0.03030303 interp value for bullets.

However, I'd argue that the accuracy in current position that you get from a lower interp is far less valuable for projections than accuracy in trajectory, because predicting where people are GOING is going to be much more important than seeing a time accurate representation of where they exactly are right now. In addition to this, interpolation will always result in an accurate position history because its following what's happening on the server, albeit delayed, whereas extrapolation will be wrong in both trajectory and position.

So, I recommend a cl_interp of 0.030303 and a cl_interp_ratio of 2, if possible. However, I've also tuned a value based on what I've measured on normal packet jitter + drops on servers. This is cl_interp 0.0178571 and cl_interp_ratio 1.178571. Use whatever works for you.

Now there are other network settings as well. I recommend cl_updaterate 66 and cl_cmdrate 65. Why? This is because of client prediction. For your own player, the client will just simulate your actions locally using its own server code because that's probably what the result is going to be from the server anyway. However, there is a bug in this where if the two value are equal, client data is preferred over server data. So, I set the server update rate to the highest, and the client update rate to one lower to avoid this issue.

I also recommend different packet size/compression settings.

net_compresspackets 1;net_compresspackets_minsize 128;net_maxroutable 1200;net_maxfragments 1200

The net_maxroutable and net_maxfragments is based on Valve's updated metrics on good packet sizes in CS:GO and Dota 2. The compression settings are to revert a change by Valve made in TF2 many years ago which bumped up the compression threshold to reduce load on servers. For clients however, this value should be much lower since you're compressing much smaller client update packets and generally have less load than a server.

I also recommend cl_smooth 1 and cl_smoothtime 0.1 to reduce client view position jitter when you get juggled or pushed by being in front the payload cart.

Finally, probably the most important of the bunch is your rate settings. These were set in 2007 to 80,000 bytes per second, which was a reasonable value back then. However, since then, Internet speeds have gotten better and although CS:GO has updated its default rate to 196608, TF2 has stuck with that same old default rate.

So, I recommend rate 196608; net_splitpacket_maxrate 196608;net_maxcleartime 0.020346.

Hey guys, today I would like to officially announce that mastercomfig specifically is cancelled. I have some exciting plans in the future to provide a much more useful service that encompasses all that mastercomfig provides, and more. I'm currently in the planning stages for this idea, but it will allow me to be less reliant on TF2 specifically and also give much more benefits than just some value tweaking. It will also make updates less dependent on me and use the power of the community.

Put your preferred net settings in custom.cfg.

To think I admired Sketchek at one point. Gosh, I thought you were brave, trying to make a bold statement about video games and the sanctity of life. But no, you're just a coward. You lied to all of us just so you could lay low for a little while, reaping the rewards of our misguided kindness and love towards you. And now you have the audacity to come back like this. I won't hate on you for admitting to it, but you should have never done this in the first place and that's what I'm angry about. However, in revealing your lie, you showed no empathy or even a slight bit of consideration to our pain, so I don't even know what to think about your announcement. Did you really think you could laugh it off with all of us? Do you have no shame or dignity?

EDIT: I appreciate your genuine and heartfelt apology. I understand you made a bad choice and although I can't fully accept your apology at this moment because of how extreme and horrible your lie was, I'm glad you're making steps to improve yourself and get yourself back on track.

Try resetting your mastercomfig settings within the settings page.

0 gets rounded up to 1.

Try opening regedit, HKEY_CURRENT_USER\Software\Valve\Source\tf\Settings, then remove mat_antialias.

Not noticeably.

https://docs.microsoft.com/en-us/windows/desktop/WinProg64/performance-and-memory-consumption

I took their language to mean that they reserve the right to release a Heavy update in the future, and that just because Heavy lost doesn't mean they will never ever update Heavy again. But other people took it to mean that they were confirmed the Heavy update coming after the Pyro update, which I don't think is valid.

You can review what's in the file on GitHub, but I would recommend using tf/cfg/custom.cfg for your own stuff. This way, your config doesn't break every time mastercomfig updates, and you can be sure that your stuff runs last and gets set to what you want. It also is more efficient, especially if you use modules.

In exclusive fullscreen mode, it won't really affect performance (maybe a frame or two), but it will make Windows snappier.

66.

66.67 is useless because update rate clamps down to an integer (no decimal places). 67 is doubly useless because sv_maxupdaterate is 66 on pretty much any server. However, on servers where this is not the case, update rate is limited by the tick rate of the server (1/0.015). You might thinking you should use it then, but no, because since client side, it is still at 67, which messes up network timings when it being considered to be at (1/0.015) on the server, but 67 on the client.

dxlevel 10 in the orange box source engine means that it ignores dxsupport

so this mod is just pepega

Delete %appdata%\mastercomfig-app\Comfig to reset the cache

Did you modify the VPK? Seems like its corrupted.