This isn't quite right. What happend was that the long time admins, Nymthae and Firestorm, that actually organised the lan competition, liaised with Multiplay and worked with production both "retired" at the same time. Nobody else stepped up to replace them so Wolfmachina took the opportunity, but he also used it to take control of the production.

This wasn't really announced either semi-privately or otherwise, it just leaked out slowly as a result of individual conversations effectively setting the tone for everything that has followed. TFTV never had a chance to continue production really whether there was a collective will to or not.

Obviously not everybody was happy with the way this was done, but mostly people got on with the job and judging from the viewer responses none of that really came across.

If you won't split divisions then use a Swiss format if you're not. Take the time to create seedings to accelerate the skill matching. It's not a panacea but it will reduce lopsided matchups. Make your season shorter if you have to.

This is a problem that's manifested itself continuously across cups and new leagues and divisions for years, and admins never solve it.

While I don't disagree that disengaging from commercial platforms has probably stunted opportunities, it's worth remembering that this isn't a core faceit project. This is built on the faceit api by TF2 people and as such is very much a hybrid partial diy effort along similar lines to so many other home brewed systems, but basing it off a larger commercial service's underlying resource provision.

It doesn't mean faceit have no interest, but it also doesn't mean they are particularly committed to our game in the same way the ESEA pug system might have been if it had been actively used for several years.

I don't mind the answer, more the maps, whitelists and class limits or lack thereof.

What you want is an elastic system that adjusts skill matching criteria based on current queue population and provides closer matches when possible and looser matches when activity is low. This could possibly be based on a user preference, although that does mean that users that always prioritise quality may never be matched during low population periods if other good players are willing to play a broader range of skill.

Ideally that would be something that received real time feedback so the waiting player could see what their skill preference would actually translate into in terms of wait time. Obviously nobody will do this.

Ryb isn't underrrated. Randa on the other hand never got the international recognition he deserved.

It's true, makes running ecommerce stores a pure joy.

https://en.wikipedia.org/wiki/Stockholm_syndrome

Typically 1 activates and 0 deactives. From the MedicStats source:

- You can disable logging buffed heals with cvar: medicstats_logbuffs 0

So medicstats_logbuffs 1 should be active

e: Although looking through the source of both I can't actually find any parts of them that output the text "overhealed" which is odd.

e2: It appears it's a LiveLogs thing, maybe that's installed on one server and not the other. I'm not sure what the buffs functions output in TFTrue and MedicStats, maybe they just mean healing events at all? Reading the code that's all they seem to output.

MedicStats turns it's own buff logging off if tftrue is installed to prevent them both doing it. For Tftrue the convar is

tftrue_logs_includebuffs 1

for MedicStats its

medicstats_logbuffs 1

Maybe the server admin turned off all additional logging for performance, although adding "overhealing" to a log line isn't exactly a strain

Taken form this game http://logs.tf/1998335 this is what a tf2 log healing event looks like

L 04/04/2018 - 19:44:12: "SoLe<464><[U:1:3624870]><Blue>" triggered "healed" against "Paulsen<469><[U:1:35306962]><Blue>" (healing "24")

I'm not sure how you determine from that whether the heal event is a buff or healing from a damaged state. The logs don't give player health totals, and they also don't record all damage events (self damage, world damage, etc) so you can't reliably calculate it from context.

One possibility might be that overhealing always heals for certain amounts, but that would require some research to establish whether they were different from a normal healing event. Even if that were the case healing rates between normal max health and overhealed health probably also vary by medigun (which isn't shown by logs unless there is an uber) and the class being healed, so it's hard to reliably extrapolate a healing event as as being a buff by it's amount without adding a lot of game knowledge to the parser and making it more brittle and error prone.

I don't think it's possible without a modification to server plugins to mark healing events as being overheals or not, and they don't receive much support these days.

Performance related rewards would need hacking to be policed much more extensively because items turn it into a profit making activity, and Valve's track record on TF2 hackers is dreadful. Participation rates are really the only safe metric for rewards given.

However I don't think you get special rewards for playing Pass Time or Mannpower modes and I imagine they view matchmaking in a similar way. It's just another way of playing the game and they don't want to skew participation unnaturally.

Fuck I've been missing this. Has he got onto Steve Jackson's Sorcery yet?

They work on engagement with their services. Logs.tf works as an advertisement for every competing system and platform, which is a huge disincentive for FaceIt to use it. The only way it makes sense is if they think users are going to abandon their platform because of the lack of logs.tf, which they aren't.

There is an obvious business case not to use an external service and force players to use their system.