This kind of element trashes koth_king and Suijin, they're basically shooting galleries because everything on the point is vulnerable to every kind of spam. Enclosures around it are also a bad idea -- entering them without killing the other team is a death sentence, and they're usually large enough to split the map in half outside it.

I think the geography of Viaduct is one of the reasons it's been so lasting -- the point is uphill but not prominently so, while cliff plus the structures (plus the rock, I guess) provide some verticality for the attackers without completely overlooking the point. Compare to basically every other KotH map, where the point is usually level with or below all open areas. Lakeside is the only stock exception, and it's the only other stock KotH played competitively. (Badlands kinda as well, and it's run in 4s.) And Coalplant's buildings are to the side, so defenders can hold on them.

To expand on / justify it -- there were several minutes left and froyo was up several rounds and sitting on nR's second. They were expecting nR to try to push out for the last-ditch attempt to tie it up even though they'd need like 4 sub-one-minute rounds in a row, and were wondering in comms why they weren't pushing. The quote is them saying nR's basically written off the map and is probably discussing the next, so they should do that, too.

Host servers on VPS or dedicated with command-line access
Install OpenVPN on servers
Connect servers to a VPN
Block Source ports on the servers from access except from the VPN's IP range
Connect players/casters to the VPN
Give out the VPN server IP
Now even if someone looks up their game info in Steam, they should only see a server IP from the VPN range

Not 100% sure this works because I've never tried it.

At that point you're basically doing the opposite of power creep, which can be a lot worse. Long time-to-kill all around can be fun in some games, but given that players in TF2 move quickly and have to reload a lot it probably wouldn't work out very well.

Good example of a (MOBA) game where it did somewhat work is Demigod -- focus of team fights was on kinda "dancing" with your positioning while doing the usual stuff like focusing down weaker players -- but in that you can output damage pretty constantly and don't have many options for heals, and players don't move quickly. But an inherent problem with the approach, that was present in that game too, is it makes big health pools more important than anything else.

Not sure if a bug or intended, but overtime on Powerhouse never ends, even when capture progress on mid fully rolls back. If the round timer runs out, the announcer says overtime, but you keep playing until someone caps last.

You can test this by enabling tournament mode and then using mp_restartgame 1 or mp_restartgame_immediate 1... tournament mode stays on, but the round timer starts and map time resets, and it will act as if it's the first round. No freezetime regardless of what tf_player_movement_restart_freeze is set to.

It's pretty clearly a bug related to the Battalion's Backup issue.

Yeah. I'm worried they'll see that, say, running two medics works too well and nerf medic as a class, or something like that. Or a team of six snipers gets wrecked too often, so they buff sniper to make running six snipers viable.

I use Google Authenticator on my phone for Gmail authentication, and with Steam Guard sending emails to that account it basically means access to my phone is needed for Steam account access from a new device.

There are desktop application implementations that support Google Authenticator if you don't use a phone. See links:

https://github.com/cdmackie/winauth
http://superuser.com/questions/462478/is-there-a-google-authenticator-desktop-client

You are of course still vulnerable to keyloggers with a PC-only approach (though Authenticator generates time-based codes from a QR code scanned at setup, so it's probably still effective), and any kind of remote control would still leave you vulnerable if you are auto-logged-in on your usual device (which is the default for Steam Guard and Gmail), but it's at least an extra obstacle that could deter anyone simply mass-compromising accounts.

Make sure you're not reusing your email or Steam passwords anywhere else; login credentials can be logged by malicious websites, or stored in plaintext/reversible encrypted form and stolen from incompetent ones. Your email is usually the key to recovering any other accounts, so have separate, unique passwords for your email and for any financial services you use, and limit re-use to accounts that don't unlock other accounts or screw you over personally (though ideally, don't reuse at all).

gg ugc; good thing I never changed the auto-genned one

Can't even think of any common software packages that don't hash or at least encrypt; even shitty web forum software from the early 2000s did an unsalted MD5 hash

Literally the only reason to store plaintext passwords is as a deliberate choice by a rouge database admin so they can try the passwords on people's email addresses

How do these upgrades actually work? If you upgrade and later want to reinstall do you need to use your old version discs for verification or a full install first? If you own a retail copy with multiple licenses, does the free upgrade apply to those, and what happens when you go to use one on another system?

"hud_damagemeter" = "1" ( def. "0" ) client
 cheat
 - Display damage-per-second information in the lower right corner of the screen.

"hud_damagemeter_ooctimer" = "1"
 client
 - How many seconds after the last damage event before we consider the player out of combat.

"hud_damagemeter_period" = "0" client
 - When set to zero, average damage-per-second across all recent damage events, otherwise average damage across defined period (number of seconds).

Could be useful to enable on MGE servers for ammomod or in bot training maps (say newbots with the bot's regen turned on) -- would be good for stickies/rockets/pistol aim.

I've occasionally seen bans pop up on people that go away days/weeks later, so it does happen. Also there have been a few instances of mass false banning. One with CoD comes to mind where they updated the game but forgot to update some file hashes or the like on VAC, so it thought everyone had modified files and banned them. If you actually didn't do anything, it's worth contacting them, but removal of these bans if likely automatic / based on fixing the system itself anyway.

There are also some non-hack things that trigger "rightful" bans that are not removed. For instance, some shader mod for HL2 that replaces DLLs can trigger source bans if not removed properly (or maybe if installed to the wrong game? Since HL2 doesn't have MP and HL2:DM is probably in a separate folder...).

Based on my tests, having tracers enabled prevents the bug from occuring, or at least makes it much more unlikely compared to hiding them.

I don't know if the crashing is related to the bug -- I assumed the crashes were from stopping the demo recording too quickly or something.

What you've said about "LinkedList overflow (exhausted index range)" message indicates, to me, several things:

1) They are storing references to sprites to draw in a linked list (a structure in memory which is, essentially, a list of things from which you can add/remove to/from the list at any point) -- I assume reason to use this structure would be to provide the capability of removing arbitrary sprites from memory as they are removed from the world (for instance, by colliding with a wall).

2) This list has an arbitrarily-limited capacity, as defined by the "index range", probably for memory usage or other performance reasons.

3) Sprites are not being removed from this list at an appropriate rate, causing it to fill up.

I know that using weird values for viewmodel_fov can cause tracers to appear in strange locations or move at weird angles. If this console message is, in fact, indicative of the problem, rather than occuring coincidentally, or being independently caused by the same issue that causes the disappearance bug, then perhaps the tracers are not being properly placed in the world when extreme FOV values are used, and are thus not colliding with walls and such and being removed in a timely manner? I'd assume this would have always been the case, but maybe they increased some kind of timeout or max range value, causing tracer sprites to pile up when they previously did not?

I don't see why this would make viewmodel_fov 360 trigger the bug upon the first shot while viewmodel_fov 0.001 requires multiple though, unless it's just some subtle variance in the angles some of them fly off at.

Does anyone get this problem using viewmodels, or using normal FOV values when they're disabled, or using viewmodel_fov 0?

"Do the coding for my idea and if it works out there might be income to share" is something every software dev knows to avoid like the plague...

Anyone capable of building a site like that can pretty easily find someone willing to give them a salary for the same level of work.