4  Konfiguration

4.1  Admin Mod einrichten (adminmod.cfg)

Dieser Abschnitt beschäftigt sich mit den Grundeinstellungen von Adminmod. Diese findet man in der adminmod.cfg („addons/adminmod/config“). Sie sollte stets aus der server.cfg heraus ausgeführt werden („exec addons/adminmod/config/adminmod.cfg“). Im Weiteren sollen die einzelnen Einstellungen (CVars) vorgestellt werden. Variablen, die nicht in der Standard adminmod.cfg stehen, können einfach ergänzt werden.

Änderungen an der adminmod.cfg werden nicht automatisch ausgeführt. In der Grundeinstellung des Half-Life Servers wird die Datei nur beim Starten des Servers geladen, da auch die server.cfg nur zu diesem Zeitpunkt geladen wird. Nur wenn man die Variable mapchangecfgfile auf „server.cfg“ oder „addons/adminmod/config/adminmod.cfg“ stellt, werden die Änderungen beim Mapwechsel übernommen. Alternativ kann man nach einer Änderung auch einfach „exec addons/adminmod/config/adminmod.cfg“ in der Serverconsole eingeben.

4.1.1  admin_balance_teams

admin_balance_teams <#>

Diese Variable wird vom TFC-Plugin verwendet. Bei einer zahlenmäßigen Überlegenheit des gegnerischen Teams wird diese automatisch ausgeglichen, indem einige Spieler ins gegnerische Team verschoben werden. Die Zahl hinter der CVar gibt den Überhang an Spielern an, ab der das Plugin aktiv wird. Die Standardeinstellung ist 0 (deaktiviert). Für CS hat diese Variable auf Grund der bereits integrierten Lösung keine Bedeutung.

 
Beispiel:
admin_balance_teams 3

Sobald ein Team 3 Spieler mehr hat als das andere, werden die Teams ausgeglichen.

4.1.2  admin_bot_protection

admin_bot_protection <#>

Hat man Bots auf seinem Server, so sollte man ggf. die Variable auf 1 setzen. Einige Bots vertragen keine Serverbefehle wie beispielweise „kick“. Diese Einstellung verhindert, dass ein solcher Befehl auf den Bot ausgeführt werden kann. Man läuft also Gefahr, einen Servercrash zu erleiden. Einfach ausprobieren, ob der Bot stabil mit der eigenen Admin Mod Installation läuft. Standardmäßig ist die 0 voreingestellt (deaktiviert).

 
Beispiel:
admin_bot_protection 1

Die Botprotection ist mit dieser Einstellung aktiviert.

4.1.3  admin_connect_msg

admin_connect_msg “<string>”

Diese Meldung wird dem jeweiligen Spieler nach dem Spieleinstieg auf den Server angezeigt (plugin_message).

Mit admin_connect_msg 0 lässt sich die Nachricht komplett abschalten.

 
Beispiel:
admin_connect_msg “Welcome to the pleasuredome...”

60 Sekunden nach dem Spieleinstieg wird in der Mitte des Bildschirms „Welcome to the pleasuredome...“ angezeigt.

4.1.4  admin_cs_restrict

admin_cs_restrict <#>

Diese Variable wird vom CS-Plugin verwendet. Wenn auf 1 gesetzt, ist es möglich den Kauf von bestimmten Waffen (z.B. AWM oder Schild) oder Equipment zu verbieten. Es ist 0 voreingestellt.

 
Beispiel:
admin_cs_restrict 1

Das Verbieten von Waffen und Equipment ist damit aktiviert.

4.1.5  admin_debug

admin_debug <#>

Eigentlich ist diese Variable nur für Scripter interessant, die ihre Plugins debuggen wollen. Für den Normalbetrieb ist es nicht zu empfehlen, daher sollte der Wert auf 0 belassen werden. Für das Debuggen kann man den Wert von 1 bis 4 erhöhen. Damit erhöht sich auch die Informationstiefe und nicht unerheblich die Logfilegröße!! Mehr Informationen zum Spielerconnect erhält man hingegen mit admin_devel.

 
Beispiel:
admin_debug 4

Admin Mod lässt sich mit dieser Einstellung tief in die Karten schauen. Der erfahrene Scripter kann mit den geloggten Ausgaben meist schnell erkennen, wo der Bug im Plugin liegt. Standard: 0

4.1.6  admin_devel

admin_devel <#>

Diese Variable gibt einige zumeist grundlegende Informationen zum Spielerconnect in den Logs aus. Außer für Programmierer an der Admin Mod Bibliothek ist diese Variable uninteressant und sollte auf der Standardeinstellung 0 belassen werden. Mögliche Werte sind 0 bis 3 (wie bei admin_debug: je größer die Zahl, desto mehr Information).

 
Beispiel:
admin_devel 3

Gibt alle Informationen zum Spielerconnect aus.

4.1.7  admin_fun_mode

admin_fun_mode <#>

Man kann mit dieser Variable erlauben den Glow- bzw. Disco-Modus zu verwenden.

Wird für das Fun-Plugin benötigt. Die Variable kann man auch temporär mit dem Befehl admin_fun verstellen. Die Glow-Funktion möchten die meisten Serverbetreiber nicht missen, daher sollte diese Einstellung auf 1 gestellt werden. Standard: 0

 
Beispiel:
admin_fun_mode 1

Der Gloweffekt wird mit dieser Einstellung freigeschaltet.

4.1.8  admin_fx

admin_fx <#>

Habt Ihr Euch schon immer gefragt, warum auf anderen Servern geslayte Spieler mit einem Donnerschlag explodieren? Setzt mal diese Variable auf 1. Dann tun sie das auch auf Eurem Server. Standard: 0

 
Beispiel:
admin_fx 1

Diese Einstellung muss vorgenommen werden, damit die „Nachricht“ des Admins stilvoll unterstrichen wird.

4.1.9  admin_gag_name

admin_gag_name <#>

De-/aktiviert die Möglichkeit zur Veränderung des eigenen Namens, wenn man geknebelt (gag) wurde. Einige Spieler versuchen über die Änderung des Namens trotz Knebelung weiter zu kommunizieren, indem sie ihre Nachrichten in ihren Namen schreiben. (plugin_retribution) Voreinstellung: 0

 
Beispiel:
admin_gag_name 1

Diese Einstellung verhindert, dass ein geknebelter Spieler über seinen Namen weiterkommunizieren kann.

4.1.10  admin_gag_sayteam

admin_gag_sayteam <#>

Wenn auf 1 gesetzt, verhindert diese Variable, dass geknebelte Spieler den Teamchat benutzen können. (plugin_retribution) Die Voreinstellung ist 0.

 
Beispiel:
admin_gag_sayteam 1

Ein geknebelter Spieler kann neben dem allgemeinen Chat auch den Teamchat nicht mehr benutzen.

4.1.11  admin_highlander

admin_highlander <#>

Es kann nur einen geben! Ja richtig, es gibt bei 1 immer nur EINEN Admin auf dem Server und zwar den mit den mit der höchsten Rechtesumme.

Ein “kleinerer” Admin fällt auf das in default_access festgelegte Level ab, sobald ein “höherer” Admin auf den Server kommt.

Der Hauptadmin soll natürlich über allen stehen. Trotzdem möchte man die Rechte einiger Admins nicht beschneiden und räumt Ihnen den selben Accesslevel ein. Dann wird es mit der Highländervergabe problematisch. Eine einfache Lösung bietet sich mit dem nichtgenutzten Accesslevel 131072 an. Dieses addiert man zum Accesslevel des Hauptadmins hinzu. Anschließend ist der Hauptadmin immer Highlander, die Rechte 65336 stehen aber auch den Unteradmins zur Verfügung, während der Hauptadmin offline ist. Default: 0

 
Beispiel:
admin_highlander 1

Mit dieser Einstellung wird derjenige alleiniger Admin, der den höchsten Accesslevel besitzt.

4.1.12  admin_ignore_immunity

admin_ignore_immunity <#>

Eure Admins laufen hin und wieder Amok? Ihr habt Ihnen in der users.ini aber leider Immunität verliehen? Das kann man auch allgemein ausschalten, in dem man diesen Wert auf 1 setzt. Die Rache ist Euer, aber Vorsicht, Ihr habt auch keine Immunität mehr! Die Standardeinstellung ist 0 und sollte das auch bleiben.

 
Beispiel:
admin_ignore_immunity 1

Dies setzt die Admin-Immunität außer Kraft.

4.1.13  admin_plugin_file

admin_plugin_file “<string>”

