IMO, TFTV admins aren't obligated to follow our requests - no matter how common-sense they may seem - because they are volunteers. Regardless, I hate spoilers as much as the next guy, so I wrote a script to hopefully make things a little less spoilery.

I updated this to hide thread titles in thread lists (/threads or /forum/...) as well. Note that it doesn't remove the slug from page and latest post links, so you can still be spoiled by mousing over those.

After having the grand finals spoiled for me by this post, I wrote a user script that hides the titles of threads in the sidebar (except for upcoming events), articles in the list on the front page, and articles listed at /news that have certain words in them.
https://greasyfork.org/en/scripts/19062-tf-tv-thread-title-hider
Screenshots:

It hides the title of the thread until you click on it, which restores the original title. It also removes the hover text and changes the href attribute of the link to remove the slug (which is shown by the browser in the corner when you mouse over the link).

The script also adds a button in the nav bar that lets you set what words are considered "spoilery":

http://puu.sh/osVNz/e475af8d6c.png

Note that the script does not change the contents of /threads. /threads and /forum/... links are now also filtered, but page and latest post links will still show the thread title when moused over. Go there at your own risk.

You can install the script using Greasemonkey in Firefox or by downloading it and dropping it on chrome://extensions if you have Chrome. You should be able to install it in any compliant browser that has a user script manager, but I've only tested it in Firefox and Chrome.

This will work, but you're not quite correct in that tf2 does not have a limit as to how deep it will search when loading custom content. The reason this works is due to the way the custom folder contents are merged into the game's virtual filesystem:

So when you have a hud in /custom/hud/, it's mounted in the game's root filesystem like so:

/custom/hud/materials/vgui/custom_ui_thing.res
         ^ the contents of this folder are placed in the root of the game's virtual
           filesystem, so the file overrides the default /materials/vgui/custom_ui_thing.res

When you move it to a disabled folder like this:

/custom/disabled/hud/materials/vgui/custom_ui_thing.res
           ^ the contents of this folder are still being searched!
             however, the custom file is now at /hud/materials/vgui/custom_ui_thing.res, so
             when the game loads /materials/vgui/custom_ui_thing.res, it uses its own copy.

You are still adding a new search path, so you are still suffering a potential performance hit from the game having to call out to the filesystem to check for custom content in that path. This can be actually noticeable if you are loading from a hard drive rather than a solid state drive. It is also possible to end up accidentally changing files that you didn't want to, depending on what you name your custom folders.

Personally, I prefer to keep my mods in vpks (which can be made by dragging a custom folder on /common/Team Fortress 2/bin/vpk.exe). Then you can just rename vpks to whatever.vpk.disabled when you want to disable them and then you are actually removing them from the game entirely - no performance hit, no accidental collisions, etc. This is what my custom folder looks like:

http://i.imgur.com/mOR7JFv.png

The only downside to my method that I've found so far is that fonts don't work in vpks, so you have to have them in a folder outside of a vpk.

Yes, the domain started working again later the same day. I didn't post again as I assumed that you had noticed and fixed it.

What happened to the domain?

$ dig tftrue.esport-tools.net

; <<>> DiG 9.10.3-P3 <<>> tftrue.esport-tools.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21279

https://www.youtube.com/watch?v=zKAt9Jq6IdM

When rendered with embedded images off, your post looks like this.

http://i.imgur.com/WgJAfRg.png

This is because nested <a> tags don't work. Since embedded images are off for guests, everyone who is not logged in will be unable to click your links. I imagine a fair number of people who browse on their phones also turn off images to avoid data charges, and they will be similarly affected.

Links for people with embedded images off:
Album
Github
Steam group

I did some basic testing, but I wasn't able to reproduce this problem. Was this only happening on one server, or any MGE server? If it was just one, which one?

I've been tweaking MGEMod just for kicks, but I've also been attempting to fix any bugs I run across. I don't have time to test this right now, but guessing from how you described it, it sounds like either MGE is doing something weird when restoring ammo (I can't find anything in the code that would obviously cause this), or the honorbound attribute is messing with the respawn code in the game, which MGE calls early to spawn you immediately after you die. I will attempt to fix whatever is happening later this week.

If you have "remember active weapon" enabled in advanced options, try disabling it and see if that fixes it, or vice versa.

https://github.com/sheybey/kvlint

Yesterday, I decided that I should write a program in C rather than my usual polyglot of scripting languages. This is the result.

When run on a KeyValues file, kvlint checks it for syntax correctness and outputs a list of possible problems it finds. Although a tad clunky to use, it works pretty much as advertised. To test it, I have been running it on the hud I use:

$ find custom/hud -name '*.res' -exec kvlint -m '{}' ';' > huderrors.txt

Sample output: http://puu.sh/iySB8/5ace25eb0d.txt (I've submitted a pull request to budhud to fix these issues)
Windows binary: https://github.com/sheybey/kvlint/releases/download/v0.4/kvlint-win32.zip

Note that some huds don't work properly from VPKs, for reasons I have not bothered to investigate.

IIRC, listen servers don't work well with sourcemod because you end up being entity 0, which is not a valid client on dedicated servers. Some functions seem to work on client 0, some do not.

hooli, you're having trouble compiling because the code for smlib uses an identifier "in" that is reserved as of sourcemod 1.7 and causes an error. While that could probably be fixed with a quick find-replace, this plugin does not actually use any smlib functions, so you can just remove the "#include <smlib>" line (line 8) and it will compile.

huds.tf

MS-DOS comes to smartphones