they're not, he removed the option and posted about it a while ago https://tf.gg/post/1033132

go in dev/lists/flat.txt and dev/lists/flat_hl2.txt and delete the lines with materials\glass, then re run the generate script

if you're using the premade vpk instead of generating yourself, unpack it and delete the glass folder inside materials

I suppose I should have indicated somehow that I was responding only to the first question and not the second.

I use dd for OS migration, I have never had a single problem with it. Even my heaviest used ssd only has some 200 TBW, so I don't care about writing a few extra GB for an easy, convenient, reliable imaging method that always will work exactly how I expect it to. Are there situations in which using dd could be less than ideal? Indeed there are.

I didn't mean to argue about it, everything you have said is more or less correct.

I mean, he just asked what people use. dd is what I've used many times to clone OS installs since I find the hassle-free and headache-free nature of a bit-for-bit copy to be absolutely worth wasting whatever .00001% of an ssd's life on cloning free space. You're completely right about drive sizes though, a filesystem level tool would be better and easier if the destination drive is smaller, although there is the option of resizing partitions and then copying just the partitions and table with dd instead of the full drive.

Have you considered changing the sens directly in tf2 via rcon instead of changing it system wide in libinput? You could easily make it crossplatform that way, and also keep m_rawinput on. The game client serves rcon if you launch with

-usercon +rcon_password "whatever" +ip 127.0.0.1 +net_start

You could use something like https://github.com/n0la/rcon or https://python-valve.readthedocs.io/en/latest/rcon.html in your script, or, if you deem those clients too bloated, cap a packet, look at how it changes when you send a different value in the sensitivity command, and just send the raw bytes with nc.

Forgive my ignorance: why would anyone ever want a sensitivity randomizer for anything other than destroying their aim?

here https://greasyfork.org/en/scripts/427733-fenoblocker9000-aimisadick-too/code

https://i.imgur.com/IRzm9Gu.png

dd

maybe you fixed it by now but I remember a few months ago this plugin considered rocket jumping to be 'aimsnap detections' or something

it's probably the changes from 9.3.2. if you don't mind it, ignore it, if you do, set mat_filterlightmaps to 1 and clear mastercomfig's lightmaps_override alias to avoid needlessly toggling it

It's still used in the current game exactly the same way it was previously: https://i.imgur.com/ndooak3.png Only difference is you can't set many things with stuffcmds that you used to be able to, but nothing has changed with cl_threaded_bone_setup.

I'm sorry for 'telling you' to disable some of the threading settings, it was simply a suggestion for something to try. I also had a crash after updating mastercomfig and happened to have some of those enabled. I thought it may be possible that the io/loading changes from the latest mastercomfig could conflict with one of them, but it was merely a guess.

I get that, but I also like to do everything I can to curb misinformation so anyone reading in the future is not mislead. This is my last post about it, won't shit up the thread any more.

Hate to keep this going, but no, it has not been removed. You nearly always have no idea what you're talking about whatsoever.

Hi aim is a dick. I looked at your 'GDB log' and feel the need to let you know that that is not debugger output from GDB at all. Only the [New Thread xxxx.xxxxx] is coming from GDB. TF2 outputs the rest of that stuff to stdout regardless, try running it without GDB and you will see much the same output.

I think the faster your cpu the more likely you are to crash, due to race conditions being more likely to arise. I'm on a slow ass computer and basically never crash.