Das ganze klingt nach nur zwei Klicks - allerdings ist sind es ein wenig mehr, da Valve beim Entity item_kevlar sehr sparsam war. Das Entity selbst tut rein garnichts, außer dem Ersten, der es berührt, 100 Kevlar zu „geben“. Für alles Weitere ist der Mapper selbst zuständig - was und wie genau, das ist das Thema dieses Tutorials.
Fangen wir also an. Als Allererstes wird das Entity item_kevlar benötigt. Da es in der cstrike.fgd, in der normalerweise CS:S spezifische Entities definiert sind, nicht definiert ist, wird es nicht im Dropdownmenü des Entity Tools angeboten, sondern der Name muss manuell eingegeben werden. Aus dem selben Grund verfügt das Entity auch über keine Outputs; es muss also ein wenig getrickst werden.
Das Entity sollte sich ein paar Units über dem Boden befinden, da es manchmal Probleme (in Form von nicht funktionieren oder Konsolenmeldungen) gibt, wenn das Entity im Boden „steckt“.
Da das item_kevlar später mit einem Output angesprochen werden muss, also einen Namen braucht, welchen es aber nicht besitzt, muss dieser wie folgt manuell hinzugefügt werden.
In den Eigenschaften des Entities ist SmartEdit bereits deaktiviert, da es sich ja um ein nicht in der .fgd definiertes Entity handelt. Darum kann durch Add (1) ein neuer Keyvalue hinzugefügt werden, in diesem Fall ist das targetname (2). Der Wert (Value, 3) ist bei mir kevlar, kann aber mit den entsprechenden Anpassungen am weiteren Verlauf des Tutorials auch ein anderer sein.
Das item_kevlar ist Ingame nicht sichtbar. Darum ist der nächste Schritt, dort, wo sich das Kevlar befindet, ein prop_physics zu platzieren und ihm ein passendes Worldmodel zu zu weisen. Mangels eines besseren Models habe ich (in Anlehnung an HL²), das Model models/items/battery.mdl verwendet; rein technisch gesehen ist das verwendete Model natürlich egal.
Damit das Model nicht versehentlich zerstört wird, sollte das Flag Don't take physics damage aktiviert werden. Außerdem braucht das Model noch einen Namen, über den es später angesprochen wird. In der Beispielmap und im weiteren Verlauf dieses Tutorials heißt es kevlar_model, der Name kann aber natürlich beliebig angepasst werden. Die anderen Einstellungen sind optional.
Das Model sollte ein wenig näher am Boden platziert sein als das item_kevlar.
Damit sich das item_kevlar mit dem prop_physics mit bewegt, wird es mit der Parent-Funktion daran gehängt. Um weitere Eingriffe per SmartEdit und außerdem Probleme, die entstehen, wenn die Verbindung per Parent schon beim Mapstart besteht, zu vermeiden, wird das item_kevlar mit Hilfe eins logic_auto Entities erst 0,4 Sekunden nach dem Mapstart an das prop_physics geparentet.
Es muss also ein logic_auto mit folgendem Output erstellt werden:
OnMapSpawn | kevlar | SetParent | kevlar_model | 0.40
Als Nächstes wird für den nötigen Sound gesorgt, wenn das Kevlar "angezogen" wird. Dazu wird ein ambient_generic benötigt; die Position des Entities ist im Prinzip egal, sollte der übersichtlichkeit halber aber in der Nähe des item_kevlar und des prop_physics sein.
Auch dieses Entity braucht einen Namen, bei mir heißt es pickup_sound. Als Sound Name habe ich items/ammopickup.wav gewählt, was dem Standardsound für das Anziehen des Kevlars entspricht.
Die Max Audible Distance kann nach Ermessen angegeben werden, ich habe 128 Units gewählt.
Die einzige außerdem noch relavante Einstellung ist SourceEntityName. Dort muss der Name des prop_physics angegeben werden, im Fall hier also kevlar_model. So kommt der „Anzieh-Sound“ immer von dort, wo sich das prop_physics befindet, unabhängig von der Postion des ambient_generic.
Die Flags sollten bei den Standardeinstellungen belassen werden, also Play everywhere deaktiviert, Start Silent und Is NOT looped aktiviert.
Als letztes Entity wird noch ein trigger_once mit 16*16 Units benötigt. Er muss sich genau auf dem item_kevlar befinden. Mit den folgenden drei Outputs "steuert" er die restlichen Entities:
OnTrigger | pickup_sound | PlaySound
OnTrigger | kevlar | ClearParent
OnTrigger | kevlar_model | Kill | 0.10
Der erste Output startet den „Anzieh-Sound“.
Der zweite Output (ClearParent) ist nötig, da, wenn das prop_physics gekillt wird und das item_kevlar noch daran geparentet ist, auch das item_kevlar verschwindet.
Der dritte Output entfernt das prop_physics, aber eben erst 0,1 Sekunden nachdem die Verbindung per Parent mit dem item_kevlar aufgelöst wurde.
Natürlich muss auch der trigger_once per Parentfunktion an die restlichen Entities gebunden werden. Dazu muss in seinen Eigenschaften als Parent der Name des prop_physics, also kevlar_model angegeben werden.
Bei den Flags des trigger_once muss Clients aktiviert sein, alle anderen Flags nicht.
Das sollte es eigentlich gewesen sein...
El Supremo
Im Archiv befindet sich eine Beispielmap.
tutorial_item_kevlar.zip (~15 KB)
