[TF] Payload GoldRush

Une map payload est basée sur un système d'attaque-défense, comme cp_gravelpit ou cp_dustbowl. Les bleus attaquent et les rouges défendent.
Ce qui change dans une map payload, c'est que les captures doivent se faire en faisant passer un charriot dessus. Dans pl_goldrush, le charriot est représenté par un caddie transportant une bombe bleue destinée à détruire la base rouge. Cela dit, le charriot est juste un prop_dynamic, donc théoriquement, n'importe quel model peut convenir.

Le contrôle des points

Nous allons avoir besoin de paramétrer le team_control_point_master, de cette manière :

Propriétés	Valeurs
Name	CP_Master
Start Disabled	No
Restrict team from winning	Red
Switch teams on map win?	Yes
Scoring Style	Add team score for each captured point
Play all rounds before changelevel	Only changelevel after all mini-rounds have been played to completion
Rate at which to give partial cap points for area captures	0.1

Ensuite, on va ajouter un team_control_point_round, à nommer comme le team_control_point_master :

Propriétés	Valeurs
Name	CP_Master
Start Disabled	No
Priority	0
Control points in this round	m
Restrict team from winning	Red

Ça, c'est fait. Maintenant, on va mapper l'environnement, histoire d'avoir une base de travail.

La création du chemin de fer se fait en deux temps :

1. le placement des models
2. les path_track

Oui, les path_track ! On va les utiliser pour indiquer au charriot (le train) quel itinéraire employer.

Itinéraire

Les rails sont à poser au moyen de prop_static. Pour rechercher les models, utilisez le filtre track dans l'explorateur de models. Il y a tout une kyrielle de models de rails que vous pouvez utiliser .

Pour symboliser les points de capture, vous pouvez, c'est recommandé, utiliser le model odels\props_trainyard\track_midcap.mdl. Voici ce que j'obtiens après avoir joué quelques minutes avec Hammer (c'est très basique ) :



Maintenant, placez les path_track. Si vous ne vous souvenez plus comment les placer, reportez-vous au chapitre qui leur est destiné. Notez qu'au niveau des checkpoints (points de capture), le charriot "monte" dessus, vous devez donc adapter vos path_track en conséquent. Mettez aussi un path_track au centre du checkpoint. Quand le charriot passera sur celui-là, le point sera capturé.



Au centre de chaque checkpoint, mettez un team_control_point, comme on le fait dans les maps CP, et donnez-lui un nom. Par exemple, CP_Partie1_x (x = numéro).

La capture

Pour déclencher la capture, on va utiliser l'output OnPass du path_track situé au milieu du point de capture. Lors de cet output, on déclenchera la capture (le SetOwer du team_control_point) et on empêchera le charriot de reculer, en désactivant le dernier path_track juste avant le path_track servant de point de capture. Voici mes outputs d'exemple pour mon point 1 :

Output named	Targets entities	Via this input	Parameter	Delay
OnPass	CP_Partie1_1	SetOwner	3	0.00
OnPass	CP_Partie1_1_relay	Trigger	<none>	0.00
OnPass	path_track_précédent	DisablePath	<none>	0.00

Le CP_Partie1_1_relay est tout simplement un lien vers un logic_relay qui se chargera d'ouvrir ou de fermer des barrières et faire d'autres trucs en rapport avec la capture comme ajouter du temps.

La prochaine capture

Nous allons le voir dans la sous-partie suivante, mais je vous en touche un mot maintenant. La capture des points se fait à l'aide d'un trigger_capture_area qui bouge en même temps que le charriot (il lui est parenté). Cette entité possède une propriété Control Point qui désigne le point de capture pour lequel elle est utilisée. Or ici, il n'y a qu'un trigger_capture_area. Il faut donc, dès qu'un point est capturé, définir le prochain point à capturer, au moyen de son input SetControlPoint, comme ceci :

Output named	Targets entities	Via this input	Parameter	Delay
OnPass	Bombe_CaptureArea	SetControlPoint	CP_Partie1_2	0.00

Dans mon exemple, CP_Partie1_2 est donc le deuxième point de capture.

Comme je l'ai laissé entendre dans l'introduction, le charriot est un func_tracktrain. Mais attention le func_tracktrain est invisible. Le model du charriot est parenté au func_tracktrain.

Créez un bloc texturé en toolsclip, que vous transformez en func_tracktrain. Nommez-le Bomb_Train.
Ensuite, insérez un prop_dynamic en utilisant le model models/props_trainyard/bomb_cart.mdl, et parentez-le au func_tracktrain :



Le tracktrain demande un certain nombre de propriétés, et dans le cas du charriot, il va falloir en ajouter 3 manuellement.

Propriétés	Valeurs
ManualAccelSpeed	70
ManualDecelSpeed	150
ManualSpeedChanges	1

Voici les propriétés habituelles à adapter :

Propriétés	Valeurs
Name	Bombe_train
First Stop Target	CP_Partie1_1
Max Speed	90
Change Velocity	Linear blend
Distance Between the Wheels	20
Height above Track	1
Damage on Crush	99999
Move Sound	Cart.Roll
Start Sound	Cart.RollStart
Stop Sound	Cart.RollStop

Avant de commencer ce chapitre, je pensais naïvement que Valve avait faire une entité toute faite pour le charriot, avec gestion du dispenser, de la zone de capture et tout et tout. Evidemment, je me trompais .

La zone dans laquelle les joueurs sont habilités à faire avancer le train est faite tout simplement d'un trigger_capture_area. Créez-le, tout autour du charriot, et parentez-le au train. Pensez à recouvrir le dessus du train aussi, comme ça si quelqu'un s'y trouve (moi, j'adore me mettre dessus ), il capturera aussi. Nommez cette entité Bombe_CaptureArea, et associez-lui le premier point de capture (CP_Partie1_1 dans mon exemple).

