No, it is the standard installation procedures, and since you managed to successfully crash your game with previous versions, I doubt that is the issue.

Check your console for load errors relating to StatusSpec. That should clue us in to what the issue is.

StatusSpec 0.18.0 is now available.

The issues introduced with last week's horrific update should all be fixed now. In addition, I have descended into the pits of hell Source and come back with the meaty heart of its glow system. As a result, outlines should be more reliable and more extensible now. This has also allowed me the opportunity to introduce a new feature - projectile outlines!

Feedback and suggestions appreciated as usual.

No, because the library files need to be recompiled as well, and the AlliedModders SDK is incompatible with the Valve SDK.

The Valve SDK is used by client plugins because VPC makes editing and compiling with Visual Studio on Windows not a pain.

Unfortunately, it won't help client plugins until Valve releases that update to the SDK. Servers (well, at least MM:S and SM) should be good to go.

StatusSpec will remain broken indefinitely until the Source SDK is updated. I apologize for any inconvenience.

It looks like several client plugins will be broken with this update. The KeyValues library was changed in this update, apparently.

On a side tangent, CompCtrl was made with the ruleset debate in mind, particularly with the consideration that the game doesn't natively support halves and that alone causes problems.

I personally would prefer to see two shorter halves, though twenty minutes a half feels arbitrary. Fifteen minutes seems a bit short, but testing to determine the best half length would be the best course of action.

SizzlingStats uploads zipped demos to Amazon S3 and stores them for 2 weeks.

As an update, Eric emailed me back yesterday and said they were looking into it. Hopefully it will get fixed very soon.

Probably not going to happen unless I spend the time to port over TF2Items to a standalone plugin, but I'll consider it if I have spare time and Valve still hasn't gotten around to fixing it.

True, I guess, but most schema changes like that don't have major attribute changes.

Well, the server's item schema isn't updated until the server is restarted, so it doesn't make much of a difference. Most major schema updates come with a server update anyway.

If that is an issue, though, the server has to be restarted. There's no way around that, as the schema download occurs at startup.

Alright, here it is.

You need to have:

• SourceMod
  
• TF2Items
  
• TF2ItemsInfo (replace the tf2itemsinfo.smx within the package with a compiled version of this patch to avoid bad errors)

The plugin itself (source) should be placed in the plugins folder. What it will do is force all items to use the default attributes for that item, thus blocking the exploit of being able to see other players' health. (There MAY be side-effects with stranges and other cosmetic items not working, but I figure that fixing the gamebreaking bug is more important than breaking the shiny pixels.) It can't do anything about the wallhacks, but those can be blocked with sv_pure 2.

Let me know if you need any help.

Well, I am actually an idiot. The fix I posted above does not work. Please disregard.

On why the medic views aren't working: the attribute is apparently attached to the Gibus for reasons I don't know. If you add the atribute to the Ubersaw (or any other item you wear I guess), it works perfectly.

I may try to look into another fix simply because this is a critical bug. I doubt that it would help ESEA/CEVO, though.

I just tested, and you can, but it's weird. sv_pure 2 does NOT enforce item schema, so these exploits, laughably, will still work. You have to set sv_pure 1 and add the following to pure_server_whitelist.txt:

whitelist
{
	scripts/items/items_game.txt	trusted_source
}

I've emailed Valve and asked them to add this to pure_server_minimal.txt and pure_server_full.txt so that it gets enforced on sv_pure 0 and 2, respectively.

See my below post, this doesn't work.

This is just another symptom of the design of the current item system. Almost every (if not every single one) of the item exploits in recent history is due to the fact that the client stores the schema to items_game.txt on disk, and there isn't much of any checking on the client or server end whether that schema being used is legitimate.

I'm going to try to figure out if there's a way to fix it on individual servers. Meanwhile, it might be useful to figure out if this shows up in client demos, because if it doesn't this is pretty much undetectable.