Completely undone. I guess we'll have to wait and see what Valve is considering next when it comes to stickies.

That's how I've thought about implementing a pause detection system. Of course, it's only a heuristic and a rather expensive one, but it's the best we have right now.

1) Given how the player panel already changes to indicate when a player respawns/changes class, and how it's difficult to modify game panels, I'm not sure that I could pull that off.

However, that does give me another idea (thanks to the World Cup)... would there be interest in a notification panel that pops up to show player changes (such as player class changes, loadout changes, or even player joins/drops)?

2) There's a similar option in the Loadout Icons module, which will display the active loadout for every class in the spec HUD. As far as looking at the current observed player, however, Gentleman Jon and I have so far been unsuccessful in actually figuring out who the camera's on due to various SDK issues. I'll probably take another pass at it soon and see whether I can find another way to access it.

3) Perhaps. I would think that a manually-triggered timer would be more useful, though, so you wouldn't be restricted to just certain events.

Well, another issue is that we still can't do time due to the STV pause problems, so no per minute stats can be done.

When you sum it all up, it's really difficult to get comprehensive stats that paint a full picture of a match.

I am very much mad that it can't do more.

You can, because player_death is emitted as an event to the STV client. That contains a lot of juicy info.

I'm just skeptical that extracting KAD is useful without also getting damage and heal stats, which is usually how people measure how well a player is doing in a match.

I did look into this a bit today. It seems like there is an actual method for overriding where you're viewing from, which would work nicely. However, actually changing that value so that you could move your camera around from that spot isn't possible.

So I guess if you'd be fine with it working like one of those weird spectator cameras that only looks at the same thing all the time and that you can't change the position or angle of, it could be done.

I believe it would be possible. There would probably need to be a lot of testing involved, but my theoretical solution would be having a payload containing the unique ID, which would help point to a location where the match server would upload relevant data and client plugins could parse and use that data. It would be an elaborate system, but if it is indeed possible to get the data from the match server to the STV client through all of the STV relays, it would work well.

I briefly touched on this when we were discussing SS-in-SS, but to summarize, I don't particularly like such a system because it's not a server-independent solution (good luck seeing these stats from ESEA or team servers), and it introduces a lot of variables in the process.

That was actually the subject of my investigation. I attempted to extract info from the player entity (which is how SizzlingStats collects stats) and from the player resource entity (which is how MvM displays stats, I think), but neither are revealing any information. There is one event that would suffice in the absence of those two, player_hurt, but that event isn't ever fired in a demo. I believe that the issue is that STV receives a very limited amount of information, and stats (or pause notification, for that matter) doesn't appear to be included.

I did email Valve to ask them to populate one of the above sources shortly before the Love & War update, but it doesn't appear that they are making any changes in response.

Today I learned that attempting to extract damage stats from the game client is utterly hopeless and impossible at this point in time. Without the ability to collect damage stats, I don't think there's really much point in displaying any other stats, so the stats module will be indefinitely shelved until/unless Valve actually changes something to allow me to get at them.

Given that, and the fact that there's not really any major improvements I CAN make to any of the modules due to limitations of TF2 or other sources, I'm unsure of what direction to take StatusSpec next, even though I feel that there is so much better that I could be doing. Suggestions for an y new features would be greatly appreciated.

StatusSpec 0.13.1 has been released to fix an issue with bleed icons not showing up because I sometimes don't know the difference between 0 and 255 alpha.

It appears that the caption got fixed. It's probably not anything meaningful, just a mistake.

I don't believe that they'll release the update tonight, since they usually don't release major updates without giving us a good idea of what's in them. Personally, I'm much more worried for Thursday or possibly Wednesday night.

That is exactly right. The relevant commands are outlined in the README.

StatusSpec 0.13.0 has just been released with options for setting team colors for the following health states: low (0% health), medium (50% health), full (100% health), buffed (150% health); and will automatically scale between those values depending on the player's current health. However, default values for these options will result in the same color regardless of health.

Please be sure to test this release and let me know of any issues, as I did not check this functionality in-depth. Theoretically, it should be fully working, but as far as my testing goes, I only know that it doesn't crash.

Valve usually doesn't release major updates without update pages during the week of, so it might actually be safer to play it today while we're still in the dark as to what the update will be about.

So apparently the lead I thought I had on team names didn't actually pan out. I did discover that mp_tournament_blueteamname and mp_tournament_redteamname change team names, though.

StatusSpec 0.12.1 is now available with some fixes.