B.  Sonstiges

B.1  Was macht eigentlich Setinfo?

Jeder kennt sicherlich Servervariablen (Beispiel: mp_timelimit). Diese Variablen sind fest in der Serversoftware verdrahtet. Man kann nur deren Wert verändern, z.B. in der server.cfg oder als Rcon-Befehl. Analog dazu gibt es auch festverdrahtete Clientvariablen (Beispiel: rate). Auch hier kann nur der Wert verändert werden (config.cfg oder Client-Console).

Jetzt nehmen wir an, dass eine Serverapplikation wie Admin Mod beim Client eine Variable auslesen möchte. Es gibt natürlich keine Möglichkeit Half-Life neu zu compilieren mangels Quellcode. Valve hat daher benutzerdefinierte Variablen eingeführt. Diese definiert man mittels des setinfo Befehls.

Anbei ein Beispiel für Sir Drink a lot’s Plugins. Über ein benutzerdefinierte Clientvariable liest es aus, ob der Client Customsounds hören will:

setinfo “am_sound” “0”

Man definiert hier eine Variable am_sound mit dem Wert 0. Es ist also nichts anderes als eine Variablendefinition unter SMALL (new am_sound=0). Wenn man diesen Befehl in der config.cfg verankert, wird man auf keinem Server mit Sir Drink a lot’s Plugins mehr von den zugehörigen Sounds genervt.

Woher weiß das Plugin aber, was der Client eingetragen hat? Dafür gibt es die Scripting-Funktion get_userinfo(). Damit kann man einige Clientvariablen auslesen bzw. alle mit setinfo definierten Variablen.

Man könnte jetzt auf die Idee kommen, jedes Plugin mit setinfo-Zeilen auszustatten (z.B. Plugin für Client an oder aus). Schließlich kann man diese Variablen einfach per execclient() Befehl beim Client in die config.cfg schreiben (soweit er sie nicht schreibgeschützt hat; das empfehle ich jedem, da es inzwischen offensichtlich Hobby geworden ist fremde Configs zu zerstören). Leider ist der Speicherbereich, der setinfo-Variablen zur Verfügung gestellt werden, sehr klein. Wer zuviele oder zu lange Variablen hat, bekommt oft ein „Info String Exceeded“ in seiner Console, meist verbunden mit einem „Name reserved“ und einem fluchenden Spieler, der Admin Mod dafür verantwortlich macht. Meist ist aber Statsme dafür verantwortlich, was meist 2 lange setinfos in der config.cfg hinterließ. Man mag soviel über die Additionsorgie unter Adminmod meckern, aber den Autoren war dieses Problem durchaus bewusst. Durch dieses System wird massiv Speicher gespart! Will man also setinfo in seinem Plugin verwenden, so sollte man dies nur tun, wenn man es als allgemeine Einstellungen für fast alle Plugins nutzen kann. Vielleicht nutzen ja mehr Plugin-Programmierer am_sound. Zu hoffen wäre es.

B.2  Interaktion zwischen HL Engine und GameDLL

Die HL Engine lädt beim Starten dynamisch eine GameDLL. Welche das ist, wird aus den Kommandozeilen Parameter -game und der liblist.gam Datei in dem angegebenen Verzeichnis ermittelt. Diese GameDLL ist verantwortlich für die Elemente des Spiels.

Engine ↔ GameDLL

Wenn in der liblist.gam die Metamod DLL angegeben ist, lädt die Engine die Metamod DLL. Der Engine ist es egal, was sie für eine DLL lädt, solange sie alle Funktionen bereithält, um erfolgreich geladen zu werden.

Da Metamod aber kein Spiel ist, muss irgendwo noch die GameDLL herkommen. Metamod schaut also nach, was die Engine für ein Spiel laden wollte, überprüft in seiner internen Liste, welche GameDLL dazu passt und lädt dann die GameDLL. Die Engine denkt sie unterhält sich mit der GameDLL, die GameDLL denkt sie unterhält sich mit der Engine, Metamod sitzt dazwischen und alle sind glücklich.

Engine ↔ Metamod ↔ GameDLL

Alte Bots, die keine Metamod Plugins sind, verhalten sich exakt so, wie es auch Metamod tut.

Engine ↔ BotDLL ↔ GameDLL

Wenn man also Metamod und Bots gleichzeitig laden will, dann müssen sie hintereinander geschaltet werden, denn nach oben (links) denkt jeder er sieht die Engine und nach unten (rechts) denkt jeder er sieht die GameDLL. Wenn Metamod also eine BotDLL lädt, dann tritt diese für Metamod als GameDLL auf, genauso wie das die BotDLL für die Engine tun würde. Man kann Metamod anweisen, eine andere GameDLL zu benutzen als die, die er normalerweise benutzen würde. In unserem Falle also eine BotDLL. Die Engine lädt Metamod als GameDLL. Metamod ist keine GameDLL und lädt daher die BotDLL als GameDLL. Die BotDLL ist auch keine GameDLL und lädt daher die GameDLL, in welcher jetzt tatsächlich das Spiel steckt.

Engine ↔ Metamod ↔ BotDLL ↔ GameDLL

Es geht auch andersherum:

Engine ↔ BotDLL ↔ Metamod ↔ GameDLL

Das hat aber den Nachteil, dass Metamod, und damit seine Plugins, keinen Einfluss mehr auf die BotDLL haben.

Frage: Wie soll jetzt Metamod eine zweite GameDLL laden, wenn a) nur eine GameDLL existieren kann (die BotDLL sieht für Metamod aus wie eine GameDLL) und b) diese in die Reihe passen muss, aber Metamod nur die Position rechts von sich beeinflussen kann?

