uggs but i still wear em :)

No, net_queued_packet_thread 1 will queue and delay packets regardless of -NoQueuedPacketThread, but will do this unthreaded if you have -NoQueuedPacketThread.

You should either use net_queued_packet_thread 0 + -NoQueuedPacketThread (which I recommend if you don't encounter problems with it), or net_queued_packet_thread 1 without the launch option.

The default config (comfig.cfg) should disable ragdolls. You can disable gibs with the comp, compquality or maxperformance presets.

What version of the config are you using? 4.3.0 should fix this.

So do you mean you don't get stuttering and hitching with net_queued_packet_thread 0 and -NoQueuedPacketThread?

https://docs.microsoft.com/en-us/cpp/mfc/windows-sockets-in-mfc,
https://social.technet.microsoft.com/Forums/windows/en-US/ead342a2-3fbd-48c7-80f8-85b34054e64b/windows-7-suddenly-limits-outgoing-udp-packets?forum=w7itpronetworking, and comments in the Source Engine's net_ws.cpp.

thanks sooo much!!! the kind words really mean a lot! <3

Strange, do you have the -NoQueuedPacketThread launch option and net_queued_packet_thread 0 ConVar set?

cl_smooth does not affect other players, it only affects your own eye location. Interp and update rate won't affect other users, cmd rate will, but only slightly. Ping is the thing that matters the most.

Hm yeah, the particles are a lot simpler in dx8. Not sure if those particle files are sv_pured or not, so maybe you could move them over to dx9.

Well 91 doesn't exist, 91 will just go to 90. The available settings are 90, 95, 98 and 100. 98 is only allowed on Xbox 360 and I don't think 100 does anything but I haven't investigated it enough.

The default value is 1.

Values:

0 - Send packets and split packets immediately
1 - Send packets and the first split packet in a sequence immediately, but queue the rest of the split packets on a separate thread and send them after a delay in between each split packet
581304 - Queue all packets on a separate thread and send them after a delay in between each packet

I tested 0 on Windows and didn't encounter these issues, but if other people experience it, then I'll set it to the default of 1. By the way, what CPU are you using?

Also, stabby, are you using the -NoQueuedPacketThread launch option with net_queued_packet_thread 1?

EDIT: After looking at the documentation about how the Windows network system works, and then crying, I've decided that net_queued_packet_thread 1 is unfortunately necessary for Windows, except in some rare cases.

net_queued_packet_thread 0 shouldn't be causing hitches unless your CPU or CPU scheduler is being dumb. Without the queued packet thread, split packets are sent without a delay.

It is a few hidden ConVars that are being set for dxlevel 90 and 95, using the dxsupport_override.cfg file. These changes aren't relevant for dx8. What exactly do you prefer with dx8?

The max performance preset is good for toasters. You'll also probably want to use the iGPU preset.

No

Preset? Launch options?

You can fix the sound problem with the -primarysound -snoforceformat launch options. Using only -primarysound will cause it to always play the sound.

So because they used the KGB means they had to port all those assets? The gloves don't distinctly look like TF2's style so it would be fine to use some other assets. And, it's not like SteamVR Home has a history of extensively borrowing assets like this minigame. Most of the other content is original for SteamVR Home.

4.3.0 alpha 1

Has a few cool optimization updates, but the big thing is the dxlevel override. This will make installing my config in the custom folder mandatory if you want these DirectX optimizations that improve particle performance, with more to come in future releases, which will include shader optimizations and improvements to the texture preload list.

I would love for people to test and see if this prerelease makes a noticeable difference for them, thanks!

How would it ruin jumping? Source 2 is just another update to Source, and the update to physics from Havok to Rubikon would affect VPhysics, not the QPhysics used for player movement.

Why would I be let down? If there isn't a Source 2 port, I won't be disappointed. I'm just thinking about things that could be possible.

Yes, I don't disagree with you there, but I doubt that the SteamVR Home team just randomly decided to use TF2 assets.

shhh i need this pls