There's a very small overlap between this and mastercomfig (with the surfaceproperties.txt and whatnot), but the majority of it is compatible. This deals with mods that may or may not give fps but do clean things up a bit, without touching any actual cfg settings. I'd recommend using mastercomfig, and likewise mastercomfig's documentation references the old cleantf2.

I wasn't expecting this many issues with people getting it working, I will try debugging things. Just as a note for flat textures, it should take very long (upwards of several minutes) because image operations are expensive and there's no real way around that when we're dealing with thousands of images.

Something to note though is that without raw input and at low fps potentially, if you move your cursor far enough that it hits the edge of the screen / moves overs to a secondary monitor, it will cause issues (negative accel by hitting the edge of the screen, losing focus on tf2 entirely by hitting the secondary monitor). Raw input doesn't run into this issue afaik, but I stand to be corrected.

You should use whatever dpi is native to your mouse sensor though, and that (depending on the sensor model) will usually range from 400-1600. The increase in granularity by increasing dpi and lowering sensitivity generally isn't worth it compared to potential issues from using non-native dpi's.

Just as some debugging, you wouldn't happen to be using a mac or linux would you? That might explain both the .bat file breaking with selecting options, and the actual scripts generating it failing (since it depends on running other scripts which run some imagemagick executables, which I'd wager is why everything appears black).

I didn't test thoroughly on other systems or with different setups, but it works on my machine™. If the issue is the OS until I can port it to .sh you might have to just ask for a vpk generated with the options you want. In Adje's case it'd be https://www.dropbox.com/s/f39abfzj072jzef/adje.zip?dl=1

It modifies stuff in place normally, and then you can run pack_vpk.bat to create vpk's for it. Changing options will require running pack_vpk again to keep them up to date. The cleantf2plus folder will still be there, but the cleantf2 vpk's will be generated as well.

It won't do anything with your hud or cfg, this doesn't touch stuff like that.

Some of the model removals do, but the main ones don't. Player gibs / ejected shells / weapon gibs do, but nohats doesn't and everything else doesn't.

The big thing that required preloading in the old cleantf2 -- the unlit textures -- are considered "obsolete" in this version because tf2 updates stopped it from being preloading and it's very broken in sv_pure nowadays. It can still be enabled by going into the generate.bat and editing it, but I wouldn't recommend it.

I can't add screenshots until later tonight at least. Most of it should hopefully be pretty self explanatory, except for how flat textures works (sv_pure 0 is the same for both, sv_pure 1/2 looks default with unresized flat textures, and sv_pure 1/2 with resized textures looks like this but with lighting).

There are also some more things I need to list out to make flat (models, mostly) but that'll just be a few lines added into a file.

Yes and no. Flat textures will either return to default (if not resized) or be grainey (if resized) and that's down to preference (I actually prefer the grainey to default, though I know I'm in the minority there). Everything else should be fine.

Breaking as in "some textures are fully lit, some are completely dark, and some are missing entirely" that you'd see with unlit in the old clean tf2 will still happen if you manually enable unlit textures, but you have to go out of your way and edit the generate.bat to do it.

https://github.com/JarateKing/CleanTF2plus

I've been working on the sequel to clean tf2 to fix some of the issues with it, and extend it further. This improved version is a framework that can extract and modify from the default vpk's, that lets it stay automatically updated and easier to modify. This also lets it extend to a lot more to different types of mods, such as providing the most up to date nohats mod.

Options:

• Flat textures -- both original size (traditional quakelike textures, default in sv_pure) and resized (clean tf2 flat textures, grainey effect in sv_pure)
  
• Nohats - both full and headsfeet options
  
• Player gibs, ejected shells, and weapon gib removals
  
• Soundscape removal, surfaceproperties.txt, and mtp.cfg files

Some advantages over the previous clean tf2:

• Scripts provided that let you update automatically whenever tf2 updates
  
• Very small download since big files are generated
  
• Multiple suboptions can be provided for different options
  
• Script provided to convert cleantf2 into a set of vpk's.

Links:
Readme
Troubleshooting

It's one thing to say "the police should monitor more and get a better success rate at preventing this" which is fairly uncontroversial even if you disagree (on grounds of too much government surveillance being bad). But sarcastically saying "haha yes of course, how could anybody possibly see this coming" based off unconfirmed claims after a shooting just makes you look like a dick.

Am I reading it wrong or is your stance "trying to look for the root cause of this issue or discussing it further is bad, you should just be sad when it happens and leave it at that"?

It being an absolutely fucked up and inhuman thing to do is exactly why people look for a reason. I don't think the focus on pewdiepie is justified but it's absolutely fair to try and figure out "what led him to do this? Is this a freak occurrence, or is it coming from somewhere likely to lead to more terrorists?" precisely because no one wants anyone else to die in this type of situation.

http://fakkelbrigade.eu/maps/ final1.bsp.bz2 is marked as from 2017, could go uncompress that and use it

Is the focus on narrowing down into one theme (high level play, production, league management, etc.) or get a broad overview of every aspect of the community?

Also yes please post the paper when you're done.

pete: hey everyone, I've noticed multiple high level players abusing this exploit that's trivial to do, we should make sure valve knows what the issue is and how to fix it, and raise awareness to pressure them so they actually do

sigafoo:

http://i.imgur.com/YRtuSz2.gif&f=1

