I'm not calling for bans, or anything like that. I don't know whether Samski should be banned at all, and as Twiikuu was saying, a lot of that depends on what happens from here.

I just hate to see people bring up pred/degu with "but they couldn't have done anything better, so unfair" which is blatantly false. I don't even get the obsession, degu's already unbanned afaik and people still constantly bring it up every time people react to other players being toxic. I don't mind degu, and for that reason I hope he's not going to do the same shit again, but it's lying to look back and say they couldn't have done anything better.

Degu's apology was essentially "I wasn't serious, and therefore everyone else is wrong for reacting badly" and iirc pred never tried to apologize or even take the situation seriously. Their bans did take that into account.

Because being worried about ones' safety is the #1 priority in all of this?

computer science, with specialization in video game programming

economics is the scientific study of how things affect the overall economy, business is about how a business is run. There's overlap, but the direction they go in is very different.

I can recommend cs, but if your main motivation is that you want to run / manage a business you should be looking at business (but if it's that you just want good money, I've known more people with business degrees go back to study cs than the other way around).

That's called key wobble. It usually either the switch type, or how snug the keycaps fit. If it's the keycaps it can be fixed with some scotch tape generally.

No one will be able to make a hud more suited for you than you yourself. Even if you don't make something perfect, there's a satisfaction in having made it your own. And it's a neat skill in general (I've mentioned it in job interviews and it helped getting into the gamedev industry), on top of just being fun.

Here are some resources that should help:
http://doodlesstuff.com/?p=tf2hud
https://www.youtube.com/playlist?list=PL5eNrB8RrXXuV3P1nv6NnwF-tCL_KnJIs
http://www.teamfortress.tv/19073/hud-editing-short-questions-quick-answers
Though once you get started, looking at how other huds do things, and experimenting on your own will get you far.

Most hud devs would be happy to point you in the right direction, and plenty would be willing to answer any direct questions. But unless it's really easy work (taking stuff from one hud and putting it into another, for example) you'll be unlikely to find someone willing to make it for you, even if you offer to pay.

So on the topic of dashboarddimmer, I've tried my hand at it and currently this is what I've got. It seems to be working for me, but I've only spent a short amount of time with it so your mileage may vary, and it might not be the best method either.

In mainmenuoverride:

	"DashboardDimmer"
	{
		"wide" "0"
		"tall" "0"
	}

In your autoexec.cfg / your hud's valve.rc:

// remove dimmer
wait 5; showconsole; wait; toggle mat_antialias; hideconsole

The issue is that dashboarddimmer is loaded after the fact when it appears for the first time (after which is just changes its alpha value), and uses its own values from code instead of the values in mainmenuoverride. So this solution is to:

1. open the console, which also loads dashboarddimmer for some reason
   
2. reload the main menu by changing the mat_antialias value
   
3. from the reload, apply wide and tall 0 to dashboarddimmer
   
4. close the console because it did its job

The restrictions are:

• toggling mat_antialias will change your mat_antialias setting, obviously
  
• changing mat_antialias on start can cause crashes for some people
  
• the reload probably adds extra load times when starting tf2
  
• the first wait might be too short for some people, 5 worked for me but if it doesn't then bump that number up

e: you can fix the mat_antialias setting changing by using this instead:

wait 5; showconsole; wait; incrementvar mat_antialias -100 100 1; hideconsole; wait 5; incrementvar mat_antialias -100 100 -1

