20 replies to this topic

[Pazer]

Please require highlander games to have mp_highlander 1 and to KEEP mp_highlander set to 1 throughout the game.

[R.E.M.]

I'm not a programmer but I seem to recall a discussion with the developers where they said this was not possible or would be difficult to implement. I might be mistaken though.

[Pazer]

TF2Center already monitors the players continuously throughout the match to make sure no one leaves, it would be trivial to also check mp_highlander at the same time.

[Kenneth]

How is mp_highlander getting changed? Is it the server admin or something else?

[VoidWhisperer]

How is mp_highlander getting changed? Is it the server admin or something else?

 

kenneth, it is the server admin executing the command 'mp_highlander 0' either through console or through rcon. They could occasionally send the rcon command 'mp_highlander' and check the response to make sure it's set to 1, but doing that continuously would not work very well.

[R.E.M.]

TF2Center already monitors the players continuously throughout the match to make sure no one leaves, it would be trivial to also check mp_highlander at the same time.

 

What would you suggest should happen in the event that mp_highlander is set to 0? Assuming there is a way to change it back 1 but failing that your only other option really is to close a lobby and frankly I would prefer to play in a server with mp_highlander 0 than in no lobby at all.

[Pazer]

Please. Like I said earlier, tf2center already has the econ password for the server, so it has full control and ability to change cvars on the server, including mp_highlander.

[Kenneth]

This is fully technically possible, and I'm sure that it wouldn't be too hard to implement. However I don't think it will or should be.

 

If the server admin is running commands on their server that is their prerogative. If you believe that their administrative choices are questionable, it's best to not play on games run by them. At the end of the day it still is their server and they can do what they want with it.

 

However, malicious server administration is not welcome on TF2Center and would fall under the Inappropriate Behavior in the rules which is potentially a bannable offence. I'm not exactly sure how much effect mp_highlander has (I think class limits are still enforced by the class limit cvars?), but if it does ruin lobbies and waste peoples time than it can certainly be something we don't want.

 

In some cases it's way simpler to deal with a person, something that has been spread out to a wider group of admins, rather than wrangle with code written by a much smaller group of people trying to stabilize the codebase ready for a release, especially if the issue is only caused by one or two users. 

[R.E.M.]

However, malicious server administration is not welcome on TF2Center and would fall under the Inappropriate Behavior in the rules which is potentially a bannable offence. I'm not exactly sure how much effect mp_highlander has (I think class limits are still enforced by the class limit cvars?), but if it does ruin lobbies and waste peoples time than it can certainly be something we don't want.

 

Whilst I agree with everything you've said I think we need a clause in the rules that defines "Malicious server administration" because accidently setting mp_highlander 0 or forgetting to set it to 1 is not malicious. I think anyone who wanted to get someone punished would need to provide evidence to prove that someone was actually malicious in their actions.

 

Perhaps we could have a system kind of like VAC-secured on the valve server lists. So some servers can go through a certification process where the server owner agrees to certain conditions such as having the right configs installed, allowing TF2Center to change cvars and configs automatically to the right value. Then these servers can be bumped to the top of the list of lobbies and they'll have the TF2C logo on them so that people know that there'll be no issues with server configuration, cvars etc. This logo can also be used to indicate which servers are running off of stock TF2C servers when they are implemented. We could maybe have a seperate forum section kind of like bans/unbans section except it's an certify/uncertify where server owners apply to get TF2C accedited and people who have found that these servers have something dodgy going on (excessive pausing, use of sv cheats, changing of configs etc).

 

That way people will know which servers they can definatly trust and hopefully have an enjoyable lobby and some sembelance of peace of mind. What do you think?

Edited by R.E.M., 06 March 2014 - 01:21 PM.

[VoidWhisperer]

Generally what sets mp_highlander to 0 is one of the competitive configs, eg, the ugc hl config

[Kenneth]

So it's not someone going "rcon mp_highlander 0" in console? It's more like "rcon exec ugc_hl.cfg" if I get this correctly.

 

TF2Center does all the configs for you, there is no reason to have to do this. It will execute the ugc whitelist and set up all the various other cvars that you need. The thing is it's very specific. When does it stop being just for mp_highlander and we start having to do it for nearly all cvars?

 

