yes

Some people may also prefer the vpk because it's less files to manage.

And yes, that will work.

6.0.2 released with documentation improvements and bug fixes.

I guess the -unbuffered_io launch option does not work then. The script scans a Source game folder for launch options.

That's what I want to find out from people testing it. Launch options can be found here: https://gist.github.com/mastercoms/12c51b171e2d3589eedc6bc9905e8f5e

I've increased the max packet size in 6.0.1 to resolve this issue.

It enables optimal buffer allocation and unbuffered IO for file loading. It works on Windows. I don't believe it works on Mac or Linux.

I was never aware that this was an issue with my config, but with custom HUDs.

6.0.1 released with network improvements and fixes, organization improvements and small tweaks to eye optimizations.

I've also created a Discord server so people can get faster help: https://discord.gg/CuPb2zV

Use the commented options https://github.com/mastercoms/tf2cfg/blob/master/mastercomfig/cfg/comfig.cfg#L438

Maybe you can also use viewmodel_fov 0.1.

Yes, you can see see the changes to the config here, or on any release by clicking the "View the code changes" link.

Yes, gibs don't impact performance as much as ragdolls.

The first two commands load data files on a separate thread, but I've found it to cause FPS drops so they're disabled.

The last two commands load all data associated with a data file, and it does this synchronously to prevent file loads from stopping the game to load stuff during a play session. If you have async data file loading on, you can turn these off, as the files can be loaded asynchronously.

New launch option to test: -unbuffered_io

Maybe try turning on the async mod_load cvars.
Also turn off cl_new_impact_effects if you have it on.

If it were not for that bug, 2 would be more optimized. The bug is that if you got server data from the last tick, it would still revert you to the predicted data for the last tick if there were no errors.

I found this bug by looking at the code.

A better rate value for you would be 90000. You can keep max clear time on 4.

Yes, 6.0.0 changes the comfig.cfg file.

Just create a file called custom.cfg in your cfg folder and add mat_picmip -1 to it.

snd_spatialize_roundrobin 0 // 1 adds a two frame delay to spatialization, not very good for competitive players

2 frame delay to sound spatialization, so sound will sound like its coming from its location 2 frames before, its slightly noticeable if you turn very quickly.

It's hard to really know what's causing stutters without any debug info. Try logging your console -condebug and turn on developer spew (developer 4).

Yep, I found that out myself and changed the documentation to say it's for Linux users only. I honestly should have initially investigated it more because it caused some trouble for people when I recommended it.

//net_splitrate 4 // Split 4 packets per frame, reduces choke but is more CPU intensive

Yeah and I would recommend using the queued packet thread.

Yeah I played the original Bridge Constructor on PC, it's pretty fun actually. It looks even more interesting with the Portal mechanics in there. And I suppose we'll get to hear more of GLaDOS, which is nice.

This release is just something extra, it isn't preventing/hindering Valve from making/releasing their own games.

not a Valve game, they just let another studio use their IP

here are some screenshots https://twitter.com/ValveTime/status/938421992512016384

Practically, the Source Engine stores snapshot (aka update) rate as an integer. It can't have decimals.

Now, it stores it as an int because of bandwidth control. Your network usage is defined in bytes per second, so therefore you have to define update rate as the number of snapshots in one second. You can't send a fraction of a snapshot, so it can't be a decimal.