| Entités | Type | Description |
|---|
| logic_case |
Point |
Permet de tester une suite de conditions |
| logic_branch |
Point |
Permet de tester une valeur booléenne |
Logic_case
Un
logic_case est en quelque sorte l'équivalent d'un
switch en programmation. Si vous ne connaissez pas, un switch est une condition qui teste toute une série de valeurs. Par exemple, un switch en Javascript ressemble à ceci :
Code : JavaScript 1
2
3
4
5
6
7
8
9
10
11
12
13
14 | switch(valeur) {
case "1":
// Si valeur vaut 1 alors...
break;
case "thunderseb":
// Si valeur est égale à thunderseb alors...
break;
case "25":
// Si valeur vaut 25 alors...
break;
default:
/ Si valeur n'est égale à aucun des choix précédents...
break;
}
|
On teste successivement ce que vaut "valeur", et si on trouve, pas exemple que "valeur" vaut 3, on exécute quelque chose.
Eh bien avec le
logic_case (remarquez le mot "case", qu'on trouve aussi dans le switch
), on va aussi tester une valeur et voir si elle correspond à des entrées définies.
En programmation (comme dans mon exemple), on peut mettre beaucoup de conditions de test (il n'y en a que 3 dans l'exemple). Mais dans le
logic_case, on ne peut en mettre que 16, ce qui est déjà beaucoup
.
Première utilisation : le switch classic
Lors du test du
logic_case, si une des "case" (par "case", comprenez chaque propriété
CaseXX) correspond à la valeur, l'output correspondant est déclenché. Par exemple, si la "case" 2 est vérifiée, l'output déclenché est
OnCase2. Si aucune "case" ne correspond, on peut déclencher l'output
OnDefault s'il est spécifié. Cela veut donc dire que vous devez spécifier claque output possible !
Remarquez que vous ne devez pas tout remplir, seulement ce dont vous avez besoin
Pour déclencher le
logic_case et débuter le test, il faut utiliser son input
InValue (
valeur entrante en anglais) en fournissant en paramètre la valeur à tester :
| Output named | Targets entities | Via this input | Parameter | Delay |
|---|
| OnTrigger |
super_switch |
InValue |
thunderseb |
0.00 |
La valeur envoyée est donc "thunderseb", ce qui correspond à la deuxième "case" (voir mon image ci-dessus). Cela veut donc dire que c'est l'output
OnCase2 qui sera déclenché.
Honnêtement, je n'ai pas d'exemple simple et utile de cette utilisation. Cependant, il existe une deuxième utilisation du
logic_case qui se révèle beaucoup plus intéressante !
Deuxième utilisation : le switch aléatoire
Une autre utilisation du logic_case consiste à ne pas renseigner les propriétés
CaseXX mais seulement les différents outputs
OnCaseXX.
Mais comment s'effectue le test des conditions ?
Il n'y a pas de test. Nous n'allons plus utiliser l'input
InValue pour déclencher le
logic_case, nous allons utiliser l'input
PickRandom, qui signifie
Choisir aléatoirement . Cela veut donc dire que parmi les différents outputs définis du
logic_case, un de ces outputs va être choisi et déclenché.
Et ici, j'ai un exemple concret à vous donner ! (hou que je suis content
). Imaginez, vous débutez devant 4 portes, et une seule de ces portes est ouverte. Mais la porte qui s'ouvre n'est pas toujours la même. Le but est donc de choisir, au début de la map, quelle porte sera ouverte. Ainsi le joueur aura une petite "surprise" à chaque commencement.
Pour mettre cette idée en oeuvre, il suffit de mettre un
logic_auto (souvenez-vous,
je vous en ai déjà parlé) qui appelle le logic_case, lequel choisira entre 4 outputs différents (1 pour chaque porte). Voici ce que ça peut donner :
Le logic_auto
| Output named | Targets entities | Via this input | Parameter | Delay |
|---|
| OnMapSpawn |
super_switch |
PickRandom |
<none> |
0.00 |
Le logic_case
| Output named | Targets entities | Via this input | Parameter | Delay |
|---|
| OnCase01 |
porte_01 |
Open |
<none> |
0.00 |
| OnCase02 |
porte_02 |
Open |
<none> |
0.00 |
| OnCase03 |
porte_03 |
Open |
<none> |
0.00 |
| OnCase04 |
porte_04 |
Open |
<none> |
0.00 |
Logic_branch
Le
logic_branch est une entité qui vérifie si une valeur est booléenne. Si vous faites de la programmation, le mot "
booléen" vous dit certainement quelque chose. Si ce n'est pas le cas, je vais vous l'expliquer brièvement
.
Une valeur booléenne (
boolean en anglais) est une valeur qui peut être soit
vraie soit
fausse c'est à dire
true ou
false en anglais ou encore
1 ou
0 en électronique ou en logique.
Les valeurs à utiliser avec un
logic_branch sont
0 (pour false) et
1 (pour true).
Donc le
logic_branch analyse une valeur pour savoir si elle est vraie ou fausse, et en fonction du résultat du test déclanche ou output :
- OnTrue : si la valeur est vraie (si c'est 1);
- OnFalse : si la valeur est fausse (si c'est 0).
Faites attention que 1 est toujours vrai, mais toute autre valeur que 1 est fausse. C'est à dire que si vous mettez 42, c'est comme si vous mettiez 0, donc c'est faux.
Mais comment utiliser cette entité ?
L'entité est simple à mettre en oeuvre mais, je le concède, un peu tordue à comprendre
. Je vais vous expliquer son fonctionnement par le biais d'un exemple
.
Vous souvenez-vous du
func_brush ? Pour rappel, c'est un bloc que l'ont peut afficher ou masquer. Il est censé remplacer son homologue
func_wall_toggle qui permet là même chose. Mais le
func_wall_toggle a quelque chose en plus, il peut être masqué s'il était affiché, et affiché s'il était masqué (d'où son nom "toggle").
En fait, grâce au
logic_branch, je vais reproduire le comportement "
toggle" du
func_wall_toggle avec un
func_brush. !
Hum, ce n'est pas super utile comme truc - utilisez directement le func_wall_toggle -, mais c'est pour vous montrer une application simple et pas trop idiote du logic_branch.
Ce qu'il faut, c'est changer la valeur du
logic_branch et l'état du
func_brush à chaque fois que le test est effectué. Pour cela, posons que quand le
func_brush est affiché la valeur du
logic_branch est
1, et s'il est masqué, la valeur est
0.
Commençons par définir les deux outputs du
logic_branch qui changent l'état du
func_brush. Comme le mur est affiché par défaut, mettez la valeur 1 dans la propriété Value du
logic_branch.
| Output named | Targets entities | Via this input | Parameter | Delay |
|---|
| OnTrue |
murtoggle |
Disable |
<none> |
0.00 |
| OnFalse |
murtoggle |
Enable |
<none> |
0.00 |
Grâce à ça, dès que le test est effectué, si il vaut
true ça veut dire que le mu est affiché, donc on souhaite le masquer. C'est le contraire s'il vaut
false. Évidemment ça ne marche qu'une fois, puisque nous n'avons pas changé la valeur. C'est pour cela que nous allons ajouter deux autres outputs, qui appellent le
logic_branch (que j'ai nommé
branch) (l'entité s'auto-appelle
) :
| Output named | Targets entities | Via this input | Parameter | Delay |
|---|
| OnTrue |
branch |
SetValue |
0 |
0.00 |
| OnFalse |
branch |
SetValue |
1 |
0.00 |
Et voilà, votre
func_brush est devenu un
func_wall_toggle . Bien sûr si vous mettez un bouton pour faire apparaître/disparaître le mur, vous devez appeler le
logic_branch, et non le
func_brush en utilisant l'input Test, comme ceci :
| Output named | Targets entities | Via this input | Parameter | Delay |
|---|
| OnPressed |
branch |
Test |
<none> |
0.00 |
Les déclencheurs [3]
. 
.
E1iteGam3r
Trouvez une formation
Suggestions
Flux RSS News
Twitter
Facebook
Google+