While I can see a useful system here for detecting lobby abuse (oh look that lobby leader has turned on sv_cheats in 3 of his past 5 lobbies, let's have a chat) I think having an automated system is a bit onerous on server owners who in the end are paying for the server themselves and do have some right to be able to change the cvars whenever they want.

 

Best option is to ask the lobby leader to not exec any configs, and if it keeps happening, refer them onto the staff and admins.

[The Once and Future King]

So it's not someone going "rcon mp_highlander 0" in console? It's more like "rcon exec ugc_hl.cfg" if I get this correctly.

 

TF2Center does all the configs for you, there is no reason to have to do this. It will execute the ugc whitelist and set up all the various other cvars that you need.

 

I would add that due to the cp_steel bug (http://forums.tf2cen...c/176-cp-steel/) there would be an exception there where you need to run a ugc config in order to actually play both rounds of the lobby, though the admin could just rcon mp_highlander 1 after running the config and ultimately this shouldn't be a problem anyway since everyone in the server should have a specific class they are playing and if they are trying to double up they are the problem and not the server owner.

Edited by The Once and Future King, 06 March 2014 - 08:39 PM.

[Kenneth]

I'm curious why the ugc highlander configs don't have mp_highlander 1 set. But yes King, it's not such so cut and dry. Foxy did say they are looking at fixing the steel bug in due time fyi so that should help solve it.

[The Once and Future King]

I'm curious why the ugc highlander configs don't have mp_highlander 1 set. 

 

I've often wondered this myself, but in the three seasons I've played in the UGC it has never been part of the config.  

I think it's possible that part of the reason has to do with using subs during a match/scrim and having to change a player at a class mid game you would want them to be able to get into the game and on their class before the person they are replacing disconnects.

[kKaltUu]

The reason why mp_highlander 1 is discouraged, is because you set a hard class limit to 1.

Which has an unfortunate implication that you are forcing people to go to spectator if you need to switch classes or legitimate reasons.

What we have found is that setting your own class limits per class in your base config gives the players a better way to change things up, if problems arise.

Due to how TF2Center currently works, the site has no way to know if you have picked your actual class. Until then, there is no feasible way to blindly set mp_highlander to 1 (unless, of course, you want to increase the amount of fail lobbies).

 

The issue for cp_steel is that you need mp_maxrounds 2 (actually, that's the case for all stopwatch maps) to have a valid ABBA game. 

 

If you're interested in which commands are needed, check http://etf2l.org/rules/configs/

(We have several levels of command invocation: base -> HL -> gametype)

[R.E.M.]

The reason why mp_highlander 1 is discouraged, is because you set a hard class limit to 1.

Which has an unfortunate implication that you are forcing people to go to spectator if you need to switch classes or legitimate reasons.

 

I've never seen this cause a problem. Sure it's slightly more annoying than doing it with mp_highlander 0 but then it's probably less annoying than people offclassing and ruining lobbies as a result.

[TheMattgician]

Yeah, I don't think forcing people to go spec is as big a problem as allowing people to troll.

[Sec]

To get rid of trolling people we need some kind of way to report/mark them to get rid of them. mp_highlander is the least of your worries if people are being deliberately idiots.

 

One reason not to set mp_highlander is (if i remember correctly) so you can change spawn by quickly changing your class and back.

[kKaltUu]

To get rid of trolling people we need some kind of way to report/mark them to get rid of them. mp_highlander is the least of your worries if people are being deliberately idiots.

 

One reason not to set mp_highlander is (if i remember correctly) so you can change spawn by quickly changing your class and back.

You're able to use quickswitch for that:
 

//loadout switcher (back/forward spawn)
bind LEFTARROW "load_itempreset 0"
bind DOWNARROW "load_itempreset 1"
bind RIGHTARROW "load_itempreset 2"
bind UPARROW "load_itempreset 3"

And speaking from experience, people WILL try to play as a different class than expected (even happened 2 lobbies ago for me). Unless you can guarantee that you can check which class a player is playing, forcing class limits is disabled in competitive configs. 

[MasterNoob]

TF2Center already monitors the players continuously throughout the match to make sure no one leaves, it would be trivial to also check mp_highlander at the same time.

 

Either I want your application for the DEV team, or you refrain yourself from this kind of statements...