Faktenlage B:
Um Metamod mitzuteilen, dass es eine andere GameDLL laden soll, als die, die es normalerweise aussuchen würde, setzt man ein Schlüssel-Wert Paar, die in der Liste namens „localinfo“. Als Schlüssel nimmt man dafür „mm_gamedll“ und der Wert enthält den Pfad zur GameDLL z.B. „podbot/podbot.dll“. Danach hat man folgende Liste:

(mm_gamedll, podbot/podbot.dll)

Metamod schaut nach, ob es einen Eintrag unter dem Schlüssel „mm_gamedll“ gibt, und verwendet diesen um die dort angegebene „Game“DLL zu laden. Die Kommandozeile

+localinfo mm_gamedll podbot/podbot.dll

legt dieses Paar unter diesem Schlüssel mit diesem Wert in der Engine an. Was passiert, wenn dieser Schlüssel zweimal mit einem Wert belegt wird?

+localinfo mm_gamedll podbot/podbot.dll +localinfo mm_gamedll
dummbot/dumm.dll

Da ein Schlüssel in nur genau einem Schlüssel-Wert Paar vorkommen kann (sonst wäre er ja nicht eindeutig), resultiert daraus logischerweise folgende Liste:

(mm_gamedll, dummbot/dumm.dll)

Die erste Paarbelegung wird durch ein erneutes Zuweisen überschrieben. Der letzte Eintrag gilt. Genauso wie, wenn in der server.cfg die selbe Cvar mehrfach belegt wird; es gilt nur die letzte Zuweisung.

Schlussfolgerung: Es ist technisch und logisch nicht möglich zwei GameDLL zu laden und es ist ebenso nicht möglich, zwei Paare unter demselben Schlüssel anzulegen.

Autor: Da Rope

B.3  Res-Dateien

Resourcendateien oder kurz RES-Dateien sind Textdateien, welche sich im Maps Verzeichnis des Mods befinden. Der Dateiname entspricht dem Mapnamen, wie zum Beispiel:

de_dust.res

Man benötigt derartige Dateien um Sounds, Texte oder Teile von Maps vom Server zum Client zu übertragen.

Wie bereits erwähnt sind RES-Dateien einfache Textdateien und können somit über jeden Editor wie beispielsweise Notepad erstellt oder verändert werden.

Da die RES-Dateien zum Übertragen von Dateien vom Server zum Client benutzt werden, müssen die zu übertragenden Dateien auf dem Server vorhanden sein. In der RES-Datei wird nun der Dateiname und der zugehörige Pfad relativ zum Mod Pfad angegeben.

Beispiel:
Angenommen es befindet sich eine Datei namens „woohoo.wav“ im Verzeichnis ...\cstrike\sound\misc\ des Servers. Diese soll zum Client übertragen, wenn zur Map de_dust gewechselt wird. Dazu muss eine Datei namens de_dust.res im Ordner maps des Servers erstellt werden und die folgende Zeile hineingeschrieben werden:

sound/misc/woohoo.wav

Mit jedem Mapwechsel wird die korrespondierende RES-Datei verarbeitet. Dazu muss sich die zugehörige Datei im Verzeichnis befinden, in dem sich die Map-Datei befindet.

Beispiel:
Wird zur Map de_dust gewechselt, wird nach einer Datei namens de_dust.res im Maps-Verzeichnis gesucht und diese dann (sofern vorhanden) verarbeitet.

Man muss nicht zu jeder Map im Maps-Ordner des Servers eine korrespondierende RES-Datei erstellen. Es bietet sich jedoch an, da einem Player der gerade den Server betritt in jedem Fall die Dateien übertragen werden.

Autor: Biohazard

Das Customplugin plugin_bk_res¹ kann bei der Erstellung der Dateien helfen.

B.4  HL-Sounds

Einige Sounds sind bereits in Half-Life vorhanden. Sie sind nicht in echten Verzeichnissen vorhanden, sondern werden aus den sogenannten PAK-Dateien geladen. Will man beispielsweise Barney sprechen lassen, kann man in der Serverconsole Folgendes eingeben:

speak barney/somethingstinky

Oder will man eine Frau sprechen lassen, dass noch 15 Sekunden verbleiben:

speak fvox/fifteen seconds remaining

Die Verwendung mit Admin Mod kann mit dem Customplugin plugin_speech² vereinfacht werden.

Alle folgenden Sounds sind bereits beim Spieler vorhanden, und müssen nicht heruntergeladen werden (Thema: Res-Dateien). Sie wurden von Kleen13 zusammengetragen³.

B.4.1  agrunt

B.4.2  ambience

B.4.3  apache

B.4.4  aslave

B.4.5  barnacle

B.4.6  barney

B.4.7  boid

B.4.8  bullchicken

B.4.9  buttons

B.4.10  common

B.4.11  controller

B.4.12  debris

B.4.13  doors

B.4.14  fans

B.4.15  fvox

B.4.16  garg

B.4.17  gman

B.4.18  gonarch

B.4.19  hassault

B.4.20  headcrab

B.4.21  hgrunt

B.4.22  holo

B.4.23  hornet

B.4.24  houndeye

B.4.25  ichy

B.4.26  items

B.4.27  leech

B.4.28  nihilanth

B.4.29  plats

B.4.30  player

B.4.31  roach

B.4.32  scientist

B.4.33  squeek

B.4.34  tentacle

B.4.35  tride

B.4.36  turret

B.4.37  vox

B.4.38  weapons

B.4.39  x

B.4.40  zombie