However this will add even more load time (though reloading the main menu doesn't take too long) and still keep the other issues.

What about anything twiggy suggested:

Or even just a retroactively applied "if a group of players wins 3 or so seasons together, they can't play on the same team" ruling that effectively does the exact same as you currently have.

And why wait until the future to do better? A lot of people have complaints with the core concept, but you already have direct advice and constructive feedback you can work with right now, that as far as I can see you've completely ignored. You don't need to get the ideal solution right off the bat, but even just setting a precedent for "these guys are too good, so seemingly on a whim here's a rule that only applies to them" is problematic.

It's one thing to list off reasons why you don't listen to the community at all (even if I think it's missing the entire point of the "ban pred & degu" thread to bring it up here), but you can't complain about how you just run into arguments here when you yourself are only willing to argue. I want to say it's good that you recognize your decisions need improvement, but as it stands your posts are coming off more like "I'm going to go through with this no matter what, but I also don't want to hear any criticism of this rule that I admit is bad" rather than genuinely trying to discuss the best course of action.

I don't know how it is on other forums, but we have no clue what's happening behind the scenes beyond what you tell us. And we haven't been told anything assuring beyond "trust me to do the right thing next season", which considering RGL's reputation here isn't a good fit. I don't mean this to start arguments or anything (if you want to focus on anything in this post please focus on twiggy's suggestions), just to say that we'll both agree your approach isn't working.

computer science with specialization in video game programming
gotta be different somehow

Yeah the bgcolor_override is a bit of a red herring. The animations you're looking for is:

//magnum hud chat bg remover
//make sure that you also have some chatanim.cfg because this needs it p much
event SetHudChatAlpha
{
	Animate HudChat bgcolor "0 0 0 0" linear 0.0 0.0
	Animate HudChat bgcolor "0 0 0 0" linear 0.0 100.0
	Animate HudChatHistory bgcolor "0 0 0 0" linear 0.0 0.0
	Animate HudChatHistory bgcolor "0 0 0 0" linear 0.0 100.0

	RunEvent SetHudChatAlphaLoop 0.1
}
event SetHudChatAlphaLoop
{
	RunEvent SetHudChatAlpha 0.1
}

That needs to be manually triggered though. There are multiple ways to trigger it (I don't know which colly did) but this is the most reliable: add this to your MenuOpen event:

event MenuOpen
{
	...
	RunEvent SetHudChatAlpha 0.0
}

And add this line to your class cfg's:

voice_menu_1; slot10

The MenuOpen and class cfg part can be used for any animation you want to trigger automatically and immediately. Removing the default chat bg is one of the better examples of animation locking, but the same idea can be applied to most things that you can't seem to remove or edit otherwise.

chat_english.txt is more reliable, since it won't break during updates (or at least far less frequently than tf_english.txt). It should work fine, as long as it's not being overridden by another mod in custom or something.

Can be done pretty easily:

// press + to increase sens, - to decrease sens
bind = "incrementvar sensitivity 0 100000 0.1"
bind - "incrementvar sensitivity 0 100000 -0.1"

Sorry dolore, good effort but incrementvar saves some work

What are your current plans, and what are you going to contribute? It sounds like "here's a general idea, now I just need people who know how to do the rest" as it stands.

Not to discourage and don't mean to sound like an ass, because I'm sure there is an interest in an old maps cup. There's plenty of maps people are nostalgic about, or just so different that players don't experience anything like them now. But running an event smoothly is not easy and requires strong organization, and asking for people to essentially run it themselves isn't putting your best foot forward.

https://github.com/mastercoms/mastercomfig/blob/release/docs/README.md#installation

If your fps is still too bad to play, you will need to buy a new computer.

It's hard to get a script for that because scripts only do things when you press keys, and unscoping can happen in a lot of different ways regardless of keybinds. It's also inconsistent to check if you have your primary out, but can be done (the same way a crosshair switcher script works).

Generally speaking though (not including checking for primary):
Sniper.cfg:

alias xhUnscoped "crosshair-settings-here"
alias xhScoped "crosshair-settings-here"
alias scopedToggle "scopedToggleOn"
alias scopedToggleOn "xhScoped; alias scopedToggle scopedToggleOff"
alias scopedToggleOff "xhUnscoped; alias scopedToggle scopedToggleOn"
alias +jumpup "+jump; +moveup"
alias -jumpup "-jump; -moveup"

bind mouse1 "+attack; spec_next; scopedToggleOff"
bind mouse2 "+attack2; spec_prev; scopedToggle"
bind space "+jumpup; spec_mode; scopedToggleOff"

All other class cfg's:

bind mouse1 "+attack"
bind mouse2 "+attack2"
bind space "+jump"

e: ninja'd, but same idea in both, not sure if hamaham's is functional though

Belgium legally considers lootboxes (in tf2's case crates but still meeting the definition) a form of gambling iirc. Especially because of how easy it is for minors to get into crates, it's pretty necessary for Valve to cut that off for legal reasons.

Just a few points:

It doesn't really change much for response time -- the difference in the actual mechanisms would be in the nanoseconds (assuming the optical switches use photodiodes, other options would definitely be slower) and different actuation points hardly matter as it is. The majority of input lag is between the keyboard controller and the computer registering inputs, and (non-analog) optical keyboards work the exact same way as normal for that. And solving debounce doesn't matter either outside of key chatter, unless you're a superhuman that can press a single key over 200 times a second.

Optical switches aren't necessarily smoother. It's the contact between the stem, housing, and spring that's the issue generally (and also where lubing is recommended). Smooth non-contact switch types (xmit's hall effect switches for example) are comparable to loose traditional switches (such as gateron), and it comes at the cost of more wobble in both cases.

I can't speak about longevity, but a concern is that you can't replace the LEDs if they die eventually. With a mechanical switch you can usually pop them open and bend the contact leaf a bit, or replace the switch entirely, but you usually won't have to anyway because switches from the 80s are working fine. For an optical switches it all depends on how cheap the company wants to get with their LEDs.

All that said, I fucking love my analog keyboard (aimpad r5). Optical switches aren't bad at all, they're just not the clear better-in-every-way upgrade that marketing would suggest--other than for analog capabilities, which imo is a huge plus (that worst case, you can just disable or ignore, so there's no reason not to have it). For someone seriously into mechs there are advantages for traditional switches (wider variety, custom builds) but if you're just looking for a nice keyboard either is fine.

General rule is that they support any game that lets you use mouse + keyboard + controller simultaneously, since they just simulate a generic controller anyway. Some notable engines don't support it (skyrim/fallout doesn't) but others work fine (source engine works great) even though their developers never had to go out of their way to support it.

Unfortunately it's all still pretty niche and uncommon. The wooting one is available but flaretech switches are horribly inconsistent and have a very non-linear analog response. Aimpad's is a lot better, but the first board it'll be publicly available on (Coolermaster MK851) is huge which isn't to most people's tastes (but I hope it does really well, because putting it on more keyboards would be great). There's a few other options floating around (there was an analog topre prototype) but there's not a whole lot of options.