Pour terminer le montage du train, il faut s'occuper du dispenser. A la manière du trigger_capture_area, créez un bloc, avec la texture de trigger, et transformez-le en dispenser_touch_trigger (ça aurait été plus malin de nommer cette entité trigger_dispenser, mais bon, le codeur devait être dans un mauvais jour). Hum, bref, donnez un nom à cette entité (Bombe_dispenser par exemple), et parentez-là au train.

Quand vous vous faites soigner par le charriot, le rayon soignant sort de la cheminée du charriot. Ce "point de départ" du rayon est placé via l'entité mapobj_cart_dispenser (je maudis ce codeur avec ses noms stupides ). Pas besoin de nommer l'entité (mais bien de la parenter). Spécifiez juste le nom du dispenser_touch_trigger dans la propriété Custom touch Trigger, et spécifiez bien la team qui peut bénéficier du soin.

Voici ce que donne mon charriot, avec tous ses triggers autour :

Faire avancer

3 joueurs au maximum

La vitesse du charriot est influencée par le nombre de joueurs présents dans la zone de capture. Ok, mais comment connaitre leur nombre ?
L'output OnNumCappersChanged du trigger_capture_area envoie le nombre de joueurs présents en son sein (le scout compte pour deux joueurs).

Le trigger_capture_area va donc transmettre le nombre de joueurs à un math_remap qui va s'occuper de redéfinir le nombre. C'est une nouvelle entité dont je ne vous ai pas encore parlé. A son tout, le math_remap va envoyer le nombre redéfini à un logic_case, qui lui va s'occuper de déterminer la nouvelle vitesse (entre 3 différentes) à donner au charriot.



Avant de voir le math_remap, voyons d'abord le logic_case, ce sera plus facile pour comprendre :

Propriétés	Valeurs	Explication
Name	Bombe_logicCase
Case 01	0	Il n'y a aucun joueur
Case 02	1	1 joueur est présent
Case 03	2	2 joueurs sont présents
Case 04	3	3 joueurs sont présents

Et en voici les outputs :

Output named	Targets entities	Via this input	Parameter	Delay
OnCase01	Bombe_train	SetSpeedDirAccel	0	0.00
OnCase02	Bombe_train	SetSpeedDirAccel	0.5	0.00
OnCase03	Bombe_train	SetSpeedDirAccel	0.75	0.00
OnCase04	Bombe_train	SetSpeedDirAccel	1	0.00

Comme on peut le voir, en fonction du nombre de joueurs, on fait changer la vitesse du charriot. Maintenant, supposons qu'il y ait 5 joueurs. Dans ce cas, il ne se passe rien ! C'est pour cela qu'on va avoir recours à un math_remap .

Le math_remap

Le math_remap est un eentité qui reçoit une valeur, qui l'analyse et qui en retourne une nouvelle, ou tout simplement la même en fonction de l'analyse. Le math_remap permet de fixer deux valeurs (deux bornes) : une minimale et une maximale. le math_remap, en recevant une valeur, va la comparer aux deux bornes. Si la valeur est comprise en les deux bornes, cette valeur est renvoyée telle-quelle. Si la valeur est plus petite que la borne inférieure, une valeur définie à l'avance est renvoyée, de même que si la valeur est supérieure à la borne supérieure :

• Minimum Valid Input Value : borne inférieure. Mettez 0.
• Maximum Valid Input Value : borne supérieure. Mettez 3 (au plus 3 joueurs).
• Output Value When Input Is Min. : valeur renvoyée si la valeur d'entrée est plus petite que la borne inférieure. Mettez 0.
• Output Value When Input Is Max. : valeur renvoyée si la valeur d'entrée est plus petite que la borne supérieure. Mettez 3.

En mettant 3 dans Output Value When Input Is Max, ça signifie que si la valeur d'entrée est 5, la valeur de sorte sera 3 .