Hmmmm, ueberpruefen wir dieses Geruecht doch mal, indem wir nicht herumraten, sondern versuchen, logisch zu denken.
Faktenlage A:
Die HL Engine laedt beim starten dynamisch eine GameDLL. Welche das ist, kramt er sich aus dem Kommandozeilen Parameter -game und der liblist.gam Datei in dem angegebenen Verzeichnis zusammen. Diese GameDLL ist verantwortlich fuer die Elemente des Spiels.
Engine <-> GameDLL
Wenn in der liblist.gam die Metamod DLL angegeben ist, dann laedt die Engine halt die Metamod DLL. Der Engine ist es egal, was sie fuer eine DLL laedt, solange sie alle Funktionen bereithaelt, um erfolgreich geladen zu werden.
Da Metamod aber nun kein Spiel ist, muss irgendwo jetzt noch die GameDLL herkommen. Metamod schaut also nach, was denn die Engine fuer ein Spiel laden wollte, kuck in seine interne Liste, welche GameDLL dazu passt und laedt dann die GameDLL. Die Engine denkt sie unterhaelt sich mit der GameDLL, die GameDLL denkt sie unterhaelt sich mit der Engine, Metamod sitzt dazwischen und alle sind gluecklich.
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 muessen sie hintereinander geschaltet werden, denn nach oben (links) denkte jeder er sieht die Engine und nach unten (rechts) denkt jeder er sieht die GameDLL. Wenn Metamod also eine BotDLL laedt, dann tritt diese fuer Metamod als GameDLL auf, genauso wie das die BotDLL fuer die Engine tun wuerde. Man kann Metamod anweisen, eine andere GameDLL zu benutzen, als die, die er normalerweise benutzen wurde. In unserem Falle also eine BotDLL. Die Engine laedt Metamod als GameDLL. Metamod ist keine GameDLL und laedt daher die BotDLL als GameDLL. Die BotDLL ist auch keine GameDLL und laedt daher die GameDLL inwelcher jetzt tatsaechlich 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 fuer Metamod ja 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 wuerde, setzt man ein Schluessel-Wert Paar, die in der Liste namens "localinfo". Als Schluessel nimmt man dafuer "mm_gamedll" und der Wert enthaelt den Pfad zur GameDLL z.B. "podbot/podbot.dll". Danach habe ich also folgende Liste:
(mm_gamedll, podbot/podbot.dll)
Metamod schaut nach, ob es einen Eintrag unter dem Schluessel 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 Schluessel mit diesem Wert in der Engine an. Was passiert jetzt wohl, wenn ich diesen Schluessel zweimal mit einem Wert belege?
+localinfo mm_gamedll podbot/podbot.dll +localinfo mm_gamedll dummbot/dumm.dll
Da ein Schluessel in nur genau einem Schluessel-Wert Paar vorkommen kann (sonst waere er ja nicht eindeutig), resultiert daraus logischerweise folgende Liste:
(mm_gamedll, dummbot/dumm.dll)
Die erste Paarbelegung wird durch ein erneutes Zuweisen ueberschrieben. 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 moeglich zwei GameDLL zu laden und es ist ebenso nicht moeglich, zwei Paare unter demselben Schluessel anzulegen.
Und jetzt ab in die Schlule mit dir.
Blacky, koenne wir mal wieder den alten Smily vom letzte Borad haben?
)