Can you confirm whether or not it's class changes that causes this? A likely cause would be one of your class cfg's changing settings and not getting changed back by the other class cfg's (if it meant to change in the first place).

https://github.com/JarateKing/BaseHud

Something about huds I've noticed is that a lot of the foundations when making a new hud take a while to set up. Stuff like adding certain common materials, or adding a blank font, or using some anim fixes are just busywork that distract from actually working on a hud. And while a lot of work has been done in the past few years to make working on huds easier (including using #base to split up files or setup auto-update scripts, or putting new closecaptions in a 'closecaptions_' folder to clean it up, or doing localization edits in chat_english.txt) most huds don't even attempt them because there's a lot that needs to be done before you get anything from them.

So for the past while I've been working on a starting point for huds that does all this tedious setup for you. It should provide any hud dev with a consistent, clean, and well developed base. And it should provide lots of features that may be hard to figure out or implement, without needing any extra work on your part.

Some notable features:

• clean directory structure
  
• large bank of basic materials and refract images
  
• includes an auto-update script, for both windows and linux
  
• full setup for closecaptions editing (compiler script, example source, and multiple options)
  
• localization customization (with chat_english.txt and a language converter script)
  
• different cfg options provided
  
• preloaded cp_icons images
  
• option to remove the screen dimmer that appears when you press the play button

What this doesn't do:

• Change the default hud appearance any. You still edit it as if it were the default hud, you just have a lot of the setup and access to certain features available. This is a tool for hud developers, not a custom hud.
  
• Force any design decisions. The file structure is split up and pretty laid out in a clean way, but it doesn't make the hud's design follow any specific pattern or abide by any limitations.
  
• Be specific to any particular update. Everything this basehud does is pretty low impact and unlikely to become out of date -- the only parts that frequently get updated are covered by the auto-update script.

Links:
Readme
Usage Guide

If you want to use this, you can download the zip or you can fork the repo and edit it from there. And if you find any issue or something to contribute, either message me, create an issue on github, or fork the repo and make a pull request.

I think the line is pretty obvious:

• box shadows makes it trivial to spot people around corners or in hiding spots - obvious exploit
  
• making decloaks loud makes it extremely obvious when a spy is around - obvious exploit
  
• removing the sniper scope gives you a lot of extra vision - obvious exploit

And notably, valve did try to stop both changing decloak volume (it's just that sv_pure doesn't enforce the files properly) and sniper scope removal (they fixed a trivial version but not one that uses anim locks). And as for box shadows, where you change how shadows work by misnaming a hud font declaration, that's about as blatant of a glitch as you can get -- it's just a glitch that also gives you a very big unfair advantage. I think it's fair to say those are exploits.

Compared to:

• Explosion removal makes the screen a bit clearer sometimes - not an exploit
  
• Soundscape removal removes a very small amount of useless noise on some maps - not an exploit
  
• Surfaceproperties also makes the screen a bit clearer sometimes - not an exploit
  
• Medic radar is intended behavior of the command in the first place - not an exploit

Of those medic radar's the only one I could see anyone actually considering an exploit since it's the only one that gives you any actual advantage, but that's also something that would be really easy for valve to stop if they wanted to. All of which are files that could be blocked in sv_pure or commands that could be limited / removed / locked. They just aren't problematic, unlike the actual exploits above.

What are you on about? You can hear multiple sounds at once, and spy decloaks are very distinct. A few ambient noises aren't going to block your hearing from picking up on a spy decloak.

The point of increasing the decloak sounds' volume is to, you know, make them actually louder. Either by upping their volume, or making everything else quieter and then upping the game's total volume to compensate. It wouldn't do anything if it was just "a few sounds are removed."

That's because it was never in the sv_pure blacklist in the first place. The majority of script files are not blocked (whether they relate to sound or not) because most script files are not abusable (or at least not as obviously and as blatantly as being able to change the volume of every sound in the game). In fact the entire blacklist is:

sound\...
models\...
materials\...
particles\...
scripts\game_sounds.txt
scripts\game_sounds_manifest.txt	
scripts\game_sounds_player.txt
scripts\game_sounds_vo.txt
scripts\game_sounds_vo_handmade.txt
scripts\game_sounds_weapons.txt
scripts\soundmixers.txt

The issue is that game_sounds files are in the blacklist and should be blocked, but aren't. I don't know the details - might be some load order shenanigans - but it's down to the blacklist not working right, not valve neglecting what should and shouldn't be blacklisted.

I can second that, the ideal solution would be to add a cvar for enabling/disabling soundscapes. But it's not really a big problem having to edit a file for soundscapes either, it's just a bit less accessible than a cvar.

They do intend for sv_pure to blacklist these; cfg/pure_server_full.txt specifically puts all the game_sounds files as 'trusted_source' so they should be blocked in sv_pure. I'm sure if enough people emailed valve to say "hey these blacklisted files aren't getting blocked, and it can be abused" they'll be more likely to deal with it than most things.

That can only remove ambient map sounds, which is basically nothing and doesn't give you an advantage. There's a lot of minor quality-of-life things you can customize (surfaceproperties.txt, extra_models.txt, stuff like nohats, arguably even huds and cfgs) that aren't really a problem if they're allowed and are definitely not comparable to actual cheats like making spy decloaks super loud.