Les déclencheurs [2]

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...

Le bouton

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.

Image utilisateur

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 :) .

La VALVe

Entités

Type

Description

func_door_rotating

Bloc

Permet de créer un bloc qui pourra tourner sur lui-même

prop_dynamic

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_.

Image utilisateur

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

Relais d'appels

Entité

Type

Description

logic_relay

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 ^^ ) :

Image utilisateur

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 :D . 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 :

Image utilisateur

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

Filtres d'activation

Entités

Type

Description

http://developer.valvesoftware.com/wik [...] tivator_class

Point

Permet de filtrer en fonction de la classe d'entité (nom d'entité)

http://developer.valvesoftware.com/wik [...] ctivator_name

Point

Permet de filtrer en fonction de la propriété Name

http://developer.valvesoftware.com/wik [...] ctivator_team

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 ?

Propriétés :
  • 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é.

Filter_activator_class

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").

Filter_activator_name

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é !).

Filter_activator_team

Ç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).