CSGO Netsettings

CSGO Server - Einstellungen und wie sie das Spiel beeinflussen

Ein Server bestimmt, wie das Spiel läuft. Er bestimmt, wieviele Leute spielen dürfen, was sie spielen und wie lange und so weiter. Neben den Settings, mit denen man sozusagen tief in den Eingeweiden des Servers herumtweaken kann, gibt es einige Grundsätzliche Einstellungen, über die jeder nachdenken sollte.

Friendly Fire

mp_friendlyfire (default 0, 1 = an, 0 = aus)

Friendly Fire (FF) ist auf den meisten Servern aktiviert, d.h. die eigenen Schüsse machen bei Mitgliedern des eigenen Teams Schaden, und dies nicht ohne Grund. Friendly Fire fördert das Gameplay. Das klingt zunächst paradox, doch bei näherer Betrachtung wird der Grund hierfür schnell offensichtlich: Es mag zwar scheinbar das Spiel zu vereinfachen, wenn man FF deaktiviert, tatsächlich aber lässt die Spielqualität schnell deutlich nach, da das deaktivierte FF zu waghalsigen (und häufig völlig schwachsinnigen) Aktionen verleitet. Außerdem ist „FF off“ auf Dauer wirklich langweilig. Ab und zu ist es mal ein netter Gag. Wie gesagt: ab und zu. Auf ein gesetztes mp_friendlyfire sollte im motd des Servers hingewiesen werden.

Punish TK

mp_tkpunish 1 (default 1, 1 = an, 0 = aus)

mp_autokick 1 (default 1, 1 = an, 0 = aus)

Ist Friendly Fire aktiv, ist es möglich, Teamkiller automatisch zu bestrafen. Dies soll Teamkiller bändigen, die sich einen Spass daraus machen, das eigene Team umzunieten. Jedenfalls in der Theorie. In der Praxis hält dieses Feature kaum einen Teamkiller davon ab, immer wieder das eigene Team zu dezimieren. Im Gegenteil: Ist nur mp_tkpunish gesetzt (mp_autokick jedoch nicht) muss der Teamkiller im schlimmsten Fall nur eine Runde warten, bevor er wieder zuschlagen kann. Auf der anderen Seite können sich die Mitglieder des betroffenen Teams nicht gegen den Teamkiller wehren, da sie ja ebenfalls vom TKPunish betroffen werden, sobald sie den Teamkiller selbst erledigen.

Da es für die Spieler bei dem Standard-HLDS nicht möglich ist, einen Spieler vom Server per Mehrheitsbeschluss zu entfernen („einen Player voten“), kann in solchen Fällen nur ein Admin helfen. Einem Teamkiller fällt es also bei gesetztem mp_punishtk sogar leichter, dem Spiel dauerhaft zu schaden. Zur Problemlösung leistet mp_tkpunish jedoch so oder so keinen Beitrag, weshalb es überflüssig, wenn nicht sogar schädlich ist. Mit mp_autokick 1 kann man dieses Problem etwas entschärfen, jedoch fängt man sich so alle mit diesem Setting verbundenen Probleme ein, die die Spielbarkeit des Servers auch nicht gerade fördern. Zieht man einen versehentlichen TK in Betracht – und das kommt häufiger vor – dann ist ein solches PunishTK wenig sinnvoll: Der Schütze weiss ja, dass er was falsch gemacht hat und es war ja auch keine Absicht. Auf ein gesetztes mp_tkpunish sollte im motd des Servers hingewiesen werden.

Custom Sounds

Nicht das es schon nervig genug wäre, auf die zum Teil elendiglich laaaaaaangsaaaamen downloads der Map selbst warten zu müssen. Nein, es müssen unbedingt noch 12.486 Wav-Files hinterhergeschoben werden. Leute, denkt an Eure User. Nichts ist ätzender, als nur deshalb auf den Server warten zu müssen, weil irgendwelche völlig unnötigen Trallalla-Sounds mitgeschickt werden. Klar, es mag schon ziemlich kewl und ultra-1337 sein, wenn man zeigen kann, dass man auf seinem Server die Wavs aller Top-Ten Erfolge der letzten 84 Jahre lagert, aber: was nützt es dem Spiel? Den Download abzubrechen und sich einen anderen Server zu suchen geht meist schneller, als das Ende der Sounddownloads abzuwarten. Beschränkt Euch möglichst auf drei oder vier sehr(!) kleine(!) Custom-Sounds, das ist wirklich genug.

