Wie wäre das: Die Map wechselt jede Runde hin- und her, ohne Ladebildschirm oder gar Serverneustart.
Klingt utopisch, ist es aber nicht. Im Folgenden erfahrt ihr, wie ihr das hinkriegt.
Das Hauptproblem dabei ist, dass sich fast alles an einer Map bei Rundenende zurücksetzt: prop_physics rücken an ihre Ursprungsposition, Explosions- bzw. Schussdecals werden gelöscht, alle Spieler teleportieren sich zu den Spawns usw. Es gibt also kaum eine Möglichkeit, eine Aktion der Map zu beeinflussen, die zwar in einer, nicht aber in einer anderen Runde automatisch stattfindet. Die einzige, die ich gefunden habe, ist das func_brush Entity, welches an- oder abgeschaltet werden kann. Das besondere dabei ist, dass es auch in der folgenden Runde seinen Zustand beibehält, d.h. deaktiviert man es, ist es auch in der nächsten Runde deaktiviert, obwohl es in der Map ursprünglich als aktiviert verzeichnet ist. Auf diesem Sachverhalt baut der gesamte Mechanismus auf. Jedoch reicht ein func_brush Entity nicht aus, schließlich muss sein an- oder abgeschalteter Zustand auch irgendwie „übersetzt“ werden, sodass man daraus einen Nutzen ziehen kann. Dies wird durch folgende Konstruktion erreicht:
Was ihr seht, ist ein sehr flacher func_brush (mit Nodraw belegt, Name „brush“, alle anderen Einstellungen nicht verändern), über und unter dem jeweils ein trigger_once liegt (Namen: „trigger_oben“ und „trigger_unten“). Zwischen dem func_brush und dem unteren Trigger ist dabei eine kleine Lücke.
Ganz knapp über dem func_brush ist ein weiterer Nodraw-Würfel, dies ist jedoch ein func_physbox (Name „physbox“, sonstige Einstellungen müssen nicht vorgenommen werden).
Außerdem sitzt daneben noch ein logic_auto (Name&Einstellungen nicht benötigt) und ein logic_relay (Name: relay, Einstellungen nicht verändern). Zu Showzwecken ist auch noch ein light (Name:“light“, Einstellungen beibehalten), vorhanden.
Diese ganze Apparatur befindet sich in einem komplett von der übrigen Map abgeschlossenen Raum. Ich habe wegen des Kontrastes die Umliegenden Brushes mit dev-Texturen belegt, normalerweise könnte das alles nodraw sein. Das light-Entity darf sich natürlich eigentlich nicht in diesem Raum befinden, denn dort kommt ja eh keiner hin. Auf meinem Screen ist es nur der Übersicht halber.
Im Folgenden sind die Einstellungen und Outputs für die Entities verzeichnet:
„logic_auto“:
Einstellungen:
-alles so lassen wie es ist-
Flags:
-alles so lassen wie es ist-
Outputs:
OnMapSpawn | trigger_oben | Enable | 3.00„trigger_oben“ (dies ist, wer hätte das gedacht, der obere Trigger):
Einstellungen:
Start Disabled | „Yes“
Flags:
Außschließlich ein Häkchen bei „Physics Objects“
Outputs:
OnTrigger | trigger_unten | Disable | 0.00
OnTrigger | brush | Disable | 0.00
OnTrigger | physbox | Kill | 0.00“trigger_unten”:
Einstellungen:
-alles so lassen wie es ist-
Flags:
Außschließlich ein Häkchen bei „Physics Objects“
Outputs:
OnTrigger | brush | Enable | 0.00
OnTrigger | relay | Trigger | 0.00
OnTrigger | physbox | Kill | 0.00“relay”:
Einstellungen:
-alles so lassen wie es ist-
Flags:
-alles so lassen wie es ist-
Outputs:
OnTrigger | light | TurnOff | 0.00Wer jetzt drei große Fragezeichen in den Augen stehen hat, für den hier die Erklärung:
Am Anfang, d.h. in der ersten Runde, ist das func_brush Entity vorhanden. Das func_physbox bleibt also darauf liegen und erreicht den unteren Trigger nicht. Nach drei Sekunden wird durch das logic_auto der obere trigger aktiviert. Warum erst jetzt? Weil er sonst auch ausgelöst würde, wenn das func_brush am Rundenstart ausgeschaltet wäre. So jedoch bleibt dem func_physbox genug Zeit herunterzufallen, sollte dies der Fall sein. Nach drei Sekunden wird also der obere Trigger angeschaltet und auch sogleich vom func_physbox getriggert. Dies bewirkt, dass der func_brush nun ausgeschaltet wird. Damit durch das dadurch ausgelöste Herunterfallen des func_physbox der untere Trigger nicht aktivert wird, wird dieser gleich vom oberen mit ausgeschaltet. Weitere Folgen gibt es in dieser Runde nicht.
Nächste Runde: die Trigger sowie das func_physbox werden in ihren ursprünglichen Zustand versetzt, d.h. das func_physbox spawnt wieder oben. Jedoch ist der func_brush letzte Runde deaktiviert worden, weshalb das func_physbox nun geradewegs nach unten fällt und somit den unteren, nicht aber den oberen Trigger auslöst. Die Folge: Der func_brush wird wieder aktiviert. Außerdem passiert noch etwas anderes: ein Licht wird ausgeschaltet.
Nächste Runde geht das Spielchen wieder von vorne los: Das func_physbox bleibt auf dem func_brush liegen und löst nach 3 Sekunden den oberen Trigger aus usw.
Der eigentliche Nutzen des ganzen wird erst bei dem Licht deutlich: dieses wird nun jede zweite Runde ausgeschaltet, sonst bleibt es an.
Das func_physbox wird übrigens nur gekillt, damit es nicht Performance für physikalische Berechnungen verbraucht, auch wenn das im Prinzip vernachlässigbar wenig ist.
_________________________________________
Der findige Mapper wird bereits herausgefunden haben: Der letzte Output (der vom logic_relay) ist nicht essentiell. Er bewirkt, dass ein Licht in der Map eine Runde an, die andere Runde aus, dann wieder an, aus, an usw. ist. Natürlich lassen sich mit der Apparatur aber noch ganz andere Dinge machen, als so schnödes Zeug wie Lichter an- und aus zu knipsen. Um mein Versprechen vom Anfang einzulösen und damit das hier nicht so kurz wird, gibt’s jetzt noch das Anwendungsbeispiel Mapwechsel dazu.
Die Sache ist relativ simpel: Man baut 2 Maps, die komplett voneinander durch das void abgetrennt sind. Schematisch:
In der einen Map setzt ihr richtige Spawnpunkte (info_player_terrorists/counterterrorist), die jeweils von einem einzelnen trigger_teleport umgeben sind. Bei jedem dieser trigger_teleports gebt ihr zwar denselben Namen („teleport“), aber unterschiedliche info_teleport_destinations unter "Remote Destination" an, welche ihr zuvor in der anderen Map (wir erinnern uns, es gibt ja 2 getrennte) an jene Stelle gepackt habt, wo normalerweise ein info_player_terrorists/counterterrorist sitzen würde. In dieser anderen Map darf es keine „echten“ Spawnpunkte geben, nur die info_teleport_destination’s, die ihr gesetzt habt.
Kleiner Tipp: Wer keine Lust hat, die „Remote Destination“ bei allen trigger_teleports selbst einzutippen, der macht einfach eines mitsamt info_teleport_destination komplett mit Einstellungen und allem drum und dran fertig, und kopiert dieses dann mit dem „Paste Special“-Befehl so oft wie benötigt, wobei ein Häkchen bei „make pasted entity names unique“ gesetzt sein muss. Dann macht der VHE automatisch die Paarungen fertig. Jedoch müsst ihr dann nachher noch mal alle trigger_teleports gleich benennen, da auch deren Namen „einzigartig“ gemacht wurden.
Dann müsst ihr nur noch die trigger_teleports bei „Start Disabled“ auf „Yes“ stellen, und beim logic_relay folgendes Output erstellen:
OnTrigger | teleport | Enable | 0.00Schon teleportieren sich in einer jeder zweiten Runde alle Spieler auf die andere Map.
Natürlich hat das ganze auch Nachteile, die man beachten muss:
- Die Skybox der beiden Maps muss dieselbe sein
- Man sieht auf dem Radar auch die Ziele der gerade nicht gespielten Map (Geiseln, Bombenplätze)
- Beim Starten der Map werden die Materials/Models beider Maps geladen
- Eventuell schlechtere Performance als bei einzelnen Maps, wenn man sich nicht die Mühe macht, alle Entities der nicht benutzten Map zu killen
- Beide 3d-Skyboxen werden auf beiden Maps berechnet (so man denn welche hat)
…
Mir fallen jetzt gerade keine mehr ein, aber es gibt wahrscheinlich noch ein paar…
Natürlich sind das jetzt bei weitem nicht alle Möglichkeiten, die man hat, um diese Apparatur auszunutzen. Andere Dinge wären z.b., dass die Schwerkraft sich jede Runde ändert, oder aber dass bestimmte Aktivitäten von Spielern einem Team in der nächsten Runden Vorteile verschaffen (Dazu muss die Konstruktion nicht ganz so kompliziert sein, man braucht nur einen Trigger unter dem func_brush, und das func_brush muss durch die o.g. Aktivitäten an- oder ausgemacht werden): Ihr seht, die Möglichkeiten sind enorm.
Das wars!
Ich hoffe, ich habe euch den Nutzen und den Gebrauch des Ganzen klargemacht, habt Spaß damit.
Sollte etwas unklar sein oder sollte ich etwas wichtiges vergessen haben, oder aber es fehlen euch weiterführende Informationen, so teilt dies bitte unverzüglich mit.
TheMoon
Beide Beispielmaps (Licht+Mapwechsel):
Download der Beispielmaps