Bon, je suppose que vous avez déjà vu une vitre uni-visionelle ou sans tain dans de_vegas ou bien cs_loftstrike. Moi, je vais vous dire comment faire.
En fait, la vitre uni-visionelle est composé de quatre couches : une couche avec une texture glass (vitre) un texture invisible, une autre texture invisible et une dernière texture glass.
Voici une image explicative. (Vue du haut) Mais comment faire cela ? D'abord créer un bloc de 4 d'épaisseur avec la texture Glassblue2. Ensuite bouton droit dessus et appuyez sur hollow puis entrer 2.
Dé-groupez le bloc et choisissez un des 2 côtés et appliquez-y la texture invisible.
A gauche la texture invisible et à droite, la texture glassblue1. Groupez les 2 textures.
A gauche la texture invisible et à droite, la texture glassblue1. Groupez les 2 textures.
Voila la première partie de la vitre. Créez-en une autre mais en inversant le côté des textures. Groupez les deux textures.Bon maintenant, il faut transformer cette vitre en entité. Moi, je l'ai mis en func_breakable mais on peux aussi le mettre en func_wall. Voici les paramètres à introduire :
Vitre où l'on voit à travers: Material type Glass Render Mode Additive FX Amount 150
Vitre où l'on ne voit pas à travers: Material type Glass Render Mode Solid FX Amount 75
Créez un bloc de quelques pixels d'épaisseur (5 pixels iront bien), de quelques dizaines de pixels de largeur (au moins 30 pixels) et de la longueur que que vous voulez.
Appliquez sur les faces du brush (« solide » en anglais, bloc) n'importe quelle texture au choix (une texture d'échelle irait) et mettez la en func_wall ou en func_illusionnary
Les func_illusionnary laissent mieux passer les balles et projectiles
Faites ensuite un solide ayant exactement les mêmes dimensions que le précédent et appliquez lui la texture AATRIGER. Transformez le en func_ladder puis collez le solide contre l'autre solide.
Faites un solide qui sera votre porte (de préference au moins 5 pixels d'épaisseur, 96 pixels de haut et 64 pixels de large).
Appliquez lui la texture que vous voulez, puis créez un bloc de 16 pixels de côté avec la texture ORIGIN sur toute ses faces puis mettez le milieu du cube ORIGIN (qui va servir de charnière) sur le milieu du côté de la porte qui restera toujours contre le mur (celui où il y a des charnières dans le monde réel). Groupez les deux solides puis mettez-les en func_door en faisant "Tie to entity" (ctrl + T).
Puis parametrez la porte (clic droit, properties):
- Name: comme pour le nom de votre map ne mettez pas d'espaces autre que "_" et pas de caractères spéciaux. Utile si la porte a besoin de boutons pour s'ouvrir. - Target: l'objet qui va être activé ou désactivé quand la porte est ouverte (ou activée). - Speed: vitesse d'ouverture de la porte. - Delay before close: délai pour que la porte se referme. Mettez -1 pour que la porte reste tout le temps ouverte après ouverture. - Move sound: son de la porte quand elle s'ouvre et se referme. - Stop sound: son de la porte juste au moment où elle se referme ( quand elle "claque"). - Damage inflicted when blocked: dommage infligé au joueur qui bloque la porte. - Fire on close: Objet à activer quand la porte se ferme. - Minimum light level : c'est pour définir le niveau d'éclairage de la porte. 0 = aucun éclairage. 1 = éclairage moyen. 2 = éclairage fort. - Pitch Yaw Roll ( Y Z X) : distance sur laquelle la porte va se déplacer du centre de rotation lorsqu'elle sera activée, ce n'est pas la même chose que l'angle d'ouverture. - Distance (deg): angle d'ouverture de la porte. 90° en général.
Vous n'êtes pas obligé de cocher dans la partie Flags.
- Start Open : porte ouvert au début de chaque round. - Reverse Dir : inverse la direction d'ouverture de la porte quand l'option one-way est cochée. - Don't link : verrouille la porte pour toute la partie. - Use only : la porte s'ouvre seulement quand on utilise le bouton Utiliser (E par défaut). - Passable : elle est pas solide la porte... - One-way : la porte s'ouvre toujours du même côté. - Toggle : la porte s'ouvre ou se ferme quand on l'active. - X axis : la porte s'ouvre en suivant l'axe X, par défaut la porte s'ouvrant sur l'axe Z. - Y axis : idem, mais sur l'axe Y cette fois.
On crée un mur destiné à devenir invisible et on lui applique la texture « CLIP » (présente dans halflife.wad).
On crée la grille avec une belle texture de grille (les trous en bleu...). On la converti en func_illusion. FX Amount 255 (par exemple), Render mode: Texture (d'autres modes peuvent marcher aussi, à vous de choisir). Là, la grille laisse passer les balles, mais aussi le joueur.
Puis on crée un deuxième bloc, recouvrant la grille (même taille, ou 1 pixel de plus), en lui appliquant la texture « CLIP » (pour son utilité, voir le tutorial ci-dessus). A présent, les balles passent mais pas le joueur.
Premièrement, il faut bien comprendre que ces commandes ne fonctionnent qu'en solo, par soucis d'équité entre les joueurs.
Deuxièmement, elles doivent être lancées dans Half-Life en mode développeur. Pour cela, lancez HL avec le paramètre « -dev » ou tappez « developer 1 » dans la console.
Les commandes ci-dessous fonctionnent dans tous les modes graphiques :
Affiche les r_speeds. Pour faire simple, les r_speeds sont le nombre de polygones CALCULES (et non pas affichés !!) en ce moment. Contrairement aux FPS, ils ne varient pas d'une configuration à l'autre. Je ne vais pas vous faire tout un cours sur les r_speeds, ce sera l'objet d'un autre post.
Je ne sais plus si elle marche dans tous les modes ou uniquement en software. Cette commande permet de ne plus voir les entités calculées (sorte de mini-draworder)
Les commandes ci-dessous fonctionnent qu'en Software :
Sorte de « Wallhack du pauvre », cette commande permet d'afficher les polygones calculés dans l'ordre inverse de l'ordre abituel. Cela aura pour effet de vous créer une illusion de wallhack permettant de voir ce qui est vraiment calculé. Petite démonstration pour justifier mes dires (nb: les images ci-dessous proviennent d'une map en développement confiée par un mappeur du forum, si il veut que je les enlève il n'a qu'à me faire signe)
Un morceau de la carte en r_draworer 0 (observez les r_speeds !) :
Le même en r_draworder 1 :
Vous voyez qu'une grande partie de la carte est calculée inutilement, cela demande une bonne optimisation.
Cette commande permet de voir de quelle manière sont appliquées les textures sur les objets. Chaque fois qu'une texture est appliquée (un « carré » fluo), cela ajoute un polygone aux r_speeds. Une demo, tirée toujours de la même carte:
Comme vous le voyez, cela aussi demande à être optimisé.
Les commandes ci-dessous fonctionnent qu'en OpenGL : Cette commande est l'équivalent OpenGL du r_drawflat 1, mais au lieu de mettre des textures « fluo », elle met les découpes en « wireframe » (fil de fer pour les anglophobes). Une démo tirée du (fantastique !) tutorial de Lichen. Comme toujours, si l'auteur veut que je la retire, me contacter:
Cette commande, croisement entre un draworder et un gl_wireframe affiche n'affiche pas les polygones AFFICHES en fil de fer, mais les polygones CALCULES. Une démo est plus claire, elle est tirée d'une de mes maps, encore en développement (pas opti, vis en fast...) :
Un des inconvénients des func_wall est que la lumière passe à travers, qu'ils n'ont pas d'ombre. Les Zhlt permettent de régler ce problème, les zhlt_lightflags. Selectionnez le func_wall que vous voulez qu'il ai une ombre, faites clic droit puis properties.
Dans la partie « class info » de properties, il y a des options du type « Name » pour mettre un nom à ce func_wall. Il y a aussi une option « Light Flags (Zhlt 2.2+) ». Vous avez le choix entre plusieures possibilités comme « Embedded Fix » mais aussi « Opaque (Blocks Light) ». Sélectionnez cette option pour que ce func_wall ai une ombre.
Un inconvénient des zhlt_lightflags est que le temps de compile augmente ( avec ma map il est passé de 5 min à 10 min, avec Bomber-Marc de 10 min à 1h30min je crois. Ca dépend surement de la surface totale des ombres crées avec les zhlt_lightflags.
Celà arrive quand on utilise un vieux FGD qu'on a trafiqué et qu'on a pas envie d'en changer.
On va faire ça gentillement, manipuler un FGD c'est pas la chose la plus facile à faire. Il est évident que tout ceci se fait avec WC qui n'est pas lancé.
// // Entities //
Juste au-dessus, ajouter :
@BaseClass = ZhltLightFlags
[
zhlt_lightflags(choices) :
« Light Flags (Zoner's Tools) » : 0 =
[
0: « Normal »
1: « Embedded Fix »
2: « Opaque (Blocks Light) »
3: « Opaque + Embedded Fix »
6: « Opaque + Concave Fix »
] Il peut être déjà présent, mais pas obligatoirement complet.
@SolidClass base(Targetname, Appearflags, RenderFields) = func_wall : « Wall »
et remplacez la par :
@SolidClass base(Targetname, Appearflags, RenderFields, ZhltLightFlags) = func_wall : « Wall »
Voilà, nous avons ajouté les lightflags.
Localisez :
@SolidClass base(Targetname, RenderFields) = func_illusionary : « Fake Wall/Light »
et remplacez la par :
@SolidClass base(Targetname, RenderFields, ZhltLightFlags) = func_illusionary : « Fake Wall/Light »
@PointClass base(Targetx, Targetname) = trigger_camera : « Trigger Camera »
Et remplacez la par :
@PointClass iconsprite(« sprites/cam.spr ») base(Targetx, Targetname) = trigger_camera : « Trigger Camera »
En admettant que votre sprite s'appelle cam.spr.
@PointClass base(Targetname) size(-4 -4 -4, 4 4 4) color(200 100 50) = info_target : « Beam Target » []
Devient :
@PointClass iconsprite(« sprites/target.spr ») base(Targetname) = info_target : « Beam Target » []
En admettant que le sprite s'appelle target.spr.
Selectionnez votre solide, et transformez le en entite (tie to entity) func_pushable . Et je pense qu'il doit y avoir un chiffre afin de faire en sorte que l'objet soit plus glissant.
Vous placez un grand grush qui va vous servir de nuage. Vous recouvrez sa face intérieure de la texture SCROLLWATER, et je vous conseille de recouvrir les autres faces (invisibles au joueur) de texture NULL si vous utilisez les ZHLT modifiés (mais ce n'est pas obligatoire je précise).
Vous transformez le brush en FUNC_CONVEYOR et vous lui affectez les propriétés suivantes :
Global Entity Name : peu importe Render FX : Normal Render Mode: Texture Render Amount : 170 - 190 (environ) FX Color : 0 0 0 Name : peu importe Conveyor Speed : 2 - 4 (essayez 3)
et vous cochez le flag NOT SOLID.
Sélectionnez ensuite la face recouverte de SCROLLWATER et faites un scale de la texture à 90-100 environ (je sais c'est énorme mais c'est fait pour).
Voilà, vous avez un beau nuage. Les valeurs sont celles indiquées dans le tutorial d'origine; Pour ma part j'utilise 1.5 de vitesse environ.
Lancez votre jeu avec le racourci rajouté de : -console -dev (sans -dev ca apparait juste dans la console)Lorsque vous lancez une carte Half-life (ou un de ses MOD), tapez (dans la console allumé par ²) r_speeds 1
Une serie de chiffre apparaitera en haut a gauche de l'écran.
Ca ressemble à celà (En mode OPENGL ou DIRECT3D) :60FPS 456 w_poly 768 e_poly 10ms
LES FPS : Le nombre d'images par secondes diffusé sur l'écran. Quand cette valeur est supérieure à 30, l'oeil ne ressent pas de rallentissement.
W_poly : World polygon. Ce sont les polygones (ou calculs) qui sont causé par les blocs. Ils sont calculé par le « Central clock frequency » de votre carte graphique.
e_poly : Entity polygon. Ce sont les polygones qui sont causés par tout ce qui est *.mdl (Skin d'armes, skin d'armes a terre, hotages, amis, ennemis.)
10 ms : C'est le temp mis pour calculer une image. 10 ms : 100 images/secondes.
Comme vous pouvez le deviner, pour un mappeur, les chiffres qui l'interesse, c'est les w_poly et les e_poly. Nous nous interresseront surtout ici aux w_poly.
Comment réduire les polygones?
Vous avez surement remarqué que lorsque vous regarder un mur, il calcule ce qu'il y a derrière. Le compilateur qui s'occupe de ce que le joueur vois à tel et tel endroit, c'est le VIS.
Il faut compiler en expert, en rajoutant -full en compilation expert. Ca prend plus de temp, mais c'est vraiment important.
En fait le VIS, il met des « portals » sur votre map. Vous pouvez controller cela grâce aux « hint-brush » (Disponible dans les derniers ZHLT).
Un bloc de 6 faces, c'est six fois quelque chose. Quand vous le pouvez, enlevez certains blocs.
Quand vous faites deux blocs qui se touchent parfaitement (deux faces cotes a cotes), faites en sorte qu'ils aient les mème propriétés de textures. Cela feras que les deux blocs seront « mixé » en un seul bloc.
Exemple : La partie supérieur des chaises du l'image ci-dessous est en fait composé de blocs mixés.
Très connue des mappeur, cette technique peut faire gagner beaucoup de r_speeds.
Quand vous posez un bloc 6 faces sur une table (par exemple) celà divise votre texture en 6 parties. Si en plus votre bloc est un cylindre, alors là c'est pire.
Pour eviter cela, il suffit de faire « surelever » votre bloc de 1 pixel, ou alors de le transformer en func_wall (Ce que je vous déconseille ! Car l'erreur « too much entity » ou une autre risque d'apparaitre). Si vous avez beaucoup d'objett sur une table, reduisez la hauteur de la table de 1 pixel (Au lieu d'augmenter tous les objets a 1 pixel.
La texture NULL, présente dans le zhlt.wad des derniers ZHLTs permet a la face dont est aplliqué cette texture de ne pas étre calculé par le HLCSG.Je vous conseil d'appliquer NULL au plus de surfaces possible (Toutes les surface que le joueur ne regardera JAMAIS.)
Cette texture permet d'autres choses (On a vu cela plus haut avec une vitre double tain) bien pratique.
Elle peut aussi reduire le temp de compilation (ne vous attendez pas à des merveilles, mais dans certains cas ca peut vrement être bénéfique)
Cette technique mérite surtout d'être en complément de celle du « bloc-volant ».
C'est l'entité scripted_sentence qui gère les dialogues. Comme dans Half-life, par exemple au début quand le garde vous dit « vous êtes en retard », vous pouvez créer des dialogues.
Commencez donc par créer le personnage qui va parler, puis près de lui créez une entité scripted_sentence (c'est de cette entité que part le son). Nommez le personnage, speak1 par exemple. Notez que cette entité accepte uniquement les vrais sentences, comme par exemple pour le scientifique la sentence c1a2_sci_elevator.
Seulement les fichiers .wav commencant par le nom d'une map (c1a2 dans l'exemple précédent) sont accéptés. Les phrases comme « bonjour, Aie, vous allez regretter c'que vous v'nez d'faire, Ha,... » ne sont pas accéptées car ce sont des sons de réflèxes des personnages (quand vous leur tirez dessus, quand vous leur parlez,...).
Propriétés :
- Sentence name : nom du fichier .wav. Ils sont tous dans le pak0. Vous devez par contre l' écrire d'une facon étrange : pour la sentence c1a2_sci_elevator par exemple, vous devez l'écrire dans ce champ comme suit : !SCI_ELEVATOR. Comme vous le voyez, vous devez mettre un point d'exclamation initial et puis le nom du fichier sans c1a2. - Speaker type : nom du monstre qui parle. - Sentence time : durée de la sentence : cet attribut définit la durée de temps pendant laquelle le monstre agite sa bouche. Reportez le chiffre de la durée du la sentence. Si vous mettez un chiffre inférieur à la vraie durée de la sentence, le monstre va fermer sa bouche mais on entendra quand même sa voix.... - Listener type : nom du monstre récépteur : c'est le personnage à qui s'adresse l'homme qui parle. Cela peut être player (joueur) ou le nom que vous avez attribué à un monstre.
Créez differentes images ( 6 ) au formats .tga dont le nom de chaque image doits être le même sauf le sufix.
EXPLICATION : imaginons que je crée un ciel que j'appelle gs ( c'est mon diminutif de mappeur , ca correspond a Golden Soupline ) alors mes 6 images seront :
gsbk.tga gsdn.tga gsft.tga gslf.tga gfrt.tga gssup.tga
Donc les sufixes à rajouter à chacunes des images sont : bk ; dn ; ft ; lf ; rt et sup
Sup est le haut de ton ciel , bk « l'arriere » ( back ) , lf la gauche (left) , rt la droite (right ), ft le devant (front ) et dn le bas (down )
Une fois le ciel crée il faut mettre les images dans HL/cstrike/gfx/env
pour mettre le ciel que tu as crée dans la map du doit entrer me nom du ciel dans : map/map properties.../environment map (cl_skyname ) dans l'exemple de mon ciel il faut metre gs comme nom de ciel
Faites deux portes : la première ca sera la porte simple, et la deuxième la vitre. Laisse un trou dans la porte pour mettre la vitre.Puis, tu configures les deux portes de la même facon : même vitesse (comme ca elles bougent en même temps), même nom, même temps de fermeture,... De cette facon, le joueur croira qu'il y a une seule porte qui est vitrée!
Mettre l'entitée armoury_entity du fgd expert de cs et réglé la valeur item de l'entitée
On utilise cette entitée pour par exemple donner plusieurs armes secondaires ou primaires. Le nom des l'entitées est game_player_equip. Il faut mettre les options Give MP5, Give ... a la valeur Yes pour que les joueurs ait l'arme et No pour qu'ils ne l'ait pas.
Mettre l'entitée info_map_parameters et dans la partie Weapon_Buying, mettre sur Neither CT's nor T's can buy guns.
D'abord, transformez les objets qui vont être cassés en func_breakable. Dans le champ Name, mettre bomb puis allez dans la partie flag et mettez le flag Only Trigger. Ensuite dans l'entité func_bomb_target, dans le seul champ qu'il y ait mettez bomb
Avant tout, on a besoin du fichier materials.txtSi celui ci n'est pas dans le répertoir SOUND de votre MOD (TFC\SOUND\ ou CS\SOUND\) il faut le récupérer dans le fichier PACK0.PAK du répertoire « VALVE\PACK0.PAK »
Il suffit d'ouvrir ce fichier avec le logiciel PackScape.
Copiez le fichier materials.txt dans le répertoire SOUND du MOD concerné.(un « clic-déplacement » marche très bien sous packscape)puis éditez le :
Le répertoire est organisé par sections, et je pense qu'il vaut mieux ajouter son nom de texture dans la bonne section afin de conserver la logique du fichier, pratique si on fait de nombreux ajouts.
Le fonctionnement est simple :On place la lettre du son désiré, un espace, puis le nom de sa texture, suivant les indications suivantes :
'M' metal 'V' ventillation 'D' dirt 'S' slosh liquid 'T' tile 'G' grate (par défaut) 'W' wood 'P' computer 'Y' glass
Si j'ai une texture nommé TEST, et que je veux un son métal quand je marche dessus ca donne :
M TEST
Un maximum de 512 textures peuvent être utilisées dans ce fichier. on enregistre au format TXT, et le tour est joué.
Un mod hl suporté par valve nommé « spirit » permet de le faire.La-dedans vous avez plein de trucs, comme la propriété move with (bouge avec). Elle est disponible sur valve. Dedans vous avez des exemples de toutes les fonctions et le fgd.
Vous avez déja compris le fonctionnement de la propriété move with? Pour le train : faites le train avec ses fonctions habituelles et faite une vitre séparée du train mais quand-même à son emplacement.
C'est là que ça change : dans la propriété move with de la vitre, mettez le nom du train. C'est fini, mais cependant le train ne pourra pas tourner, sauf si vous mettez un bloc origin groupé à la vitre au même endroit que celui du train et que vous créer une entité calc_position dont la propriété entity to use contient le nom de la vitre et la propriété position to calculate contient origin.
Réponse 1:
On crée, dans le répertoire de compilation, un fichier tamap.rad (où tamap est le nom de la map en cours), qu'on rempli avec des lignes du type
:TEXTURE_NAME R G B A
Par exemple:
~LIGHT3B 155 155 235 2000 ~LIGHT3E 90 190 140 6000 ~LIGHT5E 190 20 20 3000 +0~LIGHT1 40 60 150 3000 +A~LIGHT1 255 255 255 6000 +0~LIGHT2A 255 255 255 10000 +0~LIGHT5A 80 150 200 10000 +0~LIGHT6A 150 5 5 25000 C3A2_LIGHT 255 149 43 10000
Réponse 2:
Si on utilise des ZHLT récents, on peut à la place créer une entité du type Info_Texlights, qui s'utilise comme un multimanager, sauf qu'en lieu et place de "nom de l'entité" et "temps de déclanchement", on utilise "nom de la texture" et "r g b a"
Remarque 1:
R = Red (Rouge) G = Green (Vert) B = Blue (Bleu) A = Alpha (Intensité)
Remarque 2:
enhanced texlights All texlights can now pulse, flicker, and switch on and off, just like normal light entities. To use this feature, you need to set the 'style' value on the brush entity which has the light-emitting texture. If your .fgd doesn't include style values, you can add the following to any entity... style(choices) : "Texlight style" : 0 = [ 0 : "Normal" -3: "Grouped" 10: "Fluorescent flicker" 2 : "Slow, strong pulse" 11: "Slow pulse, noblack" 5 : "Gentle pulse" 1 : "Flicker A" 6 : "Flicker B" 3 : "Candle A" 7 : "Candle B" 8 : "Candle C" 4 : "Fast strobe" 9 : "Slow strobe" 12: "Underwater" ]The Grouped setting is essentially a hack to allow your texlights to be switchable. To use it, create a brush entity with texlights on it, and set its style to Grouped; then create a light entity with the same name as the brush entity. Hlrad will now pretend that the light emitted by the texlight is "really" being emitted by your light entity! In other words, turning the light on and off will now turn the texlights on and off, too. (You'll probably want to set the brightness of the light entity to 0.01, so that it emits no light of its own.) (This trick is unnecessary if you're using Spirit of Half-Life, which supports switchable texlights directly.)
Il semblerait qu'en ajoutant le paramètre "Texlight style" à ses entités brush-based, on puisse à présent faire "clignoter", "vaciller", etc n'importe quelle texture lumineuse. Je n'ai cependant pas testé, toute confirmation serait la bienvenue.
Tout d'abord, le train cible le premier path_track, comme un train normal. Le premier path_track cible le second et ainsi de suite. Sauf qu'il y a un petit changement : dans les flags du second, cochez « disabled ». Ainsi, lorsque le train essayera d'etteindre le second path_track (c'est-a-dire le premier qui fait « avancer » le train), il ne pourra pas car ce path_track est bloqué.Et maintenant, votre bouton doit cibler le second path_track, ce qui « décochera » le flag « disabled » et qui permettra au train d'avancer.
Récapitulons : dans le second path_track (appellons-le path2), cochez dans les flags « disabled ». Ensuite, le bouton devra cibler ce même path_track (path2).
Un env_laser pour le point de départ du laser, un info_target pour son point d'arrivée. Ensuite on joue aves ses propriétés pour obtenir l'effet désiré.
Donc, en premier tu places ton entité-bloc trigger_quelquechose. On va ici prendre comme exemple un trigger_teleport (ca peut aussi tres bien être un trigger_once ou n'importe quel autre trigger, mais je pense que cette manip peut etre utile surtout avec un trigger_teleport).
Ensuite, tu crée une entité multisource. Tu lui donnes un nom (par exemple multisource_1). Après, dans le champ Master du trigger_teleport, tu met le nom du multisource (multisource_1 dans ce cas).
Puis, tu paramètres ton trigger_teleport comme tu veux, avec le point d'arrivée et touts les autres trucs.
Veille bien à ce que le multisource soit ciblé par quelque chose, sinon il restera inactif. Le bouton qui rend fonctionnelle la téléportation doit enfête cibler le multisource (ici multisource_1).
Donc, en premier tu places ton entité-bloc trigger_quelquechose. On va ici prendre comme exemple un trigger_teleport (ca peut aussi tres bien être un trigger_once ou n'importe quel autre trigger, mais je pense que cette manip peut etre utile surtout avec un trigger_teleport).
Ensuite, tu crée une entité multisource. Tu lui donnes un nom (par exemple multisource_1). Après, dans le champ Master du trigger_teleport, tu met le nom du multisource (multisource_1 dans ce cas).
Puis, tu paramètres ton trigger_teleport comme tu veux, avec le point d'arrivée et touts les autres trucs.
Veille bien à ce que le multisource soit ciblé par quelque chose, sinon il restera inactif. Le bouton qui rend fonctionnelle la téléportation doit enfête cibler le multisource (ici multisource_1).
Ils sont dans les préfabriqués livrés avec Worldcraft (Hammer) :
Pour le chargeur de vie :
Vas dans la catégorie Usable Objects, le prefab s'appelle medkit. Tu remarquera qu'il y a plusieurs versions : west facing, north facing, east facing et south facing.
Cela depend d'où tu veux mettre ta borne : Si tu veux que la face principale soit orientée vers le nort prend north facing, si tu veux que la face principale soit orientée vers l'ouest choisi east facing, etc...
Pour le chargeur d'énergie :
Toujours dans la catégorie Usable Objects, le prefab s'appelle recharger. Tout comme pour le medkit les différentes versions dépendent de l'orientation de ton prefab.