Die Anzahl der CustomSound-Aufrufe je Spieler pro Runde sollte stark begrenzt werden: es laufen genug gestörte Trottel da draussen rum, die es ober-geil finden, den anderen den Spass gründlich zu verderben, indem sie 5 Dutzend Mal am Stück einen dieser Customs aufrufen und so viele Spieler vertreiben. Durch das endlose Abspielen dieser Sounds werden alle anderen Spielgeräusche unhörbar, das Spiel für alle nahezu unspielbar.

Serverseitige Custom Sounds sind aus diesen Gründen problematisch und sollten mit Bedacht eingesetzt werden.

Auto Team Balancing

mp_autoteambalance (default 1, 0 = aus)

mp_limitteams (default 2, 0 = aus)

Ein ganz leidiges Thema. An und für sich ist dieses Auto Team Balancing (ATB) eine ganz feine Sache[tm]. Es soll dafür sorgen, dass die Teams von der Anzahl der Spieler her gleich stark bleiben. Jedenfalls ist das die Theorie.

Oft wird allerdings ignoriert, dass eine Unterlegenheit in der Spielerzahl eines Teams in keinem Fall bedeutet, dass dieses zahlenmäßig unterlegene Team zwingend auch das spielerisch unterlegene Team sein muss. Es empfiehlt sich, den Spielraum auf zwei oder drei Spieler Unterschied einzustellen, bevor das ATB regulierend eingreift, wenn man es denn überhaupt aktiviert.

Denn: Wird ein Spieler durch das ATB von einem Team in das andere verpflanzt, so wird ihm das NICHT vorher mitgeteilt, sondern der Betroffene muss in wenigen Augenblicken völlig umdenken. Es passiert oft, dass der Spieler viel zu spät bemerkt, dass er plötzlich auf der anderen Seite spielt. Außerdem wollen viele Spieler manche Teams einfach nicht spielen… Bei einem Team Limit von Null kann es unter Umständen passieren, dass ein Spieler ständig von einem Team ins andere hin und her geworfen wird und so jede Runde in einem anderen Team spielt.

Es ist bekannt, dass ein Umsetzen durch das ATB gerne zum Auftreten des „WeaponBuyBugs“ führt: Der Spieler bekommt die Waffen des Team angezeigt, in dem er nicht mehr spielt, kann aber diese nicht kaufen, da diese Waffen seinem aktuellem Team von der Engine nicht zur Verfügung gestellt werden. Der Spieler ist unfreiwillig auf solche Waffen beschränkt, die beiden Teams zur Verfügung stehen. Gleichzeitig wird oft das Radar ausgeschaltet. Sicherlich eine Herausforderung, doch ist dieser Bug sehr nervig und meistens nur durch erneutes Verbinden zum Server zu beheben.

Map Rotation

mp_maxrounds 0 (default 0, wenn =! 0 wird mp_timelimit aktiviert)

mp_timelimit 35 (default 35, 0 = endlos, Angabe in Minuten)

Die Auswahl der Maps, die ein Server anbietet, ist Geschmackssache. Solche Server, die 24/7 nur eine einzige Map anbieten haben genauso ihre Existenzberechtigung, wie solche, die ausschließlich Custom-Maps anbieten. Welche Map gespielt wird, kann über den Mapcycle vordefiniert werden. Sofern (weitestgehend) Einigkeit unter den Spielern herrscht kann jederzeit per voting eine Map aus diesem Mapcycle ausgewählt und geladen werden. Es ist jedoch sehr nervig, wenn die Maps ständig nach ein oder zwei Runden oder wenigen Minuten wechseln. Kaum ein Spieler wird das lange mitmachen. Nervig ist es aber auch, wenn das Voting durch Plugins / AddOns deaktiviert wurde und gleichzeitig die MapTime (Dauer zwischen zwei Wechseln der Map) auf „nahe unendlich“ eingestellt wird. Sagt den Spieleren die Map nicht zu, können sie in diesem Fall nur noch den Server wechseln, oder auf die Anwesenheit eines kompetenten Admins hoffen.

Bietet man einen Mapcycle an, der mehr als eine Map umfaßt, ist ein Mapchange frühestens alle 10 Minuten empfehlenswert, damit der Server bespielbar bleibt. Ideal ist ein Mapchange alle 25 – 35 Minuten. Regelmäßig in die Serverlogs zu schauen und diese nach von Spielern ausgelösten Mapchanges zu durchsuchen, kann helfen, die jeweiligen Settings für den eigenen Server den Spielerwünschen anzupassen.

Win Limit

mp_winlimit 0 (default 0, wenn =! 0 wird mp_timelimit aktiviert)

Genauso wie für Mindestlaufzeit der einzelnen Maps eine zu kurze Dauer nicht empfehlenswert ist, sollte ein zu niedriges Winlimit aus den selben Gründen vermieden werden. Wenn die Maps jeweils nur kurz gespielt werden sollen, dann sollten doch mindestens 3 Runden ermöglicht werden (absolutes Minimum), ab 5 Runden wird das Spiel für die Spieler als ausreichend abwechslungsreich empfunden. Auf ein gesetztes mp_winlimit sollte im motd des Servers hingewiesen werden.

C4 Timer

mp_c4timer 45 (default 45, min. 15, max. 90, jeweils Sekunden)

Die Länge des C4-Timers ist manchmal Spielentscheident. Ist er zu kurz, haben die CTs kaume eine Chance, die Bombe zu finden und diese zu entschärfen. Ist er zu lang, haben die Ts kaum eine Chance, die gelegte Bombe lange genug zu verteidigen. Geht man davon aus, dass nicht nur die besten Clans dauerhaft auf dem eigenen Server zocken, dann ist 35 Sekunden erfahrungsgemäß die empfohlene Richtzeit. 45 Sekunden kann als empfohlene Obergrenze angesehen werden. Auf den für mp_c4timer gesetzten Wert sollte im motd des Servers hingewiesen werden.

Rundenlänge

mp_roundtime 5 (default 5, min. 1, max. 9, jeweils Minuten)

Die Länge einer Runde trägt maßgeblich zur Dynamik und insgesamt zum Schwierigkeitsgrad einer Map bei. Je kürzer die Runde, desto häöher der Anspruch an die Spieler. Jedoch gibt es auch hier Grenzen, an denen man sich orientieren sollte. Runden, die länger als 5 Minuten dauern, werden meistens als zu lang empfunden, Runden, die kürzer sind, als 3 Minuten wirken zu hektisch und zu kurz. Es hat sich gezeigt, dass eine Rundenlänge von 3.5 Minuten von den meisten Spielern als angenehm empfunden wird. Sollten die Runden bewußt sehr kurz oder sehr lang eingestellt sein, sollte hierauf im motd des Servers hingewiesen werden.

BuyTime und FreezeTime

mp_buytime 1.5 (default 1.5, min. 0.5, kein max., jeweils Minuten)

mp_freezetime 6 (default: 6, 0 = aus, jeweils Sekunden)

mp_buytime legt fest, wie lange nach Beginn der Runde die Spieler Equipment einkaufen können. Je kürzer man diese Zeit einstellt, desto mehr setzt man die Spieler unter Druck und desto mehr erzwingt man das Verwenden sogenannter BuyScripte, die nicht ganz unumstritten sind. Warum will man die Spieler bei der Wahl ihres Equipments unnötig unter Druck setzen? Auf der anderen Seite kann ein zu lang eingestelltes mp_buytime den Teams einen unerwarteten (und ungewollten) Vorteil verschaffen und sollte deshalb vermieden werden. Eine Buytime von 1 bis 1.5 Minuten ist durchaus akzeptabel.

mp_freezetime definiert die Zeit am Anfang jeder Runde, während der sich die Spieler nicht bewegen können. Je kürzer man diese Zeit einstellt, desto mehr erzwingt man die Verwendung der eben erwähnten Buyscripte und benachteiligt so solche Spieler, die diese nicht verwenden wollen oder können. Eine zu lang eingestellte Freezetime wird wiederum als lästig empfunden, weshalb diese auch nicht zu lang eingestellt werden sollte. In der Praxis hat sich eine Freezetime zwischen 6 und 10 Sekunden bewährt.