Master-Eigenschaft in CS

An manchen Stellen möchte man für eine CS-Map vielleicht irgenetwas blockieren, bis eine bestimmte Aktion durchgeführt wurde. Man muss zum Beispiel einen Knopf drücken, damit eine Tür entriegelt wird.
Wir wissen vom HL-Mapping, dass für das Blockieren nur ein master-Eintrag in der Tür sowie eine genauso benannte multisource herangezogen werden können.
Da bei CS nun allerdings bei jeder Runde der Anfangszustand hergestellt werden soll, müsste diese multisource zurückgesetzt werden. Leider nimmt uns der CS-Code diese Selbstverständlichkeit nicht ab, sondern zwingt uns, komplexe Schaltungen zu bauen.


Für den Fall, dass ihr eigentlich nur einen Schalter wollt, der jede Runde höchstens einmal aktiviert werden kann, solltet ihr lieber dieses Tutorial verwenden.
Um in CS eine multisource zu bauen, die zu Rundenbeginn auf ihren Startwert geschaltet wird, bedienen wir uns der Tatsache, das eine Tür, die bei Rundenbeginn zurückgesetzt wird, ihr target noch einmal aktiviert.


Die benötigten Entitys sind:

Beginnen wir bei den 3 env_globals: Wofür sind die überhaupt gut? Ganz einfach: Sie können eine "Variable" schalten, und zwar je nach Einstellung auf ON (immer an), OFF (immer aus) und TOGGLE (wechseln).
Wir tragen als erstes bei allen drei env_globals folgende Werte ein:
(env_global1)
name . . . . . . . : master1init
global state to set: master1
trigger mode . . . : off
initial state  . . : off
              [x] set initial state

(env_global2)
name . . . . . . . : master1on
global state to set: master1
trigger mode . . . : on
initial state  . . : on

(env_global3)
name . . . . . . . : master1off
global state to set: master1
trigger mode . . . : off
initial state  . . : off
Diese drei env_globals werden nachher dafür sorgen, das die multisource richtig geschaltet ist. Man kann nämlich nicht einfach zwei trigger_relays auf die multisource zeigen lassen, diese würde ihren Zustand dann nur ändern wenn beide Relays gleichzeitig aktiviert sind, und wenn jedes einzelne einen anderen Status schalten soll, dann passiert garnix.
Gut, kümmern wir uns um die multisource: 
name . . . . . . . : multis1
target . . . . . . : (leer)
global state master: master1
Jetzt ist leicht zu erkennen, durch die env_globals verwaltet man einen Wert master1, der den Zustand der multisource bestimmt. Das erste env_global stellt dabei nur den Startwert ein. Fragt mich nicht, warum ich dafür drei env_globals vorschlage, aber bei mir hat es nicht funktioniert, wenn master1on gleichzeitig set inital state aktiviert hatte.
Jetzt benötigen wir die func_door, sie wird dafür sorgen das unser master1 immer wieder auf den Startwert gesetzt wird: 
name . . . . . . . : master1reset
render mode  . . . : texture
fx amt . . . . . . : 0
speed  . . . . . . : Breite der Tür * 2
delay before close : -1
target . . . . . . : master1off
            [x] passable
Optimalerweise verpasst ihr der Tür (bei ZHLT 2.5.x oder höher) auf 5 Seiten die Sky-Textur um r_speeds zu sparen. Auf 6 Seiten würden sich die Compiler beschweren... und das wollen wir ja nicht ;)
Der Speed ist einfach erklärt: er soll nicht unsinnig hoch sein, aber dennoch so hoch, das die Tür in weniger als einer Sekunde offen/zu ist.

Falls ihr euch jetzt fragt, wieso ich die Tür nicht einfach auf starts open stelle und statt target fire-on-close verwende: Bei mir wurde nur das Target beim Reset getriggert, nicht das fire-on-close.
Jetzt bauen wir noch einen multimanager, der zusätzlich einige Keys erhält: 
name . . . . . . . : master1act
(Smart Edit aus)
master1reset : 0
master1on    : 1
Der Multimanager aktiviert als erstes die reset-Tür, die auf jeden Fall multis1 auf off stellt. Eine Sekunde später wird dann aber multis1 (bzw dessen global state master) auf on gesetzt. Die Tür muss aber aktiviert werden, denn nur sie sorgt bei Rundenbeginn dafür, dass master1 wieder aus ist.

Jetzt könnt ihr der blockierten Tür (oder wem auch immer) als master multis1 spendieren. Um die multisource nun zu aktivieren, gebt ihr z.B. bei einem func_button als target master1act ein.
Wenn die multisource erst an und dann aus sein soll, müsst ihr einfach die trigger_states der drei env_globals entsprechend ändern.



Eine Anwendung für diese Schaltung ist z.B. eine Tür die das Gameplay verbessert:

Zu Rundenbeginn ist sie von links verschlossen, der rote Weg endet an der Tür, man kann nicht durch. Von der anderen Seite allerdings ist sie offen, so dass man den blauen Weg immer nehmen kann. Wenn jemand mindestens einmal den blauen Weg entlanggegangen ist, soll die Tür entriegelt sein und auch in violetter Richtung kann man durch, zumindest bis zum Ende der Runde.
Verwendbar ist das, um zum Beispiel einen kurzen Weg, der zu einem Vorteil führen würde, für eine der beiden Seiten solange zu blockieren, bis irgendjemand den langen Weg außenrum gegangen ist.

Beginnen wir einfach mit der oben genannten Schaltung.Zusätzlich benötigen wir eine func_door sowie auf jeder Seite einen trigger_multiple ein. Die Tür nennen wir einfach mal door1. Der trigger_multiple links vor der Tür bekommt folgende Einstellungen: 
target : door1
master : multis1
Der rechte trigger_multiple bekommt folgende Einstellungen: 
target : unlock1
Nicht wundern, das target unlock1 bauen wir jetzt:
Dafür nehmen wir einen multimanager, der folgende Einträge erhält: 
name . . . . . . . : master1act
(Smart Edit aus)
door1      : 0
master1act : 0
Er öffnet also erst inmal die Tür und aktiviert gleichzeitig den master vom linken trigger_multiple. Wie ihr bemerkt habt, haben alle Entitys die 1 im Namen. Falls ihr mehrere solcher Schaltungen gleichzeitig verwenden wollt, müsst ihr einfach die Nummern abändern.




Ich hoffe, das einigen von euch dieses Tutorial weiterhilft, die Beschränkungen des CS-Codes zu umgehen und spannendere Maps zu bauen. Bei Fragen zum Tutorial oder eventuellen Fehlern könnt ihr hier im TheWall.de-Forum posten.

LePrau 2002