Maintenant que nous avons vu les déclencheurs via des triggers (et un logic_auto), nous allons voir les déclencheurs que le joueur peut utiliser, comme les boutons et les vannes...
C'est le bouton le plus basique. Pour en faire un, créez votre bouton, avec soit des blocs, soit avec un model. Moi j'ai choisi de le faire avec un model (models/props_lab/freightelevatorbutton.mdl).
Si vous avez créé votre bouton avec un ou plusieurs blocs, sélectionnez-le(s) et convertissez-le(s) en func_button. Ce sera le bouton .
Pour le model, c'est différent. Créez un bloc avec la texture toolsinvisible, à l'endroit où se trouve le bouton. C'est ce bloc que vous allez convertir en func_button. Cochez son flag Don't move.
L'output de ce bouton est d'une simplicité, que je me demande même si je dois vous le donner . Vous allez le faire, ça vous fera un peu d'exercice.
Quand on appuie sur le bouton, celui-ci doit appeler la lampe et lui disant de s'allumer si elle était éteinte, ou de s'éteindre si elle était allumée.
Output named |
Targets entities |
Via this input |
Parameter |
Delay |
---|---|---|---|---|
OnPressed |
super_lampe |
Toggle |
<none> |
0.00 |
Voilà, vous venez de créer un fabuleux bouton .
Entités |
Type |
Description |
---|---|---|
Bloc |
Permet de créer un bloc qui pourra tourner sur lui-même |
|
Point |
model qui peut être parenté, être masqué, bouger, s'animer... (on reparlera plus en profondeur de cette entité sur la partie Téléportation) |
Pour faire une valve (une vanne), vous avez deux possibilités : soit vous créez une vanne en bloc que vous transformerez en func_door_rotating, soit vous mettez un model de vanne que vous parentez à un func_door_rotating avec la texture invisible.
Mais door ça ne veut pas dire porte ?
Je vais partir sur le deuxième choix car je n'ai pas envie de créer une valve en blocs .
Voilà, dans l'image suivante, j'ai créé un func_door_rotating, avec la texture toolsinvisible. Cette entité est un cylindre et est un peu plus grande que le model de la valve (models/props_pipes/valvewheel001.mdl). Je précise que la valve est un prop_dynamic, puisqu'elle tournera en même temps que l'entité func_.
Voici maintenant les propriétés utiles du func_door_rotating :
Speed : vitesse de rotation
Delay Before Reset : temps avant que la roue ne revienne à sa position initiale après avoir été tournée. Mettez -1 si vous ne voulez pas que la vanne revienne à sa position d'origine
Distance : le nombre de degrés qu'il faudra tourner avant que la vanne ne soit complètement ouverte
Quelques flags :
X/Y Axis : c'est l'axe de rotation
Passable : pour ne pas que le joueur se bloque dedans
Toggle : si la vanne est fermée, on l'ouvre, et inversement
Use Opens : il faut appuyer sur la touche Utiliser pour tourner
Quelques outputs intéressants :
OnFullyOpen : quand c'est complètement ouvert
OnFullyClosed : quand c'est complètement fermé
OnOpen : quand on ouvre la vanne
OnClose : quand on la ferme
Entité |
Type |
Description |
---|---|---|
Point |
Permet d'établir un relais d'appel entre plusieurs entités |
|
Quand on a beaucoup d'outputs, il peut être intéressant de tous les centraliser au même endroit (la même entité). Pour cela, on va utiliser une entité neutre, appelée logic_relay.
C'est une entité qui n'a pas de fonction spécifique. Elle sert juste à établir une relation entre une entité et une autre.
Regardez ce schéma : un trigger appelle le logic_relay, qui à son tour va appeler une entité env_spark (l'entité pour faire des étincelles, souvenez-vous ) :
C'est nul ça, ont sait faire communiquer le trigger et l'env_spark sans logic_relay, non ?
Oui, on sait, et dans le cas de ce schéma, il vaut mieux . Maintenant, imaginez, vous avez plusieurs triggers dans votre map. Tous ces triggers appellent 3 entités (une env_spark, une light et une autre non-définie (obsolete)). Cela veut donc dire que vous devez, pour tous vos triggers, créer les outputs vers chaque entité appelée. C'est contraignant ! Dans ce cas-ci, un logic_relay peut s'avérer pratique :
Vous voyez, c'est le logic_relay qui va se charger d'appeler les entités ciblées. Ainsi, vous n'aurez qu'à faire UN simple output vers le logic_relay, pour chaque trigger .
Pour appeler un logic_relay, utilisez sont input Trigger, comme ceci :
Output named |
Targets entities |
Via this input |
Parameter |
Delay |
---|---|---|---|---|
OnStartTouch |
gentil_relay |
Trigger |
<none> |
0.00 |
Pour appeler une entité à partir du logic_relay, utilisez l'output OnTrigger :
Output named |
Targets entities |
Via this input |
Parameter |
Delay |
---|---|---|---|---|
OnTrigger |
super_lampe |
TurnOn |
<none> |
0.00 |
Entités |
Type |
Description |
---|---|---|
Point |
Permet de filtrer en fonction de la classe d'entité (nom d'entité) |
|
Point |
Permet de filtrer en fonction de la propriété Name |
|
Point |
Permet de filtrer en fonction de l'équipe d'appartenance d'un joueur |
Dans les propriétés des entités de type trigger, vous en avez peut-être repéré une qui s'appelle Filter Name.
Filter Name fait référence à un type d'entités bien spécifique les : filter_activator_ .
Il y a 3 entités de bases présentes dans cette classe d'entités (suivant le mod pour lequel vous mappez, d'autres entités de ce type peuvent être présentes, comme filter_activator_tfteam si vous mappez pour Team Fortress²) :
filter_activator_class
filter_activator_name
filter_activator_team
Ces entités permettent de créer des filtres pour autoriser, par exemple, l'équipe blue à déclencher un trigger.
C'est un peu difficile à comprendre, je vais prendre un exemple concret.
J'ai un trigger_multiple qui ne doit être déclenché que par un joueur de l'équipe rouge. Pour ce faire, je lie le trigger à un filter_activator_team. Je configure cette dernière pour qu'elle retourne vrai si c'est un joueur de l'équipe rouge qui se trouve dans le trigger. Si c'est un joueur bleu, le filtre retournera faux, et le trigger ne sera pas déclenché.
C'est pratique non ?
Name : le nom de l'entité
Filter mode : mode de filtrage
Allow entities that match criteria : valeur par défaut, comme dans mon exemple ci-dessus
Disallow entities that match criteria : c'est le contraire. Pour reprendre mon exemple, si c'est un bleu qui se trouve dans la zone, le trigger sera déclanché.
Filter * : c'est le paramètre de filtrage. Le nom de cette propriété diffère suivant l'entité.
Cette entité filtre en fonction du nom de classe. Par exemple, si vous faites une map solo pour Half-Life², vous pouvez n'autoriser que certaines entités (classe = nom d'entité). Les citoyens sont des entités npc_citizen. Si vous mettez npc_citizen dans la propriété Filter Classname, il n'y aura que les citoyens qui valideront le filtre (il renverra "vrai").
C'est le même principe que filter_activator_class, sauf que vous filtrez les entités en fonction de leur propriété Name (qui est différent du nom de l'entité !).
Ça c'est comme dans mon exemple, cette entité sert à filtrer en fonction de l'équipe. Suivant les mods, le contenu de la propriété Filter Team peut différer (soit 0 ou 1, soit red soit blue).