Der Vorgabewert sollte nur verändert werden, wenn die Datei an einer völlig anderen Stelle als vorgesehen installiert ist. Die meisten Serveradmins sollten die Voreinstellung “addons/adminmod/config/plugin.ini” unbedingt stehen lassen. Steht in admin_plugin_file ein Verzeichnis (z.B. „addons/adminmod/scripts“ durchsucht Admin Mod dieses Verzeichnis nach Dateien mit der Endung „.amx“ und versucht diese zu laden. Alle nicht benötigten Plugins sind dementsprechend zu löschen oder umzubenennen (z.B. „*.amx.noload“).

 
Beispiel:
admin_plugin_file “plugin.ini”

In diesem Fall wird die plugin.ini im Mod-Verzeichnis erwartet. Mehr zu dieser Datei im Kapitel Plugins installieren (plugin.ini).

4.1.14  admin_reconnect_timeout

admin_reconnect_timeout <#>

Gibt die Zeit (in Sekunden) an, wie lang das Passwort eines Spielers gültig ist, so dass er bei gleicher IP und Namen ohne Neuangabe wieder connecten kann. Den Wert höher als 300 zu setzen, ist ein Sicherheitsrisiko. Ein Wert größer als 0 wird für den Mapwechsel benötigt, ansonsten werden die Admins ihre Rechte verlieren und u.U. vom Server geworfen. Standardeinstellung: 300.

 
Beispiel:
admin_reconnect_timeout 60

Dies setzt die Zeit für die Rückkehr eines Admins auf 60 Sekunden, innerhalb der er sich nicht erneut authentifizieren muss.

4.1.15  admin_reject_msg

admin_reject_msg “<string>”

Dieser Text wird zurückgegeben, wenn man ohne Berechtigung versucht Befehle auszuführen.

 
Beispiel:
admin_reject_msg “Was wird das? Das darfst Du nicht!”

4.1.16  admin_repeat_freq

admin_repeat_freq <#>

Der Wert für admin_repeat_freq gibt in Sekunden an, in welchem Abstand der Text in admin_repeat_msg ausgegeben wird. Bei einem Wert kleiner als 15 startet der Timer beim Mapstart nicht. Eine Änderung des Werts wird erst nach einem Mapchange aktiv wird. (plugin_message) Default: 600.

 
Beispiel:
admin_repeat_freq 600

Die unter admin_repeat_msg hinterlegte Nachricht wird alle 10 Minuten (600 Sekunden) wiederholt.

4.1.17  admin_repeat_msg

admin_repeat_msg “<string>”

Gibt den Text an, der als Centersay wiederholt werden soll. Der zeitliche Abstand wird in admin_repeat_freq festgelegt. Setzt man den Wert auf 0, wird keine Nachricht ausgegeben. Solange admin_repeat_freq beim Mapstart nicht kleiner als 15 ist, kann die Nachricht jederzeit wieder aktiviert werden. (plugin_message) Default: „This server is using Admin Mod“

 
Beispiel:
admin_repeat_msg “This server is using^nAdmin Mod”

Dies bringt die Meldung „This server is using Admin Mod“ als Centersay auf den Bildschirm. Allerdings erscheint Admin Mod in der zweiten Zeile, da „^n“ ein Zeilenumbruch ist.

4.1.18  admin_quiet

admin_quiet <#>

Hiermit wird festgelegt, ob und wie Admin Mod zurückmelden soll, dass ein Befehl ausgeführt wurde. 0 bedeutet, dass folgende Nachricht erscheint:
ADMIN Command: <Player> used <command>.
Bei 1 erscheint nur der Befehl und 2 unterdrückt jegliche Ausgabe. Einige Befehle übergehen aber selbst admin_quiet 2 (z.B. admin_godmode). Voreinstellung ist 0.

 
Beispiel:
admin_quiet 2

Die meisten Serveradmins werden diese Einstellung bevorzugen, bei der nur die Cheat-Möglichkeiten offengelegt werden.

4.1.19  admin_vault_file

admin_vault_file “<string>”

Das Vaultfile speichert Einstellungen von Customplugins, sollte also definiert werden. Der Wert “addons/adminmod/config/vault.ini” ist in der Regel nicht zu verändern.

 
Beispiel:
admin_vault_file “vault.ini”

In diesem Fall wird die vault.ini im Mod-Verzeichnis erwartet. Mehr zu dieser Datei im Kapitel Pluginspezifische Einstellungen (vault.ini).

4.1.20  admin_mod_version

admin_mod_version “<string>”

Setzt die Admin Mod-Version. Es macht keinen Sinn diesen Wert zu ändern, aber der Vollständigkeit halber soll die Variable hier erwähnt werden. Händische Änderungen werden von Admin Mod überschrieben.

4.1.21  admin_vote_autostart

admin_vote_autostart <#>

Für das Plugin hldsld_mapvote wird hier festgelegt, ob 5 Minuten vor Mapchange automatisch ein Mapvote gestartet werden soll. 1 aktiviert die Funktion, 0 deaktiviert sie. Default: 0.

 
Beispiel:
admin_vote_autostart 1

Hiermit ist der Vote vor dem Mapwechsel aktiviert worden.

4.1.22  admin_vote_echo

admin_vote_echo <#>

Setzt man die Variable auf 1, wird angezeigt, welcher Spieler welche Option bei einem Vote gewählt hat. Bei 0 wird nur das Endergebnis präsentiert.

 
Beispiel:
admin_vote_autostart 1

Zeigt die Entscheidung jedes einzelnen Spielers beim Vote an.

4.1.23  admin_vote_freq

admin_vote_freq <#>

Hiermit wird festgelegt wieviele Sekunden nach einem Mapchange bzw. dem letzten Vote mittels Plugin hldsld_mapvote vergangen sein müssen, bis ein neuer durchgeführt werden darf. Es ist zu beachten, dass dieser Wert nicht für andere Votes gilt. (siehe dazu vote_freq) Standardwert: 600.

 
Beispiel:
admin_vote_freq 300

Diese Einstellung erlaubt einen Mapvote alle 5 Minuten (300 Sekunden).

4.1.24  admin_vote_maxextend

admin_vote_maxextend <#>

Legt fest, wie oft eine Map mittels Plugin hldsld_mapvote um 30 Minuten verlängert werden darf. Standardmäßig darf sie das nicht (Einstellung: 0).

 
Beispiel:
admin_vote_maxextend 1

Dies bedeutet, dass die Map einmal um 30 Minuten im Mapvote verlängert werden darf.

4.1.25  admin_vote_ratio

admin_vote_ratio <#>

Mit dieser Variablen wird festgelegt, wieviel Prozent der Spieler für einen Mapwechsel stimmen müssen, damit dieser durchgeführt wird (Plugin hldsld_mapvote). Standardwert: 60.

 
Beispiel:
admin_vote_ratio 50

Bei einem Wert von 50 und 10 Spielern auf dem Server müssen 5 für den Mapwechsel stimmen.

4.1.26  allow_client_exec

allow_client_exec <#>

Plugins können Befehle beim Client ausführen, wenn diese Variable auf 1 gesetzt wird (Standard: 0). Zum Schutz des Clients sind nicht alle Befehle ausführbar. Außerdem wird beim Einloggen eine Nachricht angegeben, dass das Ausführen von Befehlen auf diesem Server erlaubt ist.

Diese Meldung lässt sich weder entfernen noch editieren. Sie dient der Information des Clients, dass theoretisch die Möglichkeit eines böswilligen Eingriffs seitens eines Admins oder Plugins besteht! Leider gibt es immer noch genug “Admins”, die ihre Aktionen nicht reflektieren. Dabei bietet Admin Mod doch so viele andere Möglichkeiten der Bestrafung!

 
Beispiel:
allow_client_exec 1

Viele Plugins funktionieren ohne die Aktivierung dieser Funktion nicht. Es empfiehlt sich daher diese Einstellung auf 1 zu setzen.

4.1.27  ami_sv_maxplayers

ami_sv_maxplayers <#>

Gibt die ursprüngliche Maxplayereinstellung zurück. Diese Variable sollte nicht manuell gesetzt werden, hat nur informativen Charakter für Serverbrowser. Sie dient Serverbrowsern zum erkennen, wieviele Slots für die Admins reserviert sind.

4.1.28  amv_anti_cheat_options

amv_anti_cheat_options “<string>”

Admin Mod gibt Möglichkeiten an die Hand zwei bestimmte Cheats zu erkennen und Gegenmaßnahmen zu ergreifen.

1. Name Crash Cheat (interessant nur bis HL1108, inzwischen von Valve gefixt)

Der Wert besteht stets aus einer Zeichenfolge (hier nc) und einer Zahl:

“nc0” bedeutet, dass Admin Mod nichts unternimmt (Default)
“nc1” kickt den Spieler vom Server “nc2” kickt den Spieler vom Server und bannt ihn für 24 h

2. Spectator Cheat (vermutlich auch nicht mehr aktuell)

“sp0” bedeutet, dass Admin Mod nichts unternimmt (Default)
“sp1” bannt den Spieler vom Server

Will man beide Optionen gleichzeitig nutzen, so ist als Trennzeichen der Doppelpunkt zu verwenden (z.B. “nc1:sp1”)

 
Beispiel:
amv_anti_cheat_options “nc0:sp1”

Dies aktiviert die Spectator Cheat Erkennung, deaktiviert jedoch die Name Crash Cheat Erkennung.

4.1.29  amv_default_config_dir

amv_default_config_dir “<string>”

Beinhaltet den Standardpfad der Admin Mod-Installation. Dieser Wert ist zu ändern, falls nicht der Standardpfad benutzt wird (Standard ist “addons/adminmod/config”). Diese Einstellung ist für einige Custom-Plugins relevant.

 
Beispiel:
amv_default_config_dir “addons/adminmodtest/config”

In diesem Beispiel wird erwartet, dass sich die Konfigurationsdateien unüblicherweise im Unterverzeichnis “adminmodtest” befinden.

4.1.30  amv_enable_beta

amv_enable_beta “<string>”

Einige in Admin Mod eingebaute Funktionen haben nur Betastatus. Daher sind sie zunächst deaktiviert. Einige Plugins setzen solche Funktionen jedoch voraus, oder man selbst will etwas damit experimentieren.

Momentan gibt es drei Betafunktionen. Zur Aktivierung muss eine Zeichenfolge in Kombination mit einer Zahl angegeben werden:

-

“menu1” aktiviert die Menüfunktionen unter Admin Mod (wird inzwischen von diversen Plugins benötigt)

-

“melog1” Es kommt immer wieder zu verlorenen Entities beim Laden einer Map (fehlende Leiter, fehlende Fenster). Mit melog werden Verdachtsmomente in den Logs hinterlassen.

-

“mefix1” Funktioniert wie melog, nur dass statt eines Logeintrages versucht wird, das Problem zu fixen.

Will man mehrere Einträge machen, sind diese mit einem Doppelpunkt zu trennen (z.B. “melog1:mefix1”). Ausschalten kann man die Funktionen durch 0 (z.B. “menu0”).

Bitte beachten, dass es sich um Betafunktionen handelt, es also theoretisch zu Problemen kommen kann.

 
Beispiel:
amv_enable_beta “menu1:melog0:mefix0”

Hiermit werden die Menüs aktiviert und die Entity-Funktionen deaktiviert. Dies sollte so auch eingestellt werden. Die Menüs werden bereits vom plugin_CS genutzt, und die Entity-Funktionen haben bislang nicht zum Erfolg geführt.

4.1.31  amv_hide_reserved_slots

amv_hide_reserved_slots <#>

Wenn aktiviert, werden die reservierten Slots versteckt (1). Bei 0 werden auch diese nach außen angezeigt. Standard: 1.

!!! Es ist zu beachten, dass viele Spieler bei Abschaltung der Funktion irrtümlich davon ausgehen, dass noch Platz auf dem Server ist, obwohl dies nicht der Fall ist. !!! Ein ordentlicher Serverbrowser kann das trotz Aktivierung aber erkennen (Dazu gehört leider nicht der Steam-Browser).

 
Beispiel:
amv_hide_reserved_slots 0

Damit werden auch alle reservierten Slots von außen sichtbar. Notwendig, wenn der Connect nur über den Steam-Browser erfolgt. Nicht zu empfehlen! Besser eine Desktopverknüpfung für den Server erstellen (siehe auch Kapitel zur users.ini).

4.1.32  amv_log_passwords

amv_log_passwords <#>

Ist admin_debug aktiviert und dieser Wert nicht 0, so werden die Admin Mod-Passwörter in die Logs geschrieben. Man kann damit die Passwörter in den Logfiles mitlesen. Dies sollte nur dann aktiviert werden, wenn man beim Connect ein Authentifizierungsproblem hat und überprüfen möchte, ob das Passwort richtig übertragen wird.

 
Beispiel:
amv_log_passwords 1

Dies aktiviert, dass die Passwörter im Klartext in den Logs stehen. Nicht empfehlenswert!!

4.1.33  amv_private_server

amv_private_server <#>

Hiermit kann man einstellen, dass ausschließlich Spieler, die in der users.ini eingetragen wurden, auf dem Server spielen dürfen. Es ist also vergleichbar mit einem Passwort, nur dass das Passwort nicht weitergegeben werden kann, der Zugang also wirklich exklusiv ist. 1 aktiviert den “privaten” Server. Standard: 0.

 
Beispiel:
amv_private_server 1

Aktiviert, dass der Server nur für Spieler mit einem Eintrag in der users.ini nutzbar ist.

4.1.34  amv_prvt_kick_message

amv_prvt_kick_message “<string>”

Legt fest, mit welcher Begründung der Spieler von einem mit amv_private_server festgelegten Server gekickt wird, wenn er nicht in der users.ini steht. Standardmäßig ist kein Text hinterlegt.

 
Beispiel:
amv_prvt_kick_message “Server nur fuer Mitglieder! http://reg.xxx.xxx”

Dem Spieler wird beim Connect mitgeteilt, dass er sich registrieren möge.

4.1.35  amv_reconnect_time

amv_reconnect_time <#>

Wenn ein Admin, beispielsweise beim Mapwechsel, in einen anderen Serverslot rutscht, verliert er die Adminrechte. Mit dieser Variablen kann eingestellt werden, wie lange nach dem Mapwechsel der Admin trotz anderen Slots seine Rechte behält. Während dieser Zeit ist es Admin Mod dann möglich ihn neu zu authentifizieren. Der Maximalwert beträgt 90 Sekunden, bei 0 wird die Funktion abgeschaltet (Standard). Sollte ein Spieler beim Mapwechsel seine Rechte verlieren oder gekickt werden, so sollte versucht werden, den Wert zu erhöhen.

 
Beispiel:
amv_reconnect_time 30

Gibt Admin Mod 30 Sekunden Zeit den Spieler wieder neu zu erkennen.

4.1.36  amv_register_cmds

amv_register_cmds “<string>”

Plugins für Metamod wie LogD oder Statsme greifen per exec(“admin_command ...”) auf bestimmte Events zu. Die Verwendung von admin_command ist jedoch auf Grund von Sicherheitsbedenken nicht mehr gestattet. Mit dieser Variablen kann man bestimmten Metamodplugins dennoch Zugriff gewähren. Dazu trägt man hier den entsprechenden String ein, wie “logd_reg”. Bei LogD und Statsme ist das allerdings nicht mehr nötig, da diese schon berücksichtigt werden. Bei Verwendung mehrerer Plugins sind die Registrierungsstrings durch Leerzeichen zu trennen.

 
Beispiel:
amv_register_cmds “logd_reg sm_reg sm_register”

Dies erlaubt LogD und Statsme (alt und neue Registrierung) auf admin_command zuzugreifen. Allerdings sind diese schon automatisch berücksichtigt. Der Eintrag wird also nicht benötigt. Andere Metamod-Plugins, die diese Schnittstelle nutzen, sind unbekannt.

4.1.37  amv_vote_duration

amv_vote_duration <#>

Gibt die Länge eines Votes in Sekunden an. Normalerweise sind es 30 Sekunden. Minimal sind 2, maximal 1800 Sekunden möglich. Es ist zu beachtetn, dass die Veränderung dieses Wertes keinen Einfluss auf die Länge eines gerade laufenden Votes hat. Erst beim Start des nächsten Votes, werden die Einstellungen aktiv.

 
Beispiel:
amv_vote_duration 60

Damit ist der nächste Vote für 60 Sekunden aktiv.

4.1.38  default_access

default_access <#>

Mit dieser Variablen wird definiert, welche Rechte die Spieler erhalten, die NICHT in der users.ini stehen. Berechnet wird dieser Wert genauso wie bei einem normalen Benutzer. Übliche Werte sind jedoch entweder 0 oder 1, da darüber hinausgehende Rechte für Nichtadmins keinen Sinn machen. Default: 1.

 
Beispiel:
default_access 0

Die meisten Admins werden den default_access wie gezeigt auf 0 stellen wollen. Einige Rechte aus dem Accesslevel 1 sind meist unerwünscht.

4.1.39  encrypt_password

encrypt_password <#>

Admin Mod Passwörter können lokal auf dem Server verschlüsselt werden. Dies verhindert, dass Dritte bei Zugriff auf den Gameserver das Passwort ausspähen können. Es gibt dabei 4 verschiedene Optionen.

-

Bei 0 wird nicht verschlüsselt.

-

Bei 1 wird das unixeigene Crypt verwendet.

-

Bei 2 werden MD5-Hashes verwendet.

-

Bei 3 wird die MySQL-Passwort-Funktion verwendet. Diese steht jedoch nur bei Verwendung einer MySQL-Tabelle statt einer users.ini zur Verfügung. Hier gibt es das Problem, dass diese Option nicht mit MySQL 4.1 und neuer funktioniert (außer man setzt den gesamten SQL-Server in den Kompabilitätsmodus). In diesem Fall empfiehlt sich als Alternative, MD5-Hashes zu verwenden.

Zur Erstellung der Passwörter liegen Tools den Admin Mod-Distributionen bei (s. unter encrypt/encrypt.exe).

!!! Bitte beachten, dass der Client stets das Passwort im Klartext angeben muss !!!

 
Beispiel:
encrypt_password 2

In diesem Beispiel wandelt Admin Mod das vom Spieler übertragene Passwort in einen MD5-Hash um und vergleicht diesen mit dem Hash in der users.ini.

4.1.40  file_access_read

file_access_read <#>

Mit file_access_read erlaubt man Plugins sämtliche Dateien im Modverzeichnis und seinen Unterverzeichnissen des Servers zu lesen. Viele Plugins brauchen diese Funktion, es sind aber bösartige Plugins nie auszuschließen. Daher ist die Funktion standardmäßig auf 0 gesetzt, aktiviert wird sie durch das Setzen auf 1. Aus diesem Grund ist es immer gut Plugins selber zu compilieren, da der “bösartige” Code schnell auffindbar ist. Grundsätzlich sind uns aber keine solchen Plugins bekannt.

Viele Plugins brauchen aber Zugriff auf einige Dateien. Somit sollte man diese Funktion aktivieren.

 
Beispiel:
file_access_read 1

Aktiviert den Lesezugriff auf Dateien im Modverzeichnis.

4.1.41  file_access_write

file_access_write <#>

Mit file_access_write erlaubt man Plugins sämtliche Dateien im Modverzeichnis und seinen Unterverzeichnissen des Servers zu beschreiben/überschreiben. Viele Plugins brauchen diese Funktion, es sind aber bösartige Plugins nie auszuschließen. Daher ist die Funktion standardmäßig auf 0 gesetzt, aktiviert wird sie durch das Setzen auf 1. Aus diesem Grund ist es immer gut Plugins selber zu compilieren, da der ”bösartige” Code schnell auffindbar ist. Grundsätzlich sind uns aber keine solchen Plugins bekannt.

Viele Plugins brauchen aber Zugriff auf einige Dateien. Somit sollte man diese Funktion aktivieren.

 
Beispiel:
file_access_write 1

Aktiviert den Schreibzugriff auf Dateien im Modverzeichnis.

4.1.42  help_file (veraltet)

help_file “<string>”

Wird nur benötigt, wenn man statt das Pluginsystems das alte Scriptfilesystem verwendet. Diese Variable definiert, wo die Datei mit den Hilfebeschreibungen zu finden ist. Das Scriptfile wird schon seit Jahren nicht mehr gepflegt und sollte auch nicht mehr genutzt werden. Der Vollständigkeithalber sollte es aber erwähnt werden.

4.1.43  ips_file

ips_file “<string>”

Mittels der Datei ips.ini können festgelegte IPs, IP Ranges oder Subnets Zugriff auf die reservierten Slots erhalten. Bei dieser Variablen wird angegeben, wo sich die Datei ips.ini befindet (z.B. “addons/adminmod/config/ips.ini”). Standardmäßig ist die Funktion abgeschaltet “0”.

 
Beispiel:
ips_file “addons/adminmod/config/ips.ini”

Admin Mod sucht mit dieser Einstellung im angegebenen Verzeichnis nach der Datei ips.ini.

4.1.44  kick_ratio

kick_ratio <#>

Legt die Prozentzahl fest, die bei einem Kickvote für den Kick erreicht werden muss, damit dieser durchgeführt wird. Standardeinstellung ist 60.

 
Beispiel:
kick_ratio 50

Stimmen 5 von den 10 auf dem Server befindlichen Spielern für den Kick, so wird derjenige auch gekickt.

4.1.45  map_ratio

map_ratio <#>

Legt die Prozentzahl fest, die bei einem Mapvote für einen Mapwechsel erreicht werden muss, damit dieser durchgeführt wird. Default: 80.

 
Beispiel:
map_ratio 40

Stimmen mindestens 4 von den 10 auf dem Server befindlichen Spielern für den Mapchange, so wird dieser ausgeführt. 80% als Standardwert sind vielleicht etwas hoch gewählt.

4.1.46  maps_file

maps_file “<string>”

Mit dieser Variablen wird definiert, wo die Datei für die benutzbaren Maps zu finden ist. In der Regel ist dies addons/adminmod/config/maps.ini. Nur die in dieser Datei genannten Maps sind von Admin Mod Plugins nutzbar. Standard: “”

Sollen alle Maps votebar sein, so ist die Datei zu deaktivieren, indem die Variable auf “” gesetzt wird!

 
Beispiel:
maps_file “addons/adminmod/config/maps.ini”

Admin Mod lässt Mapvotes etc. nur zu, wenn die entsprechende Map auch in der maps.ini steht. Ist diese leer, kann gar keine Map ausgewählt werden!

4.1.47  models_file

models_file “<string>”

Definiert, wo sich die Datei für die Modelreservierung befindet. Diese Datei wird nur sehr selten verwendet und ist bei Bedarf unter “addons/adminmod/config/models.ini” anzulegen und entsprechend in die Variable zu schreiben. Braucht man keine Modelreservierung sollte diese Variable nicht definiert werden.

 
Beispiel:
models_file “addons/adminmod/config/models.ini”

Der Ort, wo sich die Datei zur Modelreservierung befindet, ist damit definiert.

4.1.48  models_kick_msg

models_kick_msg “<string>”

Definiert die Kickmessage, die bei Verwendung eines reservierten Models an den Spieler übermittelt wird. (Standard: „[ADMIN] That model is reserved on this server.“)

 
Beispiel:
models_kick_msg “So wie Du aussiehst, musst Du draussen bleiben!”

Dies gibt einen deutlichen Hinweis an den Spieler, wenn er ein reserviertes Model nutzen will.

4.1.49  mysql_database (nur MySQL-Version)

mysql_database “<string>”

Definiert die Datenbank auf dem MySQL-Server, in der sich die Konfigurationsdaten von Admin Mod befinden.

 
Beispiel:
mysql_database “adminmod”

In diesem Fall sucht Admin Mod die Informationen in der Datenbank „adminmod“.

4.1.50  mysql_dbtable_ips (nur MySQL-Version)

mysql_dbtable_ips “<string>”

Diese Variable legt fest, in welcher MySQL-Tabelle die IPs für die Slotreservierung zu finden sind. Ist kein Admin Mod-MySQL installiert, wird die Variable ignoriert, anderenfalls wird ggf. eine Definition von ips_file übergangen.

 
Beispiel:
mysql_dbtable_ips “am_ips”

Admin Mod erwartet die Daten zur Slotreservierung für IPs in der Tabelle „am_ips“.

4.1.51  mysql_dbtable_models (nur MySQL-Version)

mysql_dbtable_models “<string>”

Diese Variable legt fest, in welcher MySQL-Tabelle die Modelreservierungen zu finden sind. Ist kein Admin Mod-MySQL installiert, wird die Variable ignoriert, anderenfalls wird eine Definition von models_file übergangen.

 
Beispiel:
mysql_dbtable_models “am_models”

Admin Mod erwartet die Daten zur Modelreservierung in der Tabelle „am_models“.

4.1.52  mysql_dbtable_plugins (nur MySQL-Version)

mysql_dbtable_plugins “<string>”

Diese Variable legt fest, in welcher MySQL-Tabelle die Pluginpfade zu finden sind. Ist kein Admin Mod-MySQL installiert, wird die Variable ignoriert, anderenfalls wird eine Definition von admin_plugin_file übergangen.

 
Beispiel:
mysql_dbtable_plugins “am_plugins”

Admin Mod erwartet die Daten zu den Pluginpfaden in der Tabelle „am_plugins“.

4.1.53  mysql_dbtable_tags (nur MySQL-Version)

mysql_dbtable_tags “<string>”

Diese Variable legt fest, in welcher MySQL-Tabelle die reservierten Clantags zu finden sind. Dies ist notwendig, da Regex ein sehr ineffizienter Befehl bei MySQL ist und nicht auf große users-Tabellen angewendet werden sollte.

 
Beispiel:
mysql_dbtable_tags “am_tags”

Admin Mod erwartet die Daten zu den reservierten Clantags in der Tabelle „am_tags“.

4.1.54  mysql_dbtable_users (nur MySQL-Version)

mysql_dbtable_users “<string>”

Diese Variable legt fest, in welcher MySQL-Tabelle die Admins, ihre Passwörter und Accesslevels zu finden sind. Ist kein Admin Mod-MySQL installiert, wird die Variable ignoriert, anderenfalls wird eine Definition von users_file übergangen.

 
Beispiel:
mysql_dbtable_users “am_users”

Admin Mod erwartet die Daten zu den Admins in der Tabelle „am_users“.

4.1.55  mysql_dbtable_words (nur MySQL-Version)

mysql_dbtable_words “<string>”

Diese Variable legt fest, in welcher MySQL-Tabelle die zu zensierenden Wörter zu finden sind. Ist kein Admin Mod-MySQL installiert, wird die Variable ignoriert, anderenfalls wird eine Definition von words_file übergangen.

 
Beispiel:
mysql_dbtable_words “am_words”

Admin Mod erwartet die Daten zu den Admins in der Tabelle „am_words“.

4.1.56  mysql_host (nur MySQL-Version)

mysql_host “<string>”

Hiermit wird festgelegt, auf welchem Rechner Admin Mod-MySQL die MySQL-Datenbank findet (z.B. „localhost“). Wird MySQL nicht verwendet, wird diese Variable ignoriert.

 
Beispiel:
mysql_host “localhost”

In diesem Fall erwartet Admin Mod auf dem gleichen Rechner die MySQL-Datenbank.

4.1.57  mysql_pass (nur MySQL-Version)

mysql_pass “<string>”

Mit dieser Variablen wird das Passwort für den Zugang zum MySQL-Datenbank festgelegt. Standard: „“.

 
Beispiel:
mysql_pass “geheim”

Das Passwort für den Zugriff auf die MySQL-Datenbank ist auf „geheim“ gesetzt. Bitte ein besseres Passwort benutzen.

4.1.58  mysql_preload (nur MySQL-Version)

mysql_preload <#>

Mit dieser Variable wird eingestellt, ob die Datenbank-Tabellen beim Admin Mod-Start in den Speicher geladen werden sollen. Dies verringert ganz erheblich die Last auf dem MySQL-Server, da keine Querys mehr ausgeführt werden müssen, führt aber beispielsweise bei mehr als 1000 Usern in der users-Tabelle zu einer übermäßigen Nutzung von Speicher durch Admin Mod. 1 schaltet den preload ein. Außerdem ist die Einstellung 0 notwendig um die Variablen mysql_tags_sql und mysql_users_sql zu nutzen.

 
Beispiel:
mysql_preload 1

Diese Einstellung aktiviert das Laden der User in den Speicher beim Serverstart und beim Mapwechsel (wie users.ini). Sie deaktiviert mysql_tags_sql und mysql_users_sql!

4.1.59  mysql_tags_sql (nur MySQL-Version)

mysql_tags_sql “<string>”

Admin Mod lässt es dem Benutzer frei, den SQL-Befehl beim Zugriff auf die tags-Tabelle der MySQL-Datenbank nach eigenem Wunsch zu verändern (z.B. zur Implementierung in eine Forumssoftware).

Standard:
“SELECT pass,access FROM %s WHERE ’%s’ REGEXP nick OR nick = ’%s’”

 
Beispiel:
mysql_tags_sql “SELECT password, access FROM %s WHERE tag REGEXP ’%s’ OR
tag = ’%s’”

Der Ausdruck muss stets drei ”%s” enthalten. Diese werden in der Reihenfolge Tags-Table (mysql_dbtable_tags), Username und STEAM_ID gefüllt. mysql_preload muss auf 0 gesetzt sein, um diese Variable zu nutzen.

4.1.60  mysql_user (nur MySQL-Version)

mysql_user “<string>”

Definiert den Loginnamen für die MySQL-Datenbank.

 
Beispiel:
mysql_user “adminmodadmin”

Der Username für den Zugriff auf die MySQL-Datenbank ist auf „adminmodadmin“ gesetzt.

4.1.61  mysql_users_sql (nur MySQL-Version)

mysql_users_sql “<string>”

Admin Mod lässt es dem Benutzer frei, den SQL-Befehl beim Zugriff auf die users-Tabelle der MySQL-Datenbank nach eigenem Wunsch zu verändern (z.B. zur Implementierung in eine Forumssoftware).

Standard:
“SELECT pass,access FROM %s where nick=’%s’ or nick=’%s’”

 
Beispiel:
mysql_users_sql ”SELECT password, access FROM %s WHERE username = ’%s’
OR username = ’%s’”

Der Ausdruck muss stets drei „%s“ enthalten. Diese werden in der Reihenfolge User-Table (mysql_dbtable_users), Username und STEAM_ID gefüllt. mysql_preload muss auf 0 gesetzt sein, um diese Variable zu nutzen.

4.1.62  nicks_kick_msg

nicks_kick_msg “<string>”

Man legt hier fest, welche Meldung der Client bekommt, wenn er gegen die Namensreservierung verstößt.

Standard: “[ADMIN] That name is reserved on this server.”

 
Beispiel:
nicks_kick_msg “Du kommst hier ned rein! Nickname!”

Der Spieler wird darauf hingewiesen, dass er auf Grund seines Namens gekickt wurde.

4.1.63  password_field

password_field “<string>”

Ein wichtige Variable, damit sich die Spieler als Admin anmelden können. Hiermit legt man fest, unter welchem Variablennamen Admin Mod vom Spieler das Passwort erwartet. Standard: “_pw-home”

 
Beispiel:
password_field “_ichwillrein”

Dann lautet die setinfo-Zeile beim Client in etwa so:

setinfo “_ichwillrein” “binichschondrin”

!!! Es ist zu beachten, dass das Passwortfeld aus Sicherheitsgründen stets mit einem Unterstrich beginnt. Anderenfalls wird Admin Mod den Server nicht starten lassen !!!

4.1.64  pgsql_database (nur PostgreSQL-Version)

pgsql_database “<string>”

Definiert die Datenbank auf dem PostgreSQL-Server, in der sich die Konfigurationsdaten von Admin Mod befinden.

 
Beispiel:
pgsql_database “adminmod”

In diesem Fall sucht Admin Mod die Informationen in der Datenbank „adminmod“.

4.1.65  pgsql_dbtable_ips (nur PostgreSQL-Version)

pgsql_dbtable_ips “<string>”

Diese Variable legt fest, in welcher PostgreSQL-Tabelle die IPs für die Slotreservierung zu finden sind. Ist kein Admin Mod-PostgreSQL installiert, wird die Variable ignoriert, anderenfalls wird ggf. eine Definition von ips_file übergangen.

 
Beispiel:
pgsql_dbtable_ips “am_ips”

Admin Mod erwartet die Daten zur Slotreservierung für IPs in der Tabelle „am_ips“.

4.1.66  pgsql_dbtable_models (nur PostgreSQL-Version)

pgsql_dbtable_models “<string>”

Diese Variable legt fest, in welcher PostgreSQL-Tabelle die Modelreservierungen zu finden sind. Ist kein Admin Mod-PostgreSQL installiert, wird die Variable ignoriert, anderenfalls wird eine Definition von models_file übergangen.

 
Beispiel:
pgsql_dbtable_models “am_models”

Admin Mod erwartet die Daten zur Modelreservierung in der Tabelle „am_models“.

4.1.67  pgsql_dbtable_plugins (nur PostgreSQL-Version)

pgsql_dbtable_plugins “<string>”

Diese Variable legt fest, in welcher PostgreSQL-Tabelle die Pluginpfade zu finden sind. Ist kein Admin Mod-PostgreSQL installiert, wird die Variable ignoriert, anderenfalls wird eine Definition von admin_plugin_file übergangen.

 
Beispiel:
pgsql_dbtable_plugins “am_plugins”

Admin Mod erwartet die Daten zu den Pluginpfaden in der Tabelle „am_plugins“.

4.1.68  pgsql_dbtable_tags (nur PostgreSQL-Version)

pgsql_dbtable_tags “<string>”

Diese Variable legt fest, in welcher PostgreSQL-Tabelle die reservierten Clantags zu finden sind.

 
Beispiel:
pgsql_dbtable_tags “am_tags”

Admin Mod erwartet die Daten zu den reservierten Clantags in der Tabelle „am_tags“.

4.1.69  pgsql_dbtable_users (nur PostgreSQL-Version)

pgsql_dbtable_users “<string>”

Diese Variable legt fest, in welcher PostgreSQL-Tabelle die Admins, ihre Passwörter und Accesslevels zu finden sind. Ist kein Admin Mod-PostgreSQL installiert, wird die Variable ignoriert, anderenfalls wird eine Definition von users_file übergangen.

 
Beispiel:
pgsql_dbtable_users “am_users”

Admin Mod erwartet die Daten zu den Admins in der Tabelle „am_users“.

4.1.70  pgsql_dbtable_words (nur PostgreSQL-Version)

pgsql_dbtable_words “<string>”

Diese Variable legt fest, in welcher PostgreSQL-Tabelle die zu zensierenden Wörter zu finden sind. Ist kein Admin Mod-PostgreSQL installiert, wird die Variable ignoriert, anderenfalls wird eine Definition von words_file übergangen.

 
Beispiel:
pgsql_dbtable_words “am_words”

Admin Mod erwartet die Daten zu den Admins in der Tabelle „am_words“.

4.1.71  pgsql_host (nur PostgreSQL-Version)

pgsql_host “<string>”

Hiermit wird festgelegt, auf welchem Rechner Admin Mod-PostgreSQL die PostgreSQL-Datenbank findet (z.B. „localhost“). Wird PostgreSQL nicht verwendet, wird diese Variable ignoriert.

 
Beispiel:
pgsql_host “localhost”

Hier erwartet Admin Mod auf dem gleichen Rechner die PostgreSQL-Datenbank.

4.1.72  pgsql_pass (nur PostgreSQL-Version)

pgsql_pass “<string>”

Mit dieser Variablen wird das Passwort für den Zugang zum PostgreSQL-Datenbank festgelegt. Standard: „“.

 
Beispiel:
pgsql_pass “geheim”

Das Passwort für den Zugriff auf die PostgreSQL-Datenbank ist auf „geheim“ gesetzt. Bitte ein besseres Passwort benutzen.

4.1.73  pgsql_port (nur PostgreSQL-Version)

pgsql_port “<string>”

Hiermit setzt man den Port mit dem auf die PostgreSQL-Datenbank zugegriffen werden soll. Default: 5432

 
Beispiel:
pgsql_port 5433

Dies verändert den Standardport für den Zugang zur PostgreSQL-Datenbank auf 5433.

4.1.74  pgsql_preload (nur PostgreSQL-Version)

pgsql_preload <#>

Mit dieser Variable wird eingestellt, ob die Datenbank-Tabellen beim Admin Mod-Start in den Speicher geladen werden sollen. Dies verringert ganz erheblich die Last auf dem PostgreSQL-Server, da keine Querys mehr ausgeführt werden müssen, führt aber beispielsweise bei mehr als 1000 Usern in der users-Tabelle zu einer übermäßigen Nutzung von Speicher durch Admin Mod. 1 schaltet den preload ein. Außerdem ist die Einstellung 0 notwendig um die Variablen pgsql_tags_sql und pgsql_users_sql zu nutzen.

 
Beispiel:
pgsql_preload 1

Diese Einstellung aktiviert das Laden der User in den Speicher beim Serverstart und beim Mapwechsel (wie users.ini). Sie deaktiviert pgsql_tags_sql und pgsql_users_sql!

4.1.75  pgsql_tags_sql (nur PostgreSQL-Version)

pgsql_tags_sql “<string>”

Admin Mod lässt es dem Benutzer frei, den SQL-Befehl beim Zugriff auf die tags-Tabelle der PostgreSQL-Datenbank nach eigenem Wunsch zu verändern (z.B. zur Implementierung in eine Forumssoftware).

Standard:
“SELECT pass,access FROM %s WHERE ’%s’ REGEXP nick OR nick = ’%s’”

 
Beispiel:
pgsql_tags_sql “SELECT password, access FROM %s WHERE tag REGEXP ’%s’ OR
tag = ’%s’”

Der Ausdruck muss stets drei ”%s” enthalten. Diese werden in der Reihenfolge Tags-Table (pgsql_dbtable_tags), Username und STEAM_ID gefüllt. pgsql_preload muss auf 0 gesetzt sein, um diese Variable zu nutzen.

4.1.76  pgsql_user (nur PostgreSQL-Version)

pgsql_user “<string>”

Definiert den Loginnamen für die PostgreSQL-Datenbank.

 
Beispiel:
pgsql_user “adminmodadmin”

Der Username für den Zugriff auf die PostgreSQL-Datenbank ist auf „adminmodadmin“ gesetzt.

4.1.77  pgsql_users_sql (nur PostgreSQL-Version)

pgsql_users_sql “<string>”

Admin Mod lässt es dem Benutzer frei, den SQL-Befehl beim Zugriff auf die users-Tabelle der PostgreSQL-Datenbank nach eigenem Wunsch zu verändern (z.B. zur Implementierung in eine Forumssoftware).

Standard:
“SELECT pass,access FROM %s where nick=’%s’ or nick=’%s’”

 
Beispiel:
pgsql_users_sql ”SELECT password, access FROM %s WHERE username = ’%s’
OR username = ’%s’”

Der Ausdruck muss stets drei „%s“ enthalten. Diese werden in der Reihenfolge User-Table (pgsql_dbtable_users), Username und STEAM_ID gefüllt. pgsql_preload muss auf 0 gesetzt sein, um diese Variable zu nutzen.

4.1.78  pretty_say

pretty_say <#>

Pretty_say definiert, wie ein Centersay dargestellt werden soll. Steht dies auf 1 (Standard), so wird der Centersay farbig und mit Fade-In und -Out dargestellt, bei 0 als simpler Text. Standard: 1

 
Beispiel:
pretty_say 1

Diese Einstellung bringt Farbe in Admin Mod (aber dezent...).

4.1.79  public_slots_free

public_slots_free <#>

Diese Variable zeigt die noch freien Plätze auf dem Server an. Ein manuelles Setzen ist nutzlos und hat außer einer Fehldarstellung keine Auswirkungen. Rein informative Variable für Serverbrowser.

4.1.80  reserve_slots

reserve_slots <#>

Man legt hier fest, wieviele Plätze (Slots) für Administratoren reserviert werden. Bitte auch reserve_type beachten. Reservierte Slots können nur von Admins mit dem Recht 32768 genutzt werden. Die reservierten Slots sind standardmäßig abgeschaltet (Default: 0).

 
Beispiel:
reserve_slots 1

Diese Einstellung macht einen Serverslot nur für die Admins nutzbar. Mehr zu dem Thema ist dem Kapitel 4.4.4 (Serverplätze reservieren) zu entnehmen.

4.1.81  reserve_slots_msg

reserve_slots_msg “<string>”

Legt fest, welche Nachricht angezeigt wird, wenn nur noch reservierte Slots vorhanden sind und ein normaler Spieler versucht auf den Server zu connecten. Standardmäßig bekommt der Spieler folgendes zu lesen:

“There are no reserved slots available on the server.”

 
Beispiel:
reserve_slots_msg “Alle freien Plaetze sind schon besetzt. Sorry!”

Ein freundlicher Hinweis, dass leider keine freien Plätze mehr frei sind. Mehr zu dem Thema ist dem Kapitel 4.4.4 (Serverplätze reservieren) zu entnehmen.

4.1.82  reserve_type

reserve_type <#>

Diese Variable ist zunächst komplexer als sie erscheint. Sie legt fest, wie Admin Mod mit den reservierten Slots umgehen soll.

-

0: Admins werden zunächst in öffentlichen Slots untergebracht und die reservierten Slots werden bei einem Disconnect zuerst freigemacht.

-

1: Unabhängig vom Wert in reserve_slots ist immer 1 Slot zum Connecten reserviert.

-

2: Connectende Admins werden zunächst in die reservierten Slots geschoben und bei Disconnects zunächst öffentliche Slots geleert.

 
Beispiel:
reserve_type 1

Einen Slot ausschließlich zum Connecten der Admins zu verwenden, ist von den meisten gewünscht. Bei dieser Einstellung wird die Einstellung von reserve_slots ignoriert und nur ein Slot reserviert. Der Platz bleibt immer frei, steht also nicht zum Spielen zur Verfügung. Er ist nur temporär für die Zeitdauer des Connectens für die Admins nutzbar. Für den Admin wird der Spieler mit dem höchsten Ping gekickt. Mehr zu dem Thema ist dem Kapitel 4.4.4 (Serverplätze reservieren) zu entnehmen.

4.1.83  script_file (veraltet)

script_file “<string>”

Definiert, wo das Scriptfile zu finden ist. Die Verwendung des Scriptfiles ist veraltet, es wird stattdessen das Pluginsystem (admin_plugin_file) verwendet.

4.1.84  use_regex

use_regex <#>

Schaltet RegEx (Regular Expressions; reguläre Ausdrücke) für die Verwendung in der Datei users.ini ein (1) bzw. aus (0). RegEx ermöglicht die Verwendung von Wildcards und kann z.B. für die Reservierung von Clantags genutzt werden. Regex ist ein mächtiges aber auch kompliziertes Tool, was meist eine Überarbeitung der gesamten users.ini mit sich zieht. Es lohnt sich aber. Standardeinstellung: 0.

 
Beispiel:
use_regex 1

Schaltet die Verwendung von RegEx ein.

Das Kapitel 4.4.6 (RegEx) geht genauer auf das Thema ein.

4.1.85  users_file

users_file “<string>”

Hier wird festgelegt, wo sich die Datei mit den Adminrechten befindet (in der Regel „addons/adminmod/config/users.ini“).

 
Beispiel:
users_file “users.ini”

Mit dieser Einstellung erwartet Admin Mod die users.ini im Mod-Verzeichnis.

4.1.86  vote_freq

vote_freq <#>

Mit dieser Variable wird festgelegt, welcher Zeitraum (Sekunden) zwischen zwei Votes bzw. nach einem Mapchange verstrichen sein müssen, damit ein neuer Vote erstellt werden kann. Setzt man den Wert auf 0 wird Voten komplett abgeschaltet. Es ist zu beachten, dass der Wert beim Ändern erst nach dem nächsten Vote aktiv wird. Standard: 180.

Beim Plugin hldsld_mapvote ist eine andere Variable zu setzen (admin_vote_freq).

 
Beispiel:
vote_freq 300

Stellt die Zeit, die zwischen zwei Votes zu verstreichen hat, auf 5 Minuten.

4.1.87  words_file

words_file “<string>”

Die Variable definiert den Ort, an dem die Datei mit den zu zensierenden Wörtern zu finden ist (in der Regel „addons/adminmod/config/wordlist.txt“).

 
Beispiel:
words_file “wordlist.txt”

Mit dieser Einstellung erwartet Admin Mod die wordlist.txt im Mod-Verzeichnis.

4.2  Plugins installieren (plugin.ini)

Einer der Gründe für die Beliebtheit von Adminmod ist sicherlich das Pluginsystem. Einige Plugins, die die Standardfunktionen beinhalten, werden bereits mit der Admin Mod Distribution geliefert. Standardmäßig erwartet Admin Mod die Plugins im Verzeichnis „addons/adminmod/scripts“. Admin Mod lädt aber nicht alle Dateien aus diesem Verzeichnis. In der „plugin.ini“ (Bitte nicht mit der plugins.ini von Metamod verwechseln!) werden die Dateien festgelegt, die geladen werden sollen, und wo sie relativ zum Mod-verzeichnis zu finden sind.

Standardmäßig sollte nach einer normalen Installation die plugin.ini folgendermaßen aussehen:

addons/adminmod/scripts/plugin_antiflood.amx
addons/adminmod/scripts/plugin_base.amx
addons/adminmod/scripts/plugin_chat.amx
addons/adminmod/scripts/plugin_cheat.amx
# addons/adminmod/scripts/plugin_CS.amx
# addons/adminmod/scripts/plugin_TFC.amx
addons/adminmod/scripts/plugin_hldsld_mapvote.amx
addons/adminmod/scripts/plugin_message.amx
addons/adminmod/scripts/plugin_retribution.amx
addons/adminmod/scripts/plugin_fun.amx

Hier liegt folgendes Prinzip vor:
„addons/adminmod/scripts“ ist der Ordner, in dem in der Regel die Plugins liegen. Aber es ist auch jedes andere Verzeichnis relativ zum Modverzeichnis möglich (auch außerhalb mit „../“). Es schließt sich der Name des Plugins an (Wie immer gilt unter Linux die Groß- und Kleinschreibung zu beachten!). Soll ein bestimmtes Plugin nicht geladen werden, ist eine Raute (#) der Zeile voranzustellen und somit auszukommentieren (s. plugin_CS). Alternativ kann die entsprechende Zeile auch einfach gelöscht werden.

WICHTIG: Um Änderungen an der plugin.ini dem Server bekannt zu geben, ist ein Serverrestart oder besser ein einfacher Mapwechsel notwendig. Erst dann wird die Datei neu eingelesen.

Mittels der Include-Anweisung können aber auch weitere Dateien eingebunden werden. Es ist dabei sogar möglich diese Dateien außerhalb des Mod-Verzeichnisses einzubinden.

#include “../../../../standard-plugin.ini”

In der beschriebenen „standard-plugin.ini“ (hier im hlds-Verzeichnis) könnten beispielsweise Plugins stehen, die auf allen Gameservern laufen sollen. Ein identischer Eintrag bei allen Gameservern erlaubt die zentrale Verwaltung der Plugins über diese Datei.

hlds/cstrike/addons/adminmod/config/plugin.ini:
#include “../../../../standard-plugin.ini”
addons/adminmod/scripts/plugin_CS.amx

hlds/standard-plugin.ini:
../scripts/plugin_antiflood.amx
../scripts/plugin_base.amx
../scripts/plugin_chat.amx
../scripts/plugin_cheat.amx
../scripts/plugin_hldsld_mapvote.amx
../scripts/plugin_message.amx
../scripts/plugin_retribution.amx
../scripts/plugin_fun.amx

Die Plugins aus der „standard-plugin.ini“ befinden sich dann in „hlds/scripts“. Wie man erkennen kann, können Includes auch mit normalen Einträgen kombiniert werden. In diesem Fall könnte man annehmen, dass ein CS, TFC und ein Ricochet-Server läuft. Je nach Mod kann man dann die Spezialplugins aus dem normalen Scripts-Verzeichnis starten während die übergreifenden aus dem gemeinsamen Verzeichnis geladen werden.

Hier auch noch der Hinweis. Für Counter-Strike und Team Fortress Classic gibt es spezielle Standardplugins, die zunächst erst aktiviert werden müssen (Entfernen der Raute „#“). Gerade bei Counter-Strike kommen oftmals Fragen, warum denn die Befehle admin_restartround oder admin_ct nicht funktionieren. Diese Befehle gibt es erst, wenn man plugin_CS auch aktiviert.

Es gibt darüber hinaus auch die Möglichkeit alle Dateien aus einem entsprechenden Verzeichnis zu laden. Die ungewünschten Plugins müssen dann natürlich entfernt oder umbenannt werden (z.B. „*.amx“ in „*.amx.noload“). Des Weiteren muss die Variable admin_plugin_file das Verzeichnis der Scripts und nicht die plugin.ini beinhalten. Damit kann die plugin.ini entfallen, man kann dann aber die Ladereihenfolge nur noch über den Dateinamen beeinflussen, was manchmal unerwünscht ist.

4.3  Plugins kompilieren

Es taucht immer wieder die Frage auf, wie man aus einer sma- eine amx-Datei macht. Man nennt das Kompilieren. Dabei ist „.sma“ der Quellcode und „.amx“ das fertige Plugin.

Jeder sollte grundsätzlich seine Plugins selber compilieren. Das ist nicht wirklich schwierig und verringert das Risiko, dass einem ein bösartiges Plugin untergeschoben wird.

Man braucht zunächst einen Compiler. Dieser liegt der jeweils aktuellen Admin Mod-Version bei.

Nach dem Entpacken wechselt man in das Verzeichnis „scripting/myscripts“. Dies ist das Verzeichnis für die Quellcode-Dateien (sma). Zwei Dateien sind bereits vorhanden. Unter Linux sind das „compile“ und „compile_all“ sowie unter Windows „compile.bat“ und „compile_all.bat“.

Um einzelne Plugins zu compilieren muss man eine Shell bzw. Eingabeaufforderung öffnen, und im myscripts-Verzeichnis schreiben:

./compile plugin_xxx.sma

bzw. für Windows

compile.bat plugin_xxx.sma

Wobei plugin_xxx.sma natürlich für jedes x-beliebige Plugin steht.

Das ist etwas unbequem. Weil der Compiliervorgang meist recht kurz ist, kann man auch alle Plugins auf einmal kompilieren:

./compile_all

bzw. für Windows

compile_all.bat

Sofern keine Fehlermeldungen (ERROR) aufgetreten sind, muss man nun nur noch ins Verzeichnis „scripting/mybinaries“ gehen und die fertigen Plugins abholen.

Der Unterschied zwischen ERROR und WARNING ist zu beachten. Plugins mit WARNINGs funktionieren meist ohne Probleme. Es ist zwar unschön, wenn man diese bekommt, aber es ist kein Weltuntergang. In der Regel passiert das gern, wenn man ältere Plugins compilieren möchte. Der Compiler wurde von Version zu Version verschärft. Da sind Warnings dann nicht auszuschließen.

Es darf weiterhin nicht übersehen werden, dass amx-Dateien nicht gleich amx-Dateien sind. Sie wurden für das jeweilige Betriebssystem kompiliert, auf dem der Compiler lief.

Viele kompilieren unter Windows, haben aber einen Linuxserver. Seit Version 2.50.56 konvertiert Admin Mod zwar die Plugins selbstständig bei jedem Mapwechsel Plugins. Das kostet aber wiederum bei jedem Mapwechsel ein wenig Rechenzeit.

Als verantwortungsbewusster Administrator sollte man daher die Plugins vorab konvertieren. Die entsprechenden Konverter gibt es auf adminmod.org¹ und adminmod.de².

Ausgeführt werden die Kommandozeilen-Versionen (CMD) folgendermaßen:

./amxconvert plugin_xxx.amx

bzw. für Windows

amxconvert.exe plugin_xxx.amx

Für Windows gibt es aber auch eine Version mit einer graphischen Oberfläche (GUI).

4.4  Administratoren einrichten (users.ini)

4.4.1  Serverseitige Einstellungen

Administratoren müssen über die users.ini eingerichtet werden, denn zunächst weiß der Server nicht, wer Admin ist. Außerdem müssen auch die Rechte festgelegt werden. Die users.ini ist in „addons/adminmod/config“ zu finden. In die users.ini muss entweder ein Spielername, eine ID oder eine IP, sowie das dazugehörige Passwort und die Rechte des Admins eingetragen werden.

Typische Einträge in der users.ini sehen in etwa so aus:

[Bond]JamesBond:007:131071
192.168.14.31:IloveNY:255
STEAM_0:0:12345:steamy:134
\:Mr. Colon\::colonizeme:1492

Das Trennzeichen für die Einträge ist der Doppelpunkt.

4.4.1.1. Player:Password:Rights

Der Eintrag vor dem ersten Doppelpunkt kann, wie den Beispielen oben zu entnehmen ist,

einen Spielernamen,
eine WONID,
eine IP-Adresse,
eine STEAM_ID oder
eine VALVE_ID

aufnehmen. Eine Kombination von unterschiedlichen IDs oder Spielernamen in einer users.ini ist ohne Probleme möglich. Kommen Doppelpunkte im Spielernamen auf müssen diese mit einem Backslash „\“ escaped werden (s. viertes Beispiel). Die Doppelpunkte in den Steam IDs werden automatisch erkannt und müssen nicht escaped werden. Wird die Option hyperref[use-regex]use_regex genutzt, müssen noch weitere Zeichen escaped werden. Darauf wird aber im Kapitel 4.4.6 (RegEx (Clantags reservieren etc.)) näher eingegangen.

Von der Verwendung der Spielernamen zur Authentifizierung bei Admin Mod sollte Abstand genommen werden. Jeder kann einen in der users.ini angelegten Namen annehmen und mit dem richtigen Passwort hat er bereits Rechte auf dem Server. Außerdem verliert man bei einem Namenswechsel die Adminrechte.

Weiterhin sollte die Verwendung von IPs auf Netze mit statischer IP-Vergabe beschränkt werden, also meist LANs mit statischen IPs (keine automatische Vergabe) oder auf MAC-Adresse basierte Vergabe von IPs mittels DHCP.

Seit der Admin Mod Version 2.50.60 ist die localhost Adresse, 127.0.0.1, als ID für den Eröffner eines Listenservers erlaubt. Da zwar jeder diese Adresse auf seinem Rechner erhält, sie aber nur auf dem eigenen gültig ist, ist dies eine sichere Methode, so dass ein Passwort ausgelassen werden kann. Es ist deshalb auch nicht notwendig eine adminpass.cfg anzulegen. Der Einloggvorgang erfolgt automatisch.

Der users.ini Eintrag lautet dann:

127.0.0.1::131071

Dem Eröffner sollten natürlich sämtliche Rechte, 131071, gegeben werden. Letztlich könnte er auch admin_cmd vor die Admin Mod Befehle setzen. Eine Einschränkung wäre daher unnütz.

4.4.1.2. Player:Password:Rights

Der mittlere Eintrag beinhaltet das Passwort des Spielers.

Das Passwort in der users.ini kann aber auch leergelassen werden, so dass beim Client keine Einstellungen vorgenommen werden müssen. Diese Methode sollte nur bei absoluten DAUs (Dümmste Anzunehmende User) verwendet werden, die mit den Clienteinstellungen nicht zurecht kommen. Aber eigentlich sollten solche Leute schon deshalb keine Adminrechte bekommen. Man kann aber zumindest bei der Verwendung der Steam ID recht sicher sein, dass niemand sie übernehmen kann. 100%ig sicher sollte man sich aber nicht sein. Bei allen anderen Spielereinträgen wie IP oder Name ist das Weglassen des Passwortes in jedem Fall fahrlässig!

Beispiel für das Weglassen des Passworts:

STEAM_0:1:9174::131071

Umgekehrt kann man die Sicherheit auch erhöhen, indem man verschlüsselte Passwörter verwendet.

Dies ist besonders anzuraten, wenn man seinen Gameserver auf einem Rechner hat, der noch von anderen Personen genutzt wird. Es wird verhindert, dass diese die Admin Mod-Passwörter ausspähen können.

Bis Admin Mod 2.50.56 war dies nur mit Linuxrechnern möglich. Ein kleines Tool namens make_pass, das der Linuxdistribution beiliegt, wird zur Erstellung der verschlüsselten Passwörter verwendet. Der Rückgabewert von ./make_pass meinpasswort ist dann die Verschlüsselung für „meinpasswort“. Das verschlüsselte Passwort muss nun statt des Klartext-Passworts in die users.ini aufgenommen und die Variable encrypt_password 1 in der adminmod.cfg gesetzt werden.

Mit der Version 2.50.56 wurde dieses Tool durch das Programm encrypt ersetzt. Dieses ist nun in der Lage die alten Passwörter (Parameter -c) bzw. auch MD5-Hashes (Parameter -m) zu produzieren. Die encryt_password Variable ist abwärtskompatibel, muss jedoch auf 2 gesetzt werden, wenn man MD5-Hashes nutzen möchte.

Inzwischen gibt es das Verschlüsselungstool auch mit einer graphischen Oberfläche (sowohl unter Linux als auch unter Windows), die auf adminmod.de³ zum Download zur Verfügung stehen.

Beim Client ist nichts zu ändern. Er überträgt das Passwort weiterhin im Klartext. Wenn jemand den Netzwerkverkehr mitliest, kann er das Passwort immer noch das Passwort ermitteln. Man sollte also ein Passwort wählen, das man ansonsten nicht verwendet. Die Verschlüsselung dient ausschließlich dem Entgegenwirken eines Ausspähens lokal auf dem Server.

Wichtig: Es ist nicht möglich verschiedene Verschlüsselungsarten oder eine Verschlüsselung in Kombination mit Klartextpasswörter gleichzeitig in der users.ini zu verwenden. Man muss ich für eine Variante entscheiden.

4.4.1.3. Player:Password:Rights

Der letzte Eintrag definiert die Rechte des Admins. Diese können ganz unterschiedlicher Art sein. Nicht jeder Admin benötigt schließlich volle Zugangsrechte zum Server.

Adminmod hat daher mehrere Rechtelevel. Jeder einzelne Level beinhaltet Befehle, die der Admin dann ausführen darf. Die Level werden durch Zahlen symbolisiert. Ein Rechtelevel der Stufe 2 beinhaltet z.B. die Befehle: admin_map und admin_timelimit. Ein Admin, der diesen Rechtelevel besitzt, darf also z.B. die Map wechseln oder das Zeitlimit ändern. Die Rechtelevel werden ADDIERT und die Summe in die users.ini eingetragen. Mehr dazu im Kapitel 4.4.3 (Rechtelevel).

WICHTIG: Änderungen an der users.ini werden erst nach einem Serverrestart, Mapwechsel oder dem Befehl “admin_reload” übernommen.

Weitere Dateien lassen sich mit der Include-Anweisung einbinden, z.B.:

#include “admins.ini”

Steht dieser Eintrag in der users.ini, sucht Admin Mod auch noch in der admins.ini (im gleichen Verzeichnis) nach weiteren Usern (vergl. plugin.ini).

4.4.1.4. Serverseitige Einstellungen (adminmod.cfg)

Nun sollte noch einen Blick in die adminmod.cfg („addons/adminmod/config“) geworfen werden. Hier sollte die Variable password_field nach den eigenen Vorstellungen verändert werden. Diesen Variablennamen wird der Server vom Spielerconnect überprüfen. Es ist zu beachten, dass der Unterstrich zwingend vor den Variablennnamen zu schreiben ist. Ansonsten wird der Server aus Sicherheitsgründen nicht starten. Der Eintrag sieht standardmäßig folgendermaßen aus:

password_field “_pw-home”

Der Hintergrund für die zwingend vorgeschriebene Nutzung des Unterstriches ergibt sich aus einem „Exploit“, mit dem jeder Admin das Passwort eines Users auslesen kann. Während die über setinfo gesetzten, userspezifischen Variablen ohne den Unterstrich mit der Serverfunktion condump ausgelesen werden können, ist dies beim vorangestellten Unterstrich nicht der Fall. Falls man also trotz mehrfacher Warnung das Passwort doch in der config.cfg oder autoexec.cfg setzt, kann ein böswilliger Admin eines anderen Servers nicht an die Variable herankommen.

Fortgeschrittene Methoden und Einstellungen in der adminmod.cfg:

default_access
admin_highlander
amv_private_server
reserve_slots
reserve_slots_msg
reserve_type
use_regex

4.4.2  Clientseitige Einstellungen

Im Kapitel 4.4.1 wurde beschrieben, wie dem Server das Wissen vermittelt wird, wer Admin ist und wer nicht. Es könnte aber jeder mit dem passenden Namen, ID oder IP kommen und behaupten er/sie wäre Admin. Admin Mod überprüft, sofern in der users.ini angegeben, daher zusätzlich das Passwort. Es gibt dabei zwei Möglichkeiten dieses dem Server zu übergeben.

admin_login <Passwort>

Mit diesem Befehl wird dem Server via Console das eigene Admin Mod-Passwort übergeben. Die Methode funktioniert nicht bei Namensreservierung und für die Slotreservierung, da man vor der Möglichkeit der Eingabe des Befehls bereits vom Server geworfen wird.

setinfo “<password_field>” “<Passwort>”

Die setinfo Variante ist die elegantere Methode zum Anmelden bei Admin Mod und die einzige bei Namens- und Slotreservierung. Man definiert eine Variable beim Client, in der das Passwort hinterlegt wird. Mehr zu dem Thema setinfo ist aus der FAQ zu entnehmen. Ein typischer Eintrag lautet daher:

setinfo “_pw-home” “xxx”

wobei xxx für das in der users.ini definierte Passwort steht. Falls man in der adminmod.cfg die Variable password_field verändert hat, muss man „_pw-home“ natürlich entsprechend abändern.

Merke: Auch bei verschlüsselten Passwörtern in der users.ini, muss beim Client IMMER das Passwort im Klartext angegeben werden.

Wo trage ich das ein? Viele Wege führen nach Rom:

1. Verknüpfung: Man erstellt eine Verknüpfung ausschließlich zum connecten auf den eigenen Server.

   Beispiel:

   X:\Steam\Steam.exe -applaunch 10 +exec adminpass.cfg
   +connect 213.239.218.84:27015

   wobei in adminpass.cfg (im Modverzeichnis, bsp. hier cstrike) die setinfo-Zeile für das Passwort steht. -applaunch 10 steht für Counter-Strike. Andere Mods haben andere Zahlen. Hat der Server ein Passwort, so muss +password <Serverpasswort> zusätzlich angefügt werden.

   Man kann das alles aber auch in der adminpass.cfg ausführen lassen, die dann in etwa so aussähe:

   setinfo “_pw-home” “xxx”
   password <Serverpasswort>
   rcon_password <Rcon-Passwort>
   connect 213.239.218.84:27015

   In die Verknüpfung müsste dann nur stehen:

   X:\Steam\Steam.exe -applaunch 10 +exec adminpass.cfg

2. Externe Tools: HLSW beispielsweise ermöglicht das Setzen eines Passworts beim Connect aus dem Programm heraus. Hierbei muss in den Servereigenschaften bei „Zusätzliche Parameter“ stehen:

   +exec adminpass.cfg

3. autoexec.cfg: Wird immer gerne genannt, funktioniert auch gut, stellt aber ein Sicherheitsrisiko dar, da das Passwort jedem Server mitgeteilt wird, nicht nur dem eigenen.
4. valve.rc: Das Selbe wie mit der autoexec.cfg.

Wofür man sich entscheidet, sei einem selbst überlassen. Es ist aber zu bedenken, dass die Optionen 3 und 4 ein erhebliches Sicherheitsrisiko bergen. Im Zweifel admin_login benutzen, sofern keine Reservierungen verwendet werden.

Wie erkennt man aber, dass der Server einen als Admin erkannt hat?

Die folgenden Zeilen müssen beim Connecten erscheinen:

[ADMIN] Checking password for user access...
[ADMIN] Password accepted for user ’0815-Avg’. Access granted: 131071

Bei Steam ist nach dem Connect in die Console zu gehen und etwas scrollen, um die Zeilen zu finden.

Wird man dennoch nicht als Admin erkannt, sollte man zunächst die einzelnen Schritte im Kapitel 4.4 genau durchgehen.

Es gibt allerdings drei besondere Punkte, die zu beachten sind.

1. Zunächst sollte die Variable encrypt_password überprüft werden. Diese muss passend zu den Passwörtern in der users.ini gesetzt sein. Wer keine Passwortverschlüsselung verwendet soll hier 0 nehmen.
2. Wenn use_regex verwendet wird (Variable auf 1), sollte man immer darauf achten, dass evtl. vorhandene Regex-Steuerzeichen „escaped“ werden.
3. Ebenfalls dürfte es Leuten mit einem Steam-Listenserver Probleme bereiten, IPs oder die STEAM_ID als Authentifizierungsmerkmal in der users.ini zu verwenden. Es geht jedoch über die Localhost Adresse (s. Kapitel 4.4.1.1).

4.4.3  Rechtelevel

Das Rechtesystem von Admin Mod basiert auf dem Dualsystem (2^x). Jedem Level ist ein Bit (x) zugeordnet. Allerdings wird nicht das Bit angegeben sondern die sich daraus ergebene Dezimalzahl (s. Tabellen 4.1 und 4.2 für die Standardplugins):

---

---

---

---

Beispiel: 2⁴ = 16 oder 2⁸ = 256

Binär entspricht 16 = 00001000 bzw. 256 = 10000000. Man erkennt in der Binärschreibweise die einzelnen gesetzten Rechtelevel. Jedem einzelnen Befehl wird in den Plugins ein Rechtelevel zugewiesen, den der Admin braucht, um den Befehl auszuführen. Da dies ganz unterschiedliche Rechtelevel sein können und man in der Regel mehrere Level gleichzeitig zuweisen möchte, muss man die einzelnen Rechtelevel addieren.

∑ _i=0ⁿx _i ⋅ 2ⁱ = x ₀ ⋅ 2⁰ + x ₁ ⋅ 2¹ + x ₂ ⋅ 2² + ... + x _n ⋅ 2ⁿ

Beispiel: 2⁴ + 2⁸ = 16 + 256 = 272 oder binär 10001000

Aus den Tabellen 4.1 und 4.2 können die Rechtelevel für die Befehle der Standardplugins entnommen werden. Die Rechtelevel reichen von 0 bis 65536. Es ist aber auch möglich höhere Werte zu verwenden (z.B. für admin_highlander oder Customplugins). Das Level 0 wird dem Spieler immer zugewiesen. Der Hauptadmin, der auch das Rcon-Passwort kennt, sollte fast alle Rechte erhalten:

∑ _i=0¹⁶x _i ⋅ 2ⁱ - 2¹² - 2¹⁴ - 2¹⁵ = 77823

Die abgezogenen Rechtelevel werden zwar hin und wieder von Customplugins für Befehle benutzt, sie haben jedoch eine besondere Bedeutung für Admin Mod.

4096 (2¹²):

Ein Admin mit diesem Level ist immun gegenüber anderen Admins (es gibt aber auch Plugins, die das umgehen). Die Immunität kann im Spielverlauf durch das Setzen von admin_ignore_immunity 1 ausgesetzt werden.

16384 (2¹⁴):

Der eigene Name bzw. die eigene ID oder IP ist damit reserviert und darf ausschließlich vom in der users.ini angegebenen Spieler mit dem passenden Passwort verwendet werden.

32768 (2¹⁵):

Man erhält einen exklusiven Zugang zum Server, selbst wenn dieser voll ist (Stichwort: reserve_type, reserve_slots). Es ist zu beachten, dass Admin Mod nicht zaubern kann; um auf den Server zu kommen ist immer noch ein freier Slot notwendig. Half-Life fängt bei vollem Server den Connectenden schon ab, bevor Admin Mod eingreifen kann.

Erst mit diesen drei gesonderten Leveln ergibt sich die häufig zu findende Empfehlung 131071, die aber meist gar nicht notwendig ist und oftmals mehr Probleme bereitet als hilft.

∑ _i=0¹⁶x _i ⋅ 2ⁱ = 131071

4.4.4  Serverplätze reservieren

Wer kennt das nicht? Man möchte auf dem eigenen Server spielen, der aber voll ist. Dem Admin sollten besondere Rechte zugesprochen werden, dass er auch auf einen „vollen“ Server connecten kann. Dazu wurden in Admin Mod die reservierten Plätze (oder auch Slots) eingeführt.

Um diese Funktion zu nutzen, ist etwas Vorarbeit zu leisten. Zunächst muss den Admins, die einen reservierten Slot nutzen dürfen, der Rechtelevel 32768 hinzugefügt werden (sofern nicht schon geschehen). Des Weiteren müssen sich entsprechende Admins mit der setinfo-Zeile anmelden. Und letztlich muss auch der Server für die Nutzung der Slots konfiguriert werden. Dabei sind die Anzahl der reservierten Slots (reserve_slots), die von den öffentlich verfügbaren Slots abgezogen werden (können nicht von normalen Spielern genutzt werden) und die Art der Reservierung (reserve_type) festzulegen. Optional kann auch eingestellt werden, welche Nachricht ein normaler Spieler erhält, wenn er versucht auf den Server zu kommen und nur reservierte Plätze erhältlich sind (reserve_slots_msg).

Während sich die Einstellungen reserve_slots und reserve_slots_msg noch von selbst erschließen, ist die richtige Einstellung von reserve_type nicht so einfach ersichtlich. Im weiteren sollen die drei vorhandenen Konzepte 0, 1 und 2 näher erläutert werden.

4.4.4.1. reserve_type 0

Dazu nehmen wir einen Server mit 14 Slots an und in Admin Mod wurden 2 Slots reserviert. Es sind somit 12 Slots öffentlich für alle Spieler verfügbar und 2 ausschließlich für Admins. Außerdem befinden sich zunächst 11 normale Spieler auf dem Server, die damit 11 der 12 öffentlichen Slots beanspruchen.

Bei der Einstellung 0 würde sowohl ein zusätzlicher normaler Spieler als auch ein Admin den letzten öffentlichen Platz einnehmen. Sofern niemand vom Server geht, können nur noch Admins connecten. Kommt ein weiterer Admin, nimmt dieser einen der reservierten Slots in Anspruch. Geht nun ein Spieler oder Admin aus den öffentlichen Slots, rutscht der Admin im reservierten Slot in den freien öffentlichen. Es sind somit wieder alle öffentlichen Slots besetzt und die 2 reservierten frei (s.a. Abbildung 4.1).

---

---

Die Einstellung 0 hat den Vorteil, dass sofern nicht der Server voll ist, immer Admins auf den Server kommen können. Falls nicht alle öffentlichen Plätze belegt sind, nehmen die Admins jedoch den normalen Spielern die Plätze weg. Im schlimmsten Fall belegen die Admins alle öffentlichen Plätze, so dass die volle Slotzahl nicht ausgenutzt werden kann. Sind neben den öffentlichen auch alle reservierten Plätze besetzt, kann kein weiterer Admin auf den Server. Vorzugsweise sollte man nur einen Slot reservieren, da man ansonsten nur in seltenen Fällen wirklich mit mehr Spielern als der Anzahl der öffentlichen Plätze spielen kann.

4.4.4.2. reserve_type 1

Einen Slot ausschließlich zum Connecten der Admins zu verwenden, ist von den meisten gewünscht. Bei dieser Einstellung wird reserve_slots ignoriert und nur ein Slot reserviert. Der Platz bleibt immer frei, steht also nicht zum Spielen zur Verfügung. Er ist nur temporär für die Zeitdauer des Connectens für die Admins nutzbar. Für den Admin wird der Spieler mit dem höchsten Ping gekickt, und er gelangt in den frei gewordenen öffentlichen Slot (s.a. Abbildung 4.1). Dabei ist zu beachten, dass solange der connectende Admin nicht ins Spiel eingestiegen ist, er den Slot für weitere Admins blockiert. Diese Einstellung hat den großen Charme, dass man als Admin stets auf den Server kann, allerdings steht dauerhaft ein Slot weniger für alle Spieler zur Verfügung. Dies ist die beliebteste Einstellung.

4.4.4.3. reserve_type 2

Unter Annahme des Beispiels aus „reserve_type 0“ würde ein Admin bei der Einstellung 2 vorzugsweise einen reservierten Platz einnehmen. Sind 3 Admins auf dem Server, alle 14 Plätze sind belegt und ein Admin, der einen reservierten Slot hatte, geht vom Server, bekommt der Admin auf dem öffentlichen Platz den reservierten zugewiesen. Es ist dann also wieder ein öffentlicher Platz frei (s.a. Abbildung 4.1).

Die Einstellung 2 hat den Vorteil, dass, sofern nicht der Server voll ist, immer Admins auf den Server kommen können. Allerdings kann man die volle Slotanzahl auf dem Server nur nutzen, wenn auch mindestens soviele Admins wie reservierte Plätze spielen. Ist der Server voll, kann auch kein Admin mehr connecten. Die Einstellung lohnt sich, wenn wenige Admins häufig spielen.

4.4.5  Namen reservieren

Es hindert niemanden auf dem Server den Namen eines Admins anzunehmen. Auch wenn er dadurch keine Rechte auf dem Server bekommt, könnte der entsprechende Spieler mit der Identität des Admins durch auffälliges Verhalten dessen Ruf verschlechtern. Dafür bietet Admin Mod die Möglichkeit den eigenen Namen zu reservieren.

Folgender Eintrag in der users.ini verhindert, dass jemand den eigenen Namen verwendet:

STEAM_0:1:9174:meinpasswort:94207
[WING] Black Knight:zufälligespasswort:16384

Der erste Eintrag ist der übliche Eintrag mit einer Steam-ID. Der zweite Eintrag reserviert mit dem Recht 16384 den Namen „[WING] Black Knight“ mit einem zufällig ausgesuchten Passwort. Das Passwort kann man wählen, wie man will. Wichtig ist, dass es keiner erraten kann. Jeder, der den Namen annehmen will, wird vom Server gekickt. Man beachte aber, dass der zugehörige Accesslevel im ersten Eintrag das Recht 16384 beinhalten muss. Sollte dies nicht der Fall sein, sucht Admin Mod nach der erfolgreichen Erkennung als Admin weiter und wirft den Admin anschließend vom Server, da er das zufällige Passwort nicht gesetzt hat und auch nicht setzen kann.

Das Ganze kann man für alle Clanmitglieder wiederholen, was aber sehr arbeitsintensiv sein sein kann. Eleganter erreicht man das, indem man mittels RegEx gleich den Clantag reserviert, Abschnitt 4.4.6.

4.4.6  RegEx (Clantags reservieren etc.)

4.4.6.1. Einführung

Was sind Regular Expressions (RegEx)? Der deutsche Begriff „reguläre Ausdrücke“ ist zunächst ebenfalls nicht weiterführend.

Mit regulären Ausdrücken kann man nach Mustern in einer Zeichenkette (String) suchen. Der RegEx ist dabei das Muster. Das Muster muss dabei nicht aus einer Zeichenabfolge bestehen sondern kann auch sogenannte Steuerzeichen beinhalten. Diese Steuerzeichen sind ganz normale Zeichen, die RegEx aber als Befehl interpretiert.

Vom Betriebssystem kennt man das Globbing. Dieses besitzt zwei Steuerzeichen. Zum einen ist das der Asterisk „*“ für eine Zeichenkette beliebiger Länge und das Fragezeichen „?“ für eine beliebige Zeichenkette der Länge 1.

Sucht man beispielsweise nach einer Datei mit der Endung „.exe“, gibt man in der Suche „*.exe“ ein. Sucht man hingegen alle Dateien mit der Endung „.exe“ und nur einem Buchstaben vor dem Suffix (z.B. „a.exe“), dann gibt man „?.exe“ an.

RegEx nutzt ebenfalls Steuerzeichen. Allerdings sind das deutlich mehr und andere, bzw. sie haben eine andere Bedeutung.

Der Punkt „.“ ist im RegEx vergleichbar mit dem „?“ beim Globbing. „.*“ hingegen bedeutet, dass beliebig viele oder aber auch keine Zeichen gefunden werden. Dies entspricht dem Asterisk beim Globbing.

Will man, wie im oberen Globbing-Beispiel, nach Dateien mit der Endung „.exe“ suchen, so hätte man das Problem, dass der Punkt ja jedes beliebige Zeichen bedeuten kann. Man muss also kenntlich machen, dass es sich beim Punkt diesmal nicht um ein Steuerzeichen handelt. Dazu muss man den Punkt „escapen“. Dies wird mit einem vorangestellten Backslash „\„ erreicht. Ein möglicher RegEx lautet demnach „.*\.exe“.

Weitere interessante Steuerzeichen wären „^“ und „$“.

„^“ bedeutet, dass der nachfolgende RegEx am Anfang der durchsuchten Zeichenkette stehen muss. „^Admi“ wird in „Admin Mod“ gefunden „^od“ jedoch nicht, da „od“ nicht am Anfang der Zeichenkette steht.

„$“ hingegen macht das Gleiche für das Ende der Zeichenkette. „Admi$“ wird nicht in „Admin Mod“ gefunden, „od$“ jedoch sehr wohl, da es am Zeichenkettenende steht.

Die eckigen Klammer („[„ und „]“) geben eine Optionsmenge an. „[Aa]“ bedeutet, dass entweder ein großes oder ein kleines „A“ gesucht wird. Wendet man dieses RegEx auf das obige Beispiel „Admin Mod“ an, so würde es gefunden, während ein „a“ keine Übereinstimmung findet. Man kann es aber auch negieren, also nach Zeichen suchen, die nicht vorhanden sein sollen („^[Aa]“). Man kann aber auch Bereiche angeben, z.B. [a-z] oder [0-9], alle Kleinbuchstaben oder die Zahlen von 0-9. Bei ersterem werden Umlaute nicht erfasst.

Admin Mod benutzt Extended (oder Modern) Regular Expressions nach POSIX 1003.2. Diese werden jedoch case-insensitive gesucht (Groß- und Kleinschreibung wird nicht unterschieden).

Weitere und ausführlichere Informationen zu RegEx sind im Internet zu finden⁴.

4.4.6.2. Clantag reservieren

Ein Clantag ist nur ein Teil des eigenen Namens. Er weist einen jedoch indirekt als Mitglied des Clans und auf dem eigenen Server auch als Admin aus. Es ist dementsprechend auch nicht gewollt, dass ein Nicht-Mitglied so tut, als ob er Mitglied bzw. Admin auf dem Server ist.

Einerseits kann man wie im vorherigen Abschnitt 4.4.5 beschrieben, den Namen jedes einzelnen Spielers inklusive Clantag reservieren. Dies ist auf der einen Seite unbequem und hat zudem den Nachteil, dass Kombinationen mit dem Clantag und nicht reservierten Namen möglich sind. Es lohnt sich daher für die meisten nur den Clantag zu reservieren.

Zunächst sind RegEx in der adminmod.cfg zu aktivieren (use_regex 1) und alle Spieler in die users.ini einzutragen. Als LETZTEN Eintrag schreibt man den Clantag mit einem x-beliebigen Passwort und dem Recht 16384 zum Reservieren dieses Namens. Das Passwort sollte auf jeden Fall von niemanden zu erraten sein. Es wird auch von keinem Admin gebraucht.

Jeder Admin in der users.ini, der Clanmitglied ist, muss mit dem Recht 16384 (Namensreservierung) ausgestattet sein. Anderenfalls wird er bei Verwendung des Clantags gekickt. Admin Mod scannt die users.ini nach der Adminerkennung weiter.

Der Clantag-Eintrag muss der letzte Eintrag sein. Sollten weitere Clanmitglieder in der users.ini folgen, würden sie bereits von der Clantagerkennung gekickt werden, bevor sie sich als Admin authentifizieren können.

Clantags bestehen meist aus diversen Sonderzeichen, die der RegEx-Algorithmus als Steuerzeichen ansieht, d.h. es kommt zu einer kompletten Missinterpretation. Daher muss jedes Sonderzeichen „escaped“ werden. Dies geschieht über einen Backslash „\„. Im Falle des Clans [WING] sind die eckigen Klammern ein Problem. Daher müsste man zum schützen des Clantags z.B. schreiben:

\[WING\]:sdjgfsjg:16384

„Escaped“ werden müssen folgende Zeichen „*, +, ?, ., (, ), [, ], {, }, \, |, ^, $“.

Verwendet man zusätzlich weitere Namen in der users.ini, müssen auch die dort verwendeten Sonderzeichen „escaped“ werden. Dies gilt nicht für IDs oder IPs. Hier erkennt Admin Mod, dass es sich nicht um Namen handelt und wendet RegEx nicht an.

4.5  Benutzbare Maps einstellen (maps.ini)

Die maps.ini schränkt die Benutzung von Maps mittels admin_map oder Mapvotes ein. Ausschließlich Maps, die in dieser Datei stehen, dürfen dann benutzt werden. Anderenfalls bekommt man bei admin_map o.ä. die Rückmeldung „bad mapname“.

Die Verwendung einer solchen Datei ist jedoch OPTIONAL. Um die Funktion abzuschalten setzt man:

maps_file 0

Will man hingegen die Verwendung bestimmter Maps einschränken, schreibt man:

maps_file “addons/adminmod/config/maps.ini”

Wahlweise kann man natürlich auch einen anderen Pfad oder Dateinamen wählen.

Die Maps werden genau wie in der mapcycle.txt Datei aufgeführt, z.B.:

de_dust
de_inferno
de_dust2
cs_office

Daraus ergibt sich natürlich auch eine nette Möglichkeit die benutzbaren Maps auf die im Mapcycle zu beschränken. Man muss lediglich den aktuellen Mapcycle als maps.ini definieren:

maps_file “mapcycle.txt”

Das Einbinden weiterer Dateien mittels Include-Anweisung ist leider nicht möglich.

4.6  IPs für reservierte Slots festlegen (ips.ini)

Die ips.ini beinhaltet IP-Adressen, die stets Zugang zu reservierten Slots haben (siehe auch: reserve_type und reserve_slots) und ist OPTIONAL. Über die users.ini lassen sich zwar einzelnen IPs reservierte Slots zuweisen, allerdings ist es dort nicht möglich IP-Bereiche festzulegen.

Interessant dürfte eine solche Datei für Internetcafes sein, die in ihrem Netz einen Gameserver mit Internetanschluss betreiben. Den eigenen Rechnern möchte man natürlich Vorrang geben, ohne gleich Adminrechte zu vergeben. Genauso könnte man auch einen HLTV den Zugang zu einem vollem Server ermöglichen.

Für die meisten Spieler im Internet ist die IP jedoch nicht nützlich, da sie dynamisch bei jeder Einwahl vergeben wird, man also stets eine neue IP erhält.

Die ips.ini wird über ips_file definiert; in der Regel schreibt man das folgendermaßen:

ips_file “addons/adminmod/config/ips.ini”

Es ist natürlich auch jeder andere relative Pfad oder Dateiname möglich. Will man die Datei nicht benutzen, so schreibt man:

ips_file 0

Einzelne IPs trägt man folgendermaßen in die Datei ein:

129.49.231.126
131.112.1.12
71.17.235.3
172.54.512.7

Nutzt man Subnets, so kann man auch das berücksichtigen lassen:

129.49.231.126/255.255.255.0

Um beispielsweise die IPs von 168.23.21.0 bis 168.23.21.255 für die reservierten Slots zu erlauben, schreibt man den Bereich mit einer 0 am Ende:

168.23.21.0/255.255.255.0

Das kann man natürlich auch auf größere Netzwerke ausweiten:

168.23.0.0/255.255.0.0

Weitere Dateien lassen sich mit der Include-Anweisung einbinden, z.B.:

#include “ipadmins.ini”

Steht dieser Eintrag in der ips.ini, sucht Admin Mod auch noch in der ipadmins.ini (im gleichen Verzeichnis) nach weiteren IPs (vergl. plugin_ini).

Änderungen an der ips.ini werden erst bei einem Serverneustart, einem Mapwechsel oder vorzugsweise beim Ausführen des Befehls admin_reload übernommen.

4.7  Models reservieren (models.ini)

Die models.ini ist eine OPTIONALE Datei. Sie kann bestimmte Models mittels Passwort vor der Benutzung durch andere Spieler schützen.

Sie wird mittels der Variablen models_file gesetzt, z.B.:

models_file “addons/adminmod/config/models.ini”

Der relative Pfad sowie der Dateiname können frei gewählt werden.

Um den Modelschutz abzuschalten schreibt man hingegen:

models_file 0

Einträge in die models.ini werden nach folgendem Muster durchgeführt:

model:passwort

Das Passwort ist das gleiche, das auch in der users.ini beim entsprechenden Spieler vermerkt ist. Bei Verwendung von verschlüsselten Passwörtern in der users.ini müssen diese in der models.ini ebenfalls verschlüsselt angegeben werden.

Beispiele:

sas:meinampasswort

Limitiert die Benutzung des CT-Models „sas“ aus Counter-Strike auf Spieler mit dem Passwort „meinampasswort“ in der users.ini.

hostage1:gsddkakfla
hostage2:gsddkakfla
hostage3:gsddkakfla

Verhindert das Benutzen von Hostage-Models zum Cheaten in CS. Das Passwort muss irgendetwas nicht zu Erratenes sein. Vermutlich besteht die Cheat-Möglichkeit inzwischen nicht mehr.

Der Nutzen dieser Datei ist einschränkt. Sollen Spieler mit unterschiedlichen Passwörtern in der users.ini das gleiche Model reserviert bekommen, wird dies nicht funktionieren, da nur ein Passwort dem Model zugeordnet werden kann. In Mods mit wenigen Models (insbesondere in Teamspielen wie Counter-Strike oder Day of Defeat) ist die Verwendung der models.ini daher nicht sinnvoll. Haben alle Admins in der users.ini jedoch das gleiche Passwort (bei Verwendung der Steam-ID durchaus akzeptabel), kann auch dem Clan ein Model zugeordnet werden.

Ein weiterer Punkt ist, dass ein Spieler bei Auswahl eines geschützten Models direkt vom Server gekickt wird. Dies ist eventuell nicht unbedingt im Sinne vieler Admins.

Weitere Dateien lassen sich mit der Include-Anweisung einbinden, z.B.:

#include “modelsadmins.ini”

Steht dieser Eintrag in der models.ini, sucht Admin Mod auch noch in der modelsadmins.ini (im gleichen Verzeichnis) nach weiteren Models (vergl. plugin.ini).

Änderungen an der models.ini werden erst bei einem Serverneustart, einem Mapwechsel oder vorzugsweise beim Ausführen des Befehls admin_reload übernommen.

4.8  Chat zensieren (wordlist.txt)

Es gibt eine Möglichkeit mit Admin Mod zu verhindern, dass bestimmte Worte auf dem Server im Chat geschrieben werden. Beschimpfungen und Ähnliches können zensiert werden.

Dies geschieht über das Plugin Retribution, welches zu den Standardplugins gehört, und der wordlist.txt Datei.

In die wordlist.txt schreibt man einfach die Wörter untereinander, die nicht im Chat auftauchen sollen:

Idiot
Nap
Naps

Aktiviert wird die Funktion über die adminmod.cfg beispielsweise folgendermaßen:

words_file “addons/adminmod/config/wordlist.txt”

Deaktiviert wird die Zensur wie folgt:

words_file 0

Die Liste wird case-insensitive (also ohne Unterschied zwischen Groß- und Kleinschreibung) überprüft. Änderungen werden erst nach einem Serverrestart, einem Mapwechsel oder nach dem Aufruf von admin_reload aktiv.

Allerdings können bereits kleinste Änderungen die Liste umgehen:

N.aps

Dies ist immer noch lesbar, aber wird nach obiger Liste auf Grund des zusätzlichen Punktes nicht als Beschimpfung erkannt.

4.9  Pluginspezifische Einstellungen (vault.ini)

Die vault.ini dient der Speicherung von Plugineinstellungen. Insbesondere Customplugins machen oftmals Gebrauch davon.

Grundsätzlich sollte ein guter Pluginauthor dem User über Befehle im Plugin die Einstellungen ohne direkten Zugriff ermöglichen. Manchmal muss man aber auch manuell Hand anlegen.

Aktiviert wird die vault.ini in der adminmod.cfg:

admin_vault_file “addons/adminmod/config/vault.ini”

Zum Abschalten der vault.ini trägt man ein:

admin_vault_file 0

Das ist allerdings auf Grund der oftmaligen Nutzung nicht zu empfehlen.

Manuelle Änderungen sollten nicht während des Serverbetriebes vorgenommen werden. Sollte kurz nach der Änderung ein Plugin in die vault.ini schreiben, so sind die Änderungen verschwunden. Die gesamten Einstellungen werden nämlich von Admin Mod beim Mapstart in den Speicher geladen und stets am Stück zurückgeschrieben. D.h. bei manueller Änderung gelangt diese nicht sofort in den Speicher. Dies kann man nur über einen Mapchange oder admin_reload erreichen.

4.10  MySQL Installation einrichten

Es wird davon ausgegangen, dass Admin Mod bereits in einer Fallback-Konfiguration (Benutzung von Dateien) läuft. Eine Anleitung ist in Kapitel 3.4 zu finden.

In Admin Mod-MySQL können die Dateien users.ini, models.ini, ips.ini, wordlist.txt und plugin.ini durch Tabellen ersetzt werden. Es kann aber auch eine Mischinstallation durchgeführt werden. In der Regel wird nur die users und tags Tabelle benötigt. Besonderes Augenmerk sollte man auf die users.ini haben. Diese wird aufgeteilt in eine users- und eine tags-Tabelle. Admin Mod bietet die Möglichkeit über RegEx den eigenen Clantag zu schützen. Da Regex unter SQL ein sehr rechenintensiver Befehl ist, wenn er auf große Datenbestände losgelassen wird, empfiehlt es sich die Benutzung auf eine kleine überschaubare Tabelle zu limitieren, die nur die zu schützenden Clantags beinhaltet.

Auch wenn Tabellen genutzt werden, ist es immer gut auch eine einfache funktionierende Konfiguration basierend auf Dateien zu besitzen, da Admin Mod bei Verbindungsverlust zum MySQL-Server dann auf diese zurückgreifen kann.

Im Weiteren wird die Einrichtung der Tabellen in der MySQL-Datenbank näher beleuchtet.

4.10.1  Datenbankeinrichtung

Sofern noch keine Datenbank für Admin Mod eingerichtet wurde, sollte man dies tun.

mysql> CREATE DATABASE adminmod;

Als Datenbanknamen kann man statt „adminmod“ auch jeden anderen Namen angeben. Admin Mod kann aber auch in jede bestehende Datenbank eingebaut werden. Dabei sind allerdings eventuelle Überschneidungen bei Tabellennamen zu berücksichtigen und anzupassen. Der Datenbankname ist unter mysql_database in der adminmod.cfg anzugeben.

4.10.2  Users-Tabelle

Die Users-Tabelle wird als Ersatz für die users.ini eingerichtet. Sie besteht aus den Spalten „nick“, „pass“ und „access“. Äquivalent zur Angabe in der users.ini handelt es sich dabei um den Usernamen oder ID, das zugehörige Passwort und den Rechten des Users.

mysql> CREATE TABLE users( nick VARCHAR(31) PRIMARY KEY NOT NULL,
pass VARCHAR(64) NOT NULL, access INTEGER UNSIGNED NOT NULL);

Der Tabellenname muss in der adminmod.cfg unter mysql_dbtable_users angegeben werden. Es ist daher auch möglich einen anderen Namen für die Users-Tabelle zu wählen.

4.10.3  Tags-Tabelle

Wie bereits beschrieben ist die Verwendung von RegEx innerhalb großer Datenbeständen ineffizient. Daher sollten zu schützende Clantags in diese Extratabelle geschrieben werden. Diese sollte dadurch erheblich kleiner ausfallen. Angelegt wird sie natürlich genauso wie die Users-Tabelle.

mysql> CREATE TABLE tags( tag VARCHAR(30) PRIMARY KEY NOT NULL,
pass VARCHAR(64) NOT NULL, access INTEGER UNSIGNED NOT NULL );

Der Tabellenname muss in der adminmod.cfg unter mysql_dbtable_tags angegeben werden. Es ist daher auch möglich einen anderen Namen für die Tags-Tabelle zu wählen.

4.10.4  Models-Tabelle

Die Models-Tabelle wird als Ersatz für models.ini eingerichtet. Sie besteht aus den Spalten „nick“ und „pass“. Äquivalent zur Angabe in der models.ini handelt es sich dabei bei „nick“ um den Modelnamen und bei „pass“ um das Passwort.

mysql> CREATE TABLE models( nick VARCHAR(20) PRIMARY KEY NOT NULL,
pass VARCHAR(64) NOT NULL );

Der Tabellenname muss in der adminmod.cfg unter mysql_dbtable_models angegeben werden. Es ist daher auch möglich einen anderen Namen für die Models-Tabelle zu wählen.

4.10.5  Ips-Tabelle

Die Ips-Tabelle wird als Ersatz für ips.ini eingerichtet. Sie besteht nur aus der Spalte „ip“. Einträge in diese Tabelle sind identisch zur ips.ini.

mysql> CREATE TABLE ips( ip VARCHAR(22) NOT NULL );

Der Tabellenname muss in der adminmod.cfg unter mysql_dbtable_ips angegeben werden. Es ist daher auch möglich einen anderen Namen für die Ips-Tabelle zu wählen.

4.10.6  Words-Tabelle

Die Words-Tabelle wird als Ersatz für wordlist.txt eingerichtet. Sie besteht nur aus der Spalte „word“. Einträge in diese Tabelle sind identisch zur wordlist.txt.

mysql> CREATE TABLE words( word VARCHAR(30) NOT NULL );

Der Tabellenname muss in der adminmod.cfg unter mysql_dbtable_words angegeben werden. Es ist daher auch möglich einen anderen Namen für die Words-Tabelle zu wählen.

4.10.7  Plugins-Tabelle

Die Plugins-Tabelle wird als Ersatz für plugin.ini eingerichtet. Sie besteht nur aus der Spalte „plugin“. Einträge in diese Tabelle sind identisch zur plugin.ini.

mysql> CREATE TABLE plugins( plugin VARCHAR(100) NOT NULL );

Der Tabellenname muss in der adminmod.cfg unter mysql_dbtable_plugins angegeben werden. Es ist daher auch möglich einen anderen Namen für die Plugins-Tabelle zu wählen.

4.10.8  Zugriff auf die Datenbank

Nachdem die MySQL-Datenbank nun mit den Tabellen ausgestattet ist, muss Admin Mod noch mitgeteilt bekommen, wo und wie es diese erreichen kann. Dazu müssen in der adminmod.cfg folgende Variablen gesetzt sein:

mysql_host (IP-Adresse Datenbankrechner, meist „localhost“)
mysql_user (Username zum Zugriff auf die Datenbank)
mysql_pass (Passwort zum Zugriff auf die Datenbank)

4.10.9  Außergewöhnliche Einstellungen

Es gibt noch Einstellungen, die nur sehr selten gebraucht werden, die aber erwähnt werden sollten.

mysql_preload legt fest, ob alle Spieler beim Mapwechsel in den Speicher von Admin Mod geladen werden (Einstellung: 1) oder aber bei jedem Spielerconnect eine Datenabankabfrage durchgeführt wird (Einstellung: 0). Ersteres lohnt sich bei „wenigen“ Spielern und/oder nur wenigen Änderungen in der Datenbank. Letzteres ist die flexiblere Lösung, da Änderungen in der Datenbank sofort beim nächsten Connect aktiv sind. Häufige Datenbankabfragen müssen jedoch in Kauf genommen werden, was ggf. für Verzögerungen im Spielverlauf (Lags) sorgen kann. Dies ist aber eine sehr hypothetische Einschränkung, so dass man stets den Preload abschalten sollte. Sollte es Probleme geben, kann man immer noch wechseln.

Schaltet man den Preload der Daten ab, eröffnet sich einem die Möglichkeit auch nicht standardkonforme SQL-Abfragen durchzuführen. Dies geschieht mittels der Variablen:

mysql_users_sql
mysql_tags_sql

Die Verwendung der Variablen ist nicht trivial, so dass nur Profis und Frustrationstolerante sich daran versuchen sollten. Wer den Preload weiterhin verwenden möchte oder sich nicht so mit der von Admin Mod erwarteten Syntax auskennt, der kann sich ggf. mit MySQL-Views (Version 5.0.1 oder neuer notwendig) behelfen. Auf die einzelnen Möglichkeiten soll im Abschnitt 4.12 am Beispiel der Einbindung Admin Mods in die beliebte Forumsoftware phpBB⁵ eingegangen werden.

4.11  PostgreSQL Installation einrichten

Es wird davon ausgegangen, dass Admin Mod bereits in einer Fallback-Konfiguration (Benutzung von Dateien) läuft. Eine Anleitung ist in Kapitel 3.4 zu finden.

In Admin Mod-PostgreSQL können die Dateien users.ini, models.ini, ips.ini, wordlist.txt und plugin.ini durch Tabellen ersetzt werden. Es kann aber auch eine Mischinstallation durchgeführt werden. In der Regel wird nur die users und tags Tabelle benötigt. Besonderes Augenmerk sollte man auf die users.ini haben. Diese wird aufgeteilt in eine users- und eine tags-Tabelle. Admin Mod bietet die Möglichkeit über RegEx den eigenen Clantag zu schützen. Da Regex unter SQL ein sehr rechenaufwendiger Befehl ist, wenn er auf große Datenbestände losgelassen wird, empfiehlt es sich die Benutzung auf eine kleine überschaubare Tabelle zu limitieren, die nur die zu schützenden Clantags beinhaltet.

Auch wenn Tabellen genutzt werden, ist es immer gut auch eine einfache funktionierende Konfiguration basierend auf Dateien zu besitzen, da Admin Mod bei Verbindungsverlust zum PostgreSQL-Server auf diese dann zurückgreifen kann.

Im Weiteren wird die Einrichtung der Tabellen in der PostgreSQL-Datenbank näher beleuchtet.

4.11.1  Datenbankeinrichtung

Sofern noch keine Datenbank für Admin Mod eingerichtet wurde, sollte man dies tun.

$ createdb adminmod;

Als Datenbanknamen kann man statt „adminmod“ auch jeden anderen Namen angeben. Admin Mod kann aber auch in jede bestehende Datenbank eingebaut werden. Dabei sind allerdings eventuelle Überschneidungen bei Tabellennamen zu berücksichtigen und anzupassen. Der Datenbankname ist unter pgsql_database in der adminmod.cfg anzugeben.

4.11.2  Users-Tabelle

Die Users-Tabelle wird als Ersatz für die users.ini eingerichtet. Sie besteht aus den Spalten „nick“, „pass“ und „access“. Äquivalent zur Angabe in der users.ini handelt es sich dabei um den Usernamen oder ID, das zugehörige Passwort und den Rechten des Users.

adminmod=> CREATE TABLE users( nick VARCHAR(31) PRIMARY KEY NOT NULL,
pass VARCHAR(64) NOT NULL, access INTEGER UNSIGNED NOT NULL);

Der Tabellenname muss in der adminmod.cfg unter pgsql_dbtable_users angegeben werden. Es ist daher auch möglich einen anderen Namen für die Users-Tabelle zu wählen.

4.11.3  Tags-Tabelle

Wie bereits beschrieben ist die Verwendung von RegEx innerhalb großer Datenbeständen ineffizient. Daher sollten zu schützende Clantags in diese Extratabelle geschrieben werden. Diese sollte dadurch erheblich kleiner ausfallen. Angelegt wird sie natürlich genauso wie die Users-Tabelle.

adminmod=> CREATE TABLE tags( tag VARCHAR(30) PRIMARY KEY NOT NULL,
pass VARCHAR(64) NOT NULL, access INTEGER UNSIGNED NOT NULL );

Der Tabellenname muss in der adminmod.cfg unter pgsql_dbtable_tags angegeben werden. Es ist daher auch möglich einen anderen Namen für die Tags-Tabelle zu wählen.

4.11.4  Models-Tabelle

Die Models-Tabelle wird als Ersatz für models.ini eingerichtet. Sie besteht aus den Spalten „nick“ und „pass“. Äquivalent zur Angabe in der models.ini handelt es sich dabei bei „nick“ um den Modelnamen und bei „pass“ um das Passwort.

adminmod=> CREATE TABLE models( nick VARCHAR(20) PRIMARY KEY NOT NULL,
pass VARCHAR(64) NOT NULL );

Der Tabellenname muss in der adminmod.cfg unter pgsql_dbtable_models angegeben werden. Es ist daher auch möglich einen anderen Namen für die Models-Tabelle zu wählen.

4.11.5  Ips-Tabelle

Die Ips-Tabelle wird als Ersatz für ips.ini eingerichtet. Sie besteht nur aus der Spalte „ip“. Einträge in diese Tabelle sind identisch zur ips.ini.

adminmod=> CREATE TABLE ips( ip VARCHAR(22) NOT NULL );

Der Tabellenname muss in der adminmod.cfg unter pgsql_dbtable_ips angegeben werden. Es ist daher auch möglich einen anderen Namen für die Ips-Tabelle zu wählen.

4.11.6  Words-Tabelle

Die Words-Tabelle wird als Ersatz für wordlist.txt eingerichtet. Sie besteht nur aus der Spalte „word“. Einträge in diese Tabelle sind identisch zur wordlist.txt.

adminmod=> CREATE TABLE words( word VARCHAR(30) NOT NULL );

Der Tabellenname muss in der adminmod.cfg unter pgsql_dbtable_words angegeben werden. Es ist daher auch möglich einen anderen Namen für die Words-Tabelle zu wählen.

4.11.7  Plugins-Tabelle

Die Plugins-Tabelle wird als Ersatz für plugin.ini eingerichtet. Sie besteht nur aus der Spalte „plugin“. Einträge in diese Tabelle sind identisch zur plugin.ini.

adminmod=> CREATE TABLE plugins( plugin VARCHAR(100) NOT NULL );

Der Tabellenname muss in der adminmod.cfg unter pgsql_dbtable_plugins angegeben werden. Es ist daher auch möglich einen anderen Namen für die Plugins-Tabelle zu wählen.

4.11.8  Zugriff auf die Datenbank

Nachdem die PostgreSQL-Datenbank nun mit den Tabellen ausgestattet ist, muss Admin Mod noch mitgeteilt bekommen, wo und wie es diese erreichen kann. Dazu müssen in der adminmod.cfg folgende Variablen gesetzt sein:

pgsql_host (IP-Adresse Datenbankrechner, meist „localhost“)
pgsql_user (Username zum Zugriff auf die Datenbank)
pgsql_pass (Passwort zum Zugriff auf die Datenbank)
pgsql_port (Port zum Zugriff auf die Datenbank)

4.11.9  Außergewöhnliche Einstellungen

Es gibt noch Einstellungen, die nur sehr selten gebraucht werden, die aber erwähnt werden sollten.

pgsql_preload legt fest, ob alle Spieler beim Mapwechsel in den Speicher von Admin Mod geladen werden (Einstellung: 1) oder aber bei jedem Spielerconnect eine Datenabankabfrage durchgeführt wird (Einstellung: 0). Ersteres lohnt sich bei „wenigen“ Spielern und/oder nur wenigen Änderungen in der Datenbank. Letzteres ist die flexiblere Lösung, da Änderungen in der Datenbank sofort beim nächsten Connect aktiv sind. Häufige Datenbankabfragen müssen jedoch in Kauf genommen werden, was ggf. für Verzögerungen im Spielverlauf (Lags) sorgen kann. Dies ist aber eine sehr hypothetische Einschränkung, so dass man stets den Preload abschalten sollte. Sollte es Probleme geben, kann man immer noch wechseln.

Schaltet man den Preload der Daten ab, eröffnet sich einem die Möglichkeit auch nicht standardkonforme SQL-Abfragen durchzuführen. Dies geschieht mittels der Variablen:

pgsql_users_sql
pgsql_tags_sql

Die Verwendung der Variablen ist nicht trivial, so dass nur Profis und Frustrationstolerante sich daran versuchen sollten. Wer den Preload weiterhin verwenden möchte oder sich nicht so mit der von Admin Mod erwarteten Syntax auskennt, der kann sich ggf. mit PostgreSQL-Views behelfen.

4.12  Beispiel: Admin Mod in phpBB integrieren (MySQL)

In diesem Abschnitt soll die Einbindung Admin Mods in ein bestehendes Content Management System (CMS) oder Webforum mit MySQL-Backend⁶ am Beispiel des populären Forums phpBB⁷ beschrieben werden. Dies hat den Charme, dass man die Userverwaltung bequem aus der Forumssoftware heraus durchführen kann.

Die vorgestellten Methoden haben nicht den Anspruch perfekt zu sein. Ich bin weder gelernter Informatiker noch kenne ich mich besonders gut in MySQL aus. Vielmehr soll ein Einstieg gegeben werden, der zu Ideen und Optimierung anregen soll.

4.12.1  Admin Mod einrichten

Wie in Abschnitt Users-Tabelle gezeigt, erwartet Admin Mod standardmäßig eine Spalte für den Namen/ID (nick), das Passwort (pass) und den Accesslevel (access). Davon steht zunächst einmal das Passwort als MD5-Hash in phpBB2 zur Verfügung. phpBB3 weist einen gravierenden Unterschied zu phpBB2 auf. Die MD5-Hashes werden nicht mehr als MySQL-Hash sondern als „Salted Hash“ (softwaremäßig nachverschlüsselt) gespeichert. Sie sind daher für Admin Mod nicht nutzbar. Dem entsprechend ist zunächst die Verschlüsselung (encrypt_password) richtig einzustellen:

phpBB2 (MD5-Hashes):
encrypt_password 2

phpBB3 (Plain-Text):
encrypt_password 0

Die weitere Beschreibung bezieht sich auf phpBB3. Im weiteren Verlauf des Kapitels werden jedoch einige Beispiele für phpBB2 gezeigt.

Die genutzte Tabelle muss in mysql_dbtable_users festgelegt werden und ist dabei in der Regel „phpbb_users“:

mysql_dbtable_users “phpbb_users”

Nun stimmen die Spaltennamen nicht überein, so dass vom Standardformat abgewichen werden muss (mysql_users_sql). Die Abfrage würde also vorläufig folgendermaßen lauten:

SELECT user_password AS pass, 0 AS access FROM %s WHERE username=’%s’ OR
username=’%s’

Es wird verglichen, ob der Nickname oder dessen Steam ID mit dem Nicknamen im Forum übereinstimmt. Ist das der Fall, wird das Passwort und der Accesslevel als „pass“ bzw. „access“ zurückgegeben.

Wie unschwer zu erkennen ist, hat phpBB kein Feld für den Accesslevel. In dieser Abfrage bekommen alle Spieler den Accesslevel 0. Mit phpBB3 ist es möglich userspezifische Profilfelder hinzuzufügen. Man fügt also ein INT-Feld („user_amaccess“, wird dann in „pf_user_amaccess“ umbenannt) hinzu, welches nur durch die Forenadministratoren editierbar ist (standardmäßig sollte es 0 oder 1 sein, s. default_access). Leider befindet sich der Inhalt des Feldes nicht in „phpbb_users“, was die Abfrage komplexer macht. Auch muss man in phpBB3 das Passwort als userspezifisches Feld anlegen, VAR-Feld (Länge 20, „user_password“ wird zu „pf_user_password“).

SELECT u2.pf_user_password AS pass, u2.pf_user_amaccess AS access FROM
%s AS u1, phpbb_profile_fields_data AS u2 WHERE u1.user_id = u2.user_id
AND (u1.username=’%s’ OR u1.username=’%s’)

Nun kann jeder Nickname oder jede Steam ID in der Datenbank wiedergefunden werden. Eine Steam ID als Nickname ist aber eher unerwünscht. Also wird noch ein weiteres Feld benötigt, das die Steam ID beinhaltet (VARCHAR, Länge 31, „user_steamid“), das vom User im Profil editierbar sein sollte.

SELECT u2.pf_user_password AS pass, u2.pf_user_amaccess AS access FROM
%s AS u1, phpbb_profile_fields_data AS u2 WHERE u1.user_id = u2.user_id
AND (u1.username=’%s’ OR u2.pf_user_steamid=’%s’)

Man kann die Abfrage auch beispielsweise auf bestimmte Gruppen (z.B. Clans) einschränken, so dass ein angemeldeter, normaler User ohne Passwort auf den Server kann bzw. die Server clanweise aus einer Datenbank verteilt werden können. Man könnte das Ganze auch mit den Tags weitertreiben und diese an bestimmte Gruppen binden, etc.

Betreibt man eine Community, könnte man auch auf Passwörter verzichten wollen. Dann muss man aber mühsam, die Abfrage des Usernamens unterbinden:

SELECT ” AS pass, u2.pf_user_amaccess AS access FROM %s AS u1,
phpbb_profile_fields_data AS u2 WHERE u1.user_id = u2.user_id AND
’%s’=’%s’ AND u2.user_steamid=’%s’

Es ist aber auch weiterhin zumindest bei der Übertragung das Passwort in einen MD5-Hash umzuwandeln:

u2.pf_user_password AS pass -→ MD5(u2.pf_user_password) AS pass

Dann muss aber auch encrypt_password 2 eingestellt werden.

4.12.2  Nutzung von Views

Je komplexer die Abfrage ist, desto schwieriger wird es die von Admin Mod aufgezwunge Syntax einzuhalten. Seit MySQL 5.0.1 ist es möglich sogenannte Views zu erstellen, die die komplexe Abfrage aufnehmen und somit Admin Mod nur noch mit der Standardabfrage genutzt werden muss.

Zunächst das Beispiel für die Einrichtung eines Views mit Passwortabfrage und ausschließlicher Steam ID Nutzung:

CREATE VIEW am_users AS SELECT u2.pf_user_steamid AS nick,
u2.pf_user_password AS pass, u2.pf_user_amaccess AS access FROM
phpbb_users AS u1, phpbb_profile_fields_data AS u2 WHERE
u1.user_id=u2.user_id

oder in diesem Fall ohne Passwortabfrage:

CREATE VIEW am_users AS SELECT u2.pf_user_steamid AS nick, ” AS pass,
u2.pf_user_amaccess AS access FROM phpbb_users AS u1,
phpbb_profile_fields_data AS u2 WHERE u1.user_id=u2.user_id

Bitte nicht vergessen nun auf die Tabelle „am_users“ zu verweisen:

mysql_dbtable_users “am_users”

In den meisten Fällen würde ich Views vorziehen, da man mit Admin Mod nur sehr eingeschränkt auf Fehlersuche gehen kann. Sie sind aber kein Allheilmittel und stehen bei älteren MySQL-Versionen auch nicht zur Verfügung.

4.12.3  Nutzung von phpBB2

Wie bereits eingangs erwähnt, steht jedem die weitere Integration offen. Auch andere CMS oder Foren sind möglich. Es ist ebenfalls die Implementierung in phpBB2 möglich, wenngleich ungleich schwieriger, da zunächst ein Hack wie das Profile Control Center⁸ installiert werden muss. Weder dessen Installation noch Konfiguration sind trivial. Auch passt die Installationsanweisung teilweise nicht mehr zur aktuellen Version.

Abschließend die Admin Mod SQL-Abfrage für phpBB2 mit installiertem Profile Control Center und Passwortabfrage sowie den passenden View:

SELECT user_password AS pass, user_amaccess AS access FROM %s WHERE
username=’%s’ OR user_steamid=’%s’

CREATE VIEW am_users AS SELECT user_steamid AS nick, user_password AS
pass, user_amaccess AS access FROM phpbb_users