Question fréquemment posée
En résumé
Streamer.bot est un outil qui est surpuissant pour vous accompagner dans la mise en œuvre technique de votre stream Twitch / OBS. Avec sa très grande variété de déclencheurs appelés triggers (commandes dans le chat, boutons, évènements twitch, etc), il vous permet de lancer des actions (suites de sub-actions) qui vous permettent d'intervenir automatiquement sur OBS (afficher et masquer des sources, modifier le contenu de certaines sources, lire des sons...), sur Twitch (envoyer un message dans le chat, faire une action de modération, ...) tout en générant une quantité impressionnante de données.
En effet, chaque action s'accompagne d'une longue liste d'informations, qu'on appelle de façon générique des "variables" que l'on peut récupérer, utiliser et même... stocker ! Le but de cet article est donc de vous présenter les différents types d'informations disponibles, la manière d'en obtenir de nouvelles, et surtout la manière de stocker et réutiliser ces informations.
En gras, je vous mets en avant le vocabulaire spécifique à Streamer.Bot et à chaque fois que c'est possible, je vous mets le lien de la page de la documentation officielle qui correspond. Elle est totalement en anglais mais elle est généralement très bien faite.
Des informations... partout !
Retenez à ce stade que toute action déclenchée au sein de Streamer.bot génère une large palette d'informations, et ce même si vous lancez une action qui ne fait... rien. Pour vous en rendre compte, RDV dans la rubrique Action Queues et l'onglet Action History. Vous y verrez la liste de toutes les actions lancées dans Streamer.bot depuis son ouverture. Un double clic sur l'une d'entre elle vous ouvrira une liste des informations disponibles.
Voici un exemple des variables générées par une action vide. Evidemment, à ce stade, on n'y trouve pas grand chose d'intéressant. Mais les prochains exemples vont vous montrer de façon évidente qu'on peut faire beaucoup mieux.
Imaginons que vous mettiez en place une action que vous souhaitez déclencher au moment où une personne follow votre chaîne Twitch. Vous allez donc créer votre action, et définir comme trigger Twitch / Channel / Follow. Faisons un clic droit sur ce trigger afin de lancer un test.
Comme vous le remarquez, la liste des variables disponibles s'est grandement allongée. Et on commence à y voir des informations que l'on peut qualifier "d'utiles". En regardant le détail, vous voyez par exemple user et userName. Astuce : la documentation de Streamer.bot vous liste, trigger par trigger, toutes les infos qui vous seront renvoyées... N'hésitez pas à y faire un tour.
Avant même de faire quoi que ce soit, votre action a donc connaissance de toutes les informations que lui apporte son trigger. Vous pouvez donc vous en servir au sein des sub-actions que vous prévoyez pour cette action, sans avoir besoin de faire une quelconque opération supplémentaire.
Dans notre exemple du follow, il va donc être possible, par exemple, de faire un message dans le chat Twitch en intégrant le nom du nouveau follower. Au lieu d'écrire "Merci pour le follow" de façon impersonnelle, vous pouvez écrire "Merci pour le follow %user% !" et automatiquement, %user% sera remplacé par la valeur correspondante.
Pour montrer une autre situation, imaginons cette fois que l'on configure un trigger Core / command / command triggered en définissant une !commande qui déclenche une action (toujours vide ne faisant rien de particulier, pour l'exemple).
Voyons quelles informations sont récupérées à cette occasion.
Une nouvelle fois la liste des variables disponibles s'allonge encore grandement !
En observant de près cette nouvelle liste, vous allez retrouver des informations déjà vues concernant l'utilisateur ayant lancé la commande avec user et userName, ainsi que quelques-unes de ses caractéristiques comme isSuscribed, subscriptionTier, isModerator, isVip... Mais aussi et surtout, vous découvrez un nouvel ensemble de variables ayant trait cette fois à ce qui a été tapé dans le chat Twitch comme commandName, rawInput, input0, input1, input2...
Vous comprenez alors aisément qu'utiliser ces informations va permettre potentiellement beaucoup de choses que ce soit à vous, streameur ou à vos viewers.
A partir du moment où vous choisissez qu'une commande déclenche quelque chose, ça peut être absolument ce que vous voulez : enregistrer ce qui suit la commande dans un fichier texte, utiliser ce qui suit la commande comme élément variable. C'est difficile à expliquer de façon théorique mais plus de façon pratique. J'ose quelques exemples :
- !pause 10 : Vous pouvez déclencher une pause et définir une durée...
Au lieu de définir un Core / Delay directement en chiffre, vous pouvez lui dire %input0%
Attention, un délai est en millisecondes. Si vous voulez écrire des minutes il faudra faire une petite opération :) Oui, on peut faire des maths ! On y reviendra... - !vip : Vous pouvez avoir une seule commande VIP mais... personnalisée pour chacun
En effet si vous utilisez !vip vous pouvez savoir qui est %user% qui fait la commande
Et rien ne vous empêcher d'aller chercher un son MP3 intitulé %user%.mp3 :) Ainsi pour chaque nouveau VIP vous n'aurez rien à faire sinon ajouter un fichier avec le bon nom dans votre dossier de MP3 dédié. Et paramétrer la commande pour n'être lançable que par des VIP évidemment. Pratique, non ? - !ajoutercitation : Vous pouvez répondre une commande à un message de votre chat
Faites le test, si vous répondez à un message en faisant une commande, vous verrez que dans les variables disponibles figurent entre autres l'auteur et le texte du message initial ! Parfait pour vous construire un petit système personnalisé d'enregistrement de citations :) Mais vous pouvez aussi envoyer la citation dans un chanel Discord, ou bien d'autres choses encore.
Pour finir sur ces éléments d'introduction, rappelons également que certaines sub-actions spécifiques permettent d'obtenir encore plus d'informations. Par exemple, le très connu "Twitch / User / Get User info for Target / Source : variable / user" permet d'interroger Twitch pour avoir tout un ensemble d'informations très pratiques sur le %user% qui a déclenché le trigger en cours.
Attention à bien choisir quelle est la "Target" sinon vous aurez les informations mais... pas de la personne que vous espérez. Par défaut, ce sont les infos de vous-mêmes, broadcaster, qui sont récupérées... ce qui n'est pas très intéressant.
Comme on peut le voir, on sait tout (ou presque) sur l'utilisateur "ciblé". Ici je vous montre l'exemple avec le streamer DonnM4ster. On remarque qu'on peut récupérer la description de sa chaîne Twitch dans targetDescription, l'URL permettant de charger sa photo de profil dans targetUserProfileImageUrl, on peut savoir qu'il est affilié Twitch dans targetIsAffiliate, on connait la dernière catégorie de jeu auquel il a joué en live dans game, son dernier titre de stream dans targetChannelTitle, les tags de sa chaîne dans tagsDelimited...
Et voici ce qu'on récupère quand on se rend sur l'adresse de targetUserProfileImageUrl
Récupérer la photo de profil d'un ou de plusieurs viewers ? Chic alors... Vous allez pouvoir la charger dans une source navigateur sur votre OBS, la faire apparaître... disparaître... Avouez que ça vous donne des idées ! ;)
Bref, à ce stade, ce qu'il faut retenir :
- Toute action et tout trigger génère tout un ensemble de variables
- Ces variables peuvent être utilisées dans les sub-actions entre %% (ex : %user%)
- Ces variables sont disponibles y compris dans actions que l'on déclenche dans les sub-actions
- Des sub-actions spécifiques permettent de récupérer encore plus d'informations
- Lorsqu'on exécute une sub-actions qui génère des variables, celles-ci sont disponibles uniquement dans la suite des sub-actions (on ne peut pas connaître une information avant de l'avoir récupérée... c'est logique)
- Une variable peut être utilisée dans beaucoup d'endroits où l'on peut taper du texte
- Une variable peut souvent remplacer une valeur "en dur", par exemple un délai
- Une variable peut être la base d'une condition qui vérifie quelque chose
- Une condition peut vérifier une correspondance (= user), une valeur (égale, plus grand, plus petit), un état (True / False), ... ce qui ouvre de nombreuses possibilités
- Une variable liée à une action, comme toutes celles qu'on vient de voir, s'appelle dans Streamer.bot un argument. Une caractéristique essentielle : à la fin de l'action (et des éventuelles autres actions que l'on a appelées à l'intérieur), elles ne sont plus utilisables ni disponibles. Elles sont éphémères.
- Quand vous créez une action et que vous ne savez pas trop ce que le trigger va rendre disponible, n'hésitez pas à déclencher le trigger manuellement (clic droit dessus / test) puis à vous rendre dans Action Queues / Action History puis à double cliquer sur votre action une fois terminée (ce qui devrait être immédiat si elle est vide). Vous aurez ainsi la liste des informations disponibles, comme les captures d'écran ci-dessus.
Maintenant qu'on a présenté le concept général de variables, il est temps de s'intéresser aux différents types de variables présentes dans Streamer.bot et ce que l'on peut en faire.
Les différents types de variable : tour d'horizon
Nous allons détailler ci-après les différences, intérêts et cas d'usage des :
- Arguments (essentiellement évoqués ci-dessus)
- Variables globales persistantes
- Variables globales non persistantes
- Variables globales liées à un utilisateur
- Variables génériques
- Variables génériques avec formattage
- Fonctions "inline" permettant de calculer (entre autres choses)
Les arguments : éphémères et peu partageurs...
Comme largement expliqué précédemment, les arguments sont des variables "ponctuelles", qui sont générées et utilisées / utilisables uniquement le temps d'une action, de son début jusqu'à sa fin. Si une action fait appel à d'autres actions dans ses sub-actions, les autres actions auront aussi accès à ces arguments. L'un des arguments les plus utilisés est sans doute user.
Pour utiliser un argument dans un endroit où l'on peut taper du texte, on le met entre pourcents : %user%. On peut utiliser un argument à de très nombreux endroits. En général, c'est précisé dans la boite de dialogue de ce que vous êtes en train d'utiliser.
Par exemple, si vous voulez ajouter une petite pause dans votre suite de sub-actions à l'intérieur de votre action, vous allez utiliser la sub-action Core / Delay. Et quand la boite s'ouvre pour vous demander combien de millisecondes doit durer la pause, on vous précise en dessous...
You can enter a %variable% in either field, or a number. The value is in milliseconds ou en bon français : vous pouvez entrer une %variable% dans ce champ, ou un nombre. La valeur est en millisecondes.
Pour reprendre l'exemple précédent, si vous vous faites une commande qui s'appelle !pause, vous pouvez préciser ensuite le nombre de minutes en tapant par exemple "!pause 10". Vous récupérez le 10 grâce à %input0% et vous faites une petite opération mathématique pour obtenir le nombre de millisecondes correspondant. 1 seconde = 1000 ms, 60 secondes = 60000 ms. Donc il suffit de multiplier par 60000.
On peut le faire grâce aux "Inline functions" que je détaille un tout petit peu plus loin. Moralité, vous pouvez dans le délai indiquer : $math(%input0% * 60000)$ au lieu de vous contenter d'un chiffre figé qui est toujours le même.
Félicitations ! Vous pouvez ainsi prévoir un changement de scène, le lancement d'une musique, etc. puis un délai de 10 minutes avant de revenir à vos affaires... automatiquement, une fois le timer de pause fini. Mais ça peut tout aussi bien être !pause 5, ou !pause 30 :)
Vous n'avez pas forcément envie d'aller taper une commande dans votre chat ou de déclencher un point de chaine Twitch, ou que sais-je encore pour tester l'action que vous êtes en train de concevoir. Dans ce cas, il est très facile de créer un trigger "Core / Test", ce qui vous ouvre une petite boite qui vous permet de définir des arguments de test. A gauche, le nom de votre argument, à droite, la valeur que vous voulez lui donner.
Ci-dessous, je force le fait d'écrire "DonnM4ster" dans l'argument "user" afin de faire un test.
Il suffit ensuite de faire un clic droit sur le trigger Test pour lancer le test. Et c'est "comme si" DonnM4ster avait été à l'origine de l'action.
Au-delà des tests, vous pouvez aussi vouloir définir un argument dans votre suite de sub-actions, parce que vous en avez besoin. Par exemple pour pouvoir ensuite faire appel à une action qui attend certains arguments précis. C'est souvent le cas des actions que je mets à votre disposition pour faire quelque chose de précis qui vous indique qu'il y a besoin avant de lancer l'action, de définir un argument ayant tel nom, avec le contenu utile à son fonctionnement.
Il y a pour ça la sub-action "Core / Argument / Set argument". On peut indiquer comme valeur d'un argument... un autre argument. C'est pratique quand on veut garder temporairement en mémoire un argument avec un autre nom que celui qui est donné par défaut.
J'essaye d'illustrer mon propos.
Imaginez que vous avez prévu une commande qui permet de lancer un petit jeu avec 3 viewers que vous désignez dans le chat. Vous allez sans doute utiliser "!jeu nbbeliard berlinabot kafkalino" donc une commande, suivie de 3 paramètres qui vont automatiquement être stockés dans %input0%, %input1% et %input2% comme on l'a vu précédemment. Or ces noms d'argument ne sont pas très... clairs et vous pouvez vite vous y perdre.
Rien ne vous empêche donc de commencer votre action avec 3 sub-actions "Core / Set argument" de suite, en créant un argument joueur1 et en lui donnant la valeur %input0%, puis joueur2 en lui donnant la valeur %input1% puis joueur3 en lui donnant la valeur %input2%.
Ainsi, dans toute la suite de votre action, vous pourrez utiliser %joueur1%, %joueur2% et %joueur3% ce qui semble tout de même plus confortable pour s'y retrouver !
De la même façon, cela vous permet d'éviter d'être bloqué. Comme on l'a vu précédemment, la sub-action "Twitch / User / Get User info for Target / Source : variable / joueur1" vous permet de récupérer l'avatar d'un joueur. Mais comment faire si vous avez 3 joueurs ? Car à chaque nouvel appel de cette sub-action pour un joueur différent, l'argument targetUserProfileImageUrl va se trouver écrasé car il a toujours le même nom ! Et à la fin, vous n'aurez à l'intérieur que le lien de l'avatar du dernier joueur. C'est embêtant...
Appliquons ce que l'on vient de voir ! Une fois que vous avez défini les arguments %joueur1%, %joueur2% et %joueur3%, rien ne vous empêche de commencer par sub-action "Twitch / User / Get User info for Target / Source : variable / joueur1", puis de faire un "Core / Set argument" qui vous permet de ranger dans "joueur1avatar" le contenu de %targetUserProfileImageUrl%. Vous recommencez l'opération avec "Twitch / User / Get User info for Target / Source : variable / joueur2" puis vous refaites un "Core / Set argument" qui vous permet de ranger dans "joueur2avatar" le contenu de %targetUserProfileImageUrl%... et vous recommencez une 3e fois.
Ainsi, à la fin de cette phase qu'on pourrait appeler de "préparation", vous avez à votre disposition %joueur1%, %joueur2% et %joueur3% mais aussi %joueur1avatar%, %joueur2avatar% et %joueur3avatar%. C'est tout de même fort pratique ? :) Et bien plus clair !
J'espère ne pas vous avoir perdus...
Mais comme je l'ai déjà rappelé plusieurs fois, un argument est éphémère, et n'est pas disponible dans des actions "séparées" de celle que vous êtes en train d'exécuter. Si votre petit jeu est complexe et dure un peu, ou nécessite plusieurs commandes et plusieurs actions séparées... Il va falloir trouver autre chose :) Ça n'est pas très pratique quand on veut garder quelque chose en mémoire plus longtemps, ou quand on veut pouvoir faire passer facilement des informations d'une action à une autre alors qu'elles sont indépendantes.
Les variables globales : elles ont de la mémoire et sont partout
Evidemment, si vous avez eu le courage d'arriver jusque là, votre cerveau bouillonne d'idées et de possibilités immenses.
Mais un point épineux subsiste... Comment faire si vous voulez faire un compteur pour compter le nombre de fois où vous avez fait quelque chose ? Comment faire pour garder en mémoire l'information d'une action qui est terminée ? Par exemple... quel est le pseudo du dernier follow, ou du dernier sub ? Bref. Comment faire pour ne pas devenir amnésique dès qu'une action se termine... Comment faire un système d'inscription à un jeu qui sache mémoriser quel est le (ou quels sont les) participants afin de s'en servir dans d'autres actions indépendantes ?
La solution ? Il n'y a aucun suspense : les variables globales. (Je vous vois vous, là bas, qui utilisiez jusque là des fichiers texte parce que ne saviez pas comment faire autrement...).
Pour faire simple, elles fonctionnent exactement comme les arguments (un nom et une valeur associée) sauf... qu'elles ne sont pas stockées au même endroit et elles durent ! Pour définir une variable globale, on n'utilise plus "Core / Argument / Set Argument" mais "Core / Globals / Global (Set)".
Une petite fenêtre s'ouvre et vous propose de choisir ce que vous voulez stocker. Ce peut être un argument qui existe déjà (mais que vous allez donc "retenir"), dans ce cas vous choisissez "Argument" et vous indiquez son nom (sans %%). Vous pouvez aussi spécifier une valeur précise, dans ce cas vous choisissez "Value" avant de remplir la case. Et enfin lorsque vous avez déjà créé la variable globale précédemment, vous pouvez avoir envie d'ajouter 1 (dans ce cas vous choisissez "Increment") ou de retirer 1 (dans ce cas vous choisissez "Decrement"). Vous pouvez aussi indiquer un autre chiffre que 1 si nécessaire (si vous voulez compter de 5 en 5... et pourquoi pas ?).
Et voilà... vous savez faire un compteur qui ajoute (ou "incrémente" dit en langage programmation), ou qui retranche (ou "décrémente" dit en langage programmation)... Et vous savez faire une variable globale intitulée comme vous voulez, et stockant ce que vous voulez.
Attention, vos variables globales étant toutes rangées au même endroit (le bouton "Variables" en haut de l'écran principal de Streamer.bot) elles seront petit à petit toutes mélangées, et classées par ordre alphabétique.
Je vous recommande donc de penser à préfixer les variables globales qui concernent un même sujet pour éviter d'en avoir dans tous les sens. Si vous vous occupez d'un jeu, vous pouvez les appeler nomdujeuParticipant1, nomdujeuAvatar1, nomdujeuParticipant2, nomdujeuAvatar2, nomdujeuGagnant, etc. Ou encore pour des compteurs compteurMorts, compteurAtchoum, compteurBeug... bref, vous avez saisi l'idée. Vous faites comme vous voulez mais gardez en tête qu'on est dans l'ordre alphabétique et que tout est au même endroit. Le but est de vous y retrouver dans 1 semaine, 2 mois, 6 mois...
Dans ce même écran listant les variables globales, vous pouvez faire clic droit / Add variable si vous voulez en créer une directement avant de l'utiliser ailleurs : la "création" de la variable globale n'est pas forcément et obligatoirement dans une action.
Maintenant pour ce qui concerne l'utilisation de ces variables. C'est tout simple, elles sont accessibles partout et tout le temps en utilisant des tildes ~~ à la place des pourcents %% qui eux, sont réservés aux arguments comme on l'a vu.
Si vous avez créé une variable globale compteurMorts, vous pouvez l'utiliser avec ~compteurMorts~ dans toute zone de texte où les variables sont autorisées, comme on l'a vu précédemment.
Bien sûr, la mise à jour de la variable globale va modifier sa valeur dans Streamer.bot, mais si vous avez prévu un affichage quelque part sur votre stream, par exemple un compteur de morts dans un coin de votre overlay... Il va falloir détecter cette mise à jour et actualiser le GDI text qui affiche votre nombre de morts. Si c'est opportun vous pouvez le faire au même endroit, au moment où vous mettez à jour votre variable globale avec votre sub-action "Core / Globals / Global (Set)" en l'utilisant immédiatement après dans une sub-action "OBS / Source / Set GDI text" par exemple. Mais si vous souhaitez gérer ça séparément, vous le pouvez...
Car heureusement, Streamer.bot a tout prévu et vous pouvez découvrir que parmi les triggers il y a un trigger Core / Globals / Global variable updated. Vous indiquez quelle variable globale doit être "surveillée" et hop... votre action sera immédiatement automatiquement appelée à chaque mise à jour de la variable. Outre la mise à jour du GDI text avec "OBS / Source / Set GDI text" (ou plusieurs de suite s'il y en a plusieurs) vous pouvez prévoir un petit bruitage, un message dans le chat Twitch, le clignotement de vos lumières... que sais-je !
Il peut être très utile de prévoir un ensemble de variables globales que vous remplissez à chaque fois qu'un évènement ponctuel "intéressant" survient : un follow (nom du dernier follower), un sub (nom du dernier abonné), un raid (nom du dernier raideur et nombre de viewers par exemple), et tout ce à quoi vous souhaitez pouvoir vous référer quelque part ailleurs par la suite.
C'est exactement ce genre d'astuce qui m'a permis de vous proposer ceci :
Enfin un dernier point qui concerne le fait que votre variable globale sera persistante ou non persistante.
Vous l'avez compris, les variables globales sont plus durables que les arguments qui disparaissent aussitôt l'action terminée. Mais elles-mêmes peuvent avoir plusieurs horizon de survie.
Une variable globale persistante va rester en mémoire sans limite. A chaque ouverture de Streamer.bot, vous la retrouverez et pouvez vous en servir. Elle ne bougera pas, sauf si vous la supprimez vous-même, ou si vous en changez la valeur vous-même. Dans le doute, je vous recommande de faire plutôt des variables globales persistantes. La raison en est simple... Vous pouvez ne pas avoir besoin d'une variable toujours là. Mais si elle n'est plus là et que vous en avez besoin... ça peut être gênant. D'où ma recommandation.
Une variable globale non persistante va en effet rester en mémoire uniquement le temps de votre utilisation en cours de Streamer.bot. Une fois le logiciel fermé, elles sont effacées. C'est potentiellement utile si vous voulez garder quelque chose en mémoire uniquement le temps d'un stream. Il existe également une sub action spécifique qui permet de reset manuellement toutes les variables globales non persistantes.
La différence entre les deux figure dans une simple case à cocher au moment où vous définissez votre variable globale.
Voilà... vous savez tout !
Une dernière chose, il peut arriver que vous souhaitiez transformer une variable globale en argument afin de pouvoir lancer une action particulière par la suite. Comme vous vous en doutez, il y a un outil pour ça. Une sub-action qui s'appelle Core / Globals / Get Global Variable.
Le fonctionnement est très simple, vous indiquez le nom de la variable globale à récupérer (sans les ~~) et le nom de l'argument dans lequel vous voulez stocker cette variable globale (ça peut être le même nom). Si vous le souhaitez, vous pouvez définir une valeur "par défaut" qui sera envoyée dans l'argument dans le cas où la variable globale n'est pas trouvée, ou est vide.
Comme vous avez tout bien suivi jusque là, vous pouvez ensuite utiliser %votreVariable% à nouveau avec des pourcents, car c'est désormais un argument disponible dans l'action en cours ! C'est utile si vous devez lancer une action qui exige de vous de définir un argument, et que la valeur qui vous intéresse est stockée dans une variable globale. Vous l'avez compris, c'est très facile de passer de l'un à l'autre dès qu'on en a besoin.
Notez qu'il est OBLIGATOIRE de transformer une variable globale en argument local avant de l'utiliser dans un Core / Logic / If-Else. Les %arguments% sont possibles, mais les ~variablesGlobales~ ne le sont pas.
C'est une obligation mentionnée dans le mode d'emploi du If-Else :
Mais attendez... je suppose que votre cerveau vient d'avoir un pic d'activité. Je sens bien que vous vous dites que c'est trop cool de pouvoir compter des choses que vous, streameur, vous faites sur votre live Twitch. Le nombre de fois où un big boss Elden Ring vous botte les fesses par exemple. Mais... pourquoi pas compter également des choses qui sont liées à vos viewers ?
Devinez quoi... ? C'est possible !
Les variables globales liées à un utilisateur
Si vous avez tout compris aux variables globales, les variables globales liées à un utilisateur ne devraient pas vous poser de problème majeur. Comme vous vous en doutez, il va y avoir une petite subtilité au moment d'enregistrer puis d'utiliser cette variable, car il faut bien savoir de "qui" on parle...
Si on se place dans la situation où on créé la variable, le début de l'histoire est sensiblement le même que pour une variable globale. Il suffit d'utiliser la sub-action dédiée : Core / Globals / Set Global Variable.
Oui, c'est la même chose que précédemment, mais on va utiliser une autre option... Vous vous en doutez, on va s'intéresser aux deux autres possibilités de destination "User (redeemer)" et "User (target)".
Quand on veut lier une variable à un utilisateur, il est évident qu'il faut que Streamet.bot comprenne de qui il s'agit. Alors on aurait pu penser que les développeurs proposent une case pour nous demander dans quel argument il allait trouver l'utilisateur concerné (vous avez retenu qu'en fonction du contexte, le nom d'un utilisateur pouvait être dans %user% mais pas toujours). Il n'en est rien, sans doute pour de bonnes raisons. Nous allons donc devoir analyser le fonctionnement de ces deux possibilités.
La première, "User (redeemer)" est liée à la personne ayant déclenché l'action en cours, dans laquelle vous venez d'ajouter la sub-action Core / Globals / Set Global Variable. Donc ça sera opérationnel si vous comptez quelque chose qui a trait à une commande lancée par l'utilisateur concerné, à un point de chaîne lancé par l'utilisateur concerné, à un trigger directement liée à un utilisateur (follow, sub, etc). Je ne vous recommande pas cette méthode car vous ne contrôlez pas exactement ce qui se passe, et je ne trouve pas ça, personnellement, très clair. Ça rend également les tests de bon fonctionnement potentiellement embêtants car vous allez injecter de "fausses données" à des utilisateurs choisis aléatoirement à chaque test.
La seconde, "User (target)" va enregistrer la variable globale liée à l'utilisateur en la rattachant à l'utilisateur qui sera mentionné dans l'argument "targetUser". Si juste avant d'enregistrer votre variable globale vous avez utilisé une sub-action Twitch / User / Get User info for Target, vous êtes tranquille, targetUser existe déjà. Mais dans tous les autres cas, je vous recommande de commencer par faire une sub-action Core / Arguments / Set argument, d'injecter dans targetUser la variable qui contient le nom de l'utilisateur pour lequel vous voulez stocker la variable globale, puis seulement ensuite de lancer la sub-action Core / Globals / Set Global Variable, en utilisant la ligne "User (target)". Comme ça vous serez absolument sûr de ce qu'il se passe et vous pourrez même faire un Core / Test en indiquant manuellement le targerUser pour faire vos tests.
Avoir des actions qui sont "testables" est votre meilleure garantie d'arriver aux résultats que vous souhaitez et d'éviter / détecter des problèmes.
Pour le nom et la manière de remplir la variable globale, on est sur la même chose que précédemment. Je vous recopie le paragraphe pour vous éviter l'effort de remonter...
Ce peut être un argument qui existe déjà (mais que vous allez donc "retenir"), dans ce cas vous choisissez "Argument" et vous indiquez son nom (sans %%). Vous pouvez aussi spécifier une valeur précise, dans ce cas vous choisissez "Value" avant de remplir la case. Et enfin lorsque vous avez déjà créé la variable globale précédemment, vous pouvez avoir envie d'ajouter 1 (dans ce cas vous choisissez "Increment") ou de retirer 1 (dans ce cas vous choisissez "Decrement"). Vous pouvez aussi indiquer un autre chiffre que 1 si nécessaire (si vous voulez compter de 5 en 5... et pourquoi pas ?).
Et maintenant, on passe à l'autre pan... celui de la récupération d'une variable globale liée à un utilisateur. Car si on enregistre des données pour un utilisateur, c'est pour être en capacité de s'en resservir. Qu'il s'agisse d'en faire état dans le chat Twitch, de l'afficher sur l'overlay OBS, de l'envoyer sur Discord, ou d'en faire ce qu'on veut... Encore faut-il la récupérer. Il y a comme vous vous en doutez une sub-action exprès pour ça, c'est à dire : Core / Global / Get Global. Une nouvelle fois le point de départ est un outil déjà disponible pour les variables globales évoqué un peu plus haut pour transformer une variable globale en argument.
On retombe sur une interface qui va vous rappeler étrangement celle que l'on utilise pour écrire une variable globale liée à un utilisateur.
L'enjeu lié à la désignation de l'utilisateur pour lequel on veut avoir l'information est le même que ce que j'ai expliqué pour l'écriture. Une fois encore, je vous recommande de commencer par une sub-action Core / Arguments / Set argument, afin d'injecter dans targetUser la variable qui contient le nom de l'utilisateur pour lequel vous voulez lire la variable globale, puis d'utiliser "User (target)". C'est le plus simple, le plus fiable et le plus vérifiable.
Sauf qu'ici, au lieu d'indiquer le nom et la valeur, on indique le nom de la variable globale qu'on veut récupérer, puis le nom que l'on souhaite pour l'argument dans lequel arrivera l'information, et enfin une éventuelle valeur par défaut dans le cas où la variable globale n'est pas trouvée, n'existe pas, ou est vide. Imaginons par exemple que vous avez une variable points pour votre utilisateur, et que vous voulez l'enregistrer dans points, vous pourrez alors vous en servir en utilisant %points% dans toute la suite de votre action.
Donc retenez le plus important :
- Avant toute opération (écriture ou lecture) d'une variable globale affectée à un utilisateur, on commence toujours par faire un Core / Arguments / Set argument qui indique dans l'argument targetUser la variable contenant le nom de l'utilisateur concerné
- On peut ensuite procéder à l'opération de lecture ou d'écriture souhaitée avec Core / Global / Get Global ou Core / Globals / Set Global Variable en utilisant l'option "User (target)"
Voilà, à vous d'expérimenter :)
Vous pouvez ainsi imaginer compter combien de messages chacun de vos viewers écrit dans votre chat Twitch, vous pouvez enregistrer une date de naissance afin d'envisager une alerte si vous concevez une action "anniversaire" que vous lancez une fois par stream, vous pouvez enregistrer le nombre de fois qu'un viewer utilise un point de chaine en particulier, écrit un mot particulier dans le chat, vous pouvez ajouter un compteur de don qui additionne les dons réalisés à chaque nouveau don, vous pouvez enregistrer le nombre de points géré par Streamelements dépensés par des achats de commandes Streamelements... Vous pouvez enregistrer la première phrase qu'un viewer dit dans votre chat pour vous y référer bien plus tard... bref, vous pouvez mémoriser tout ce que vous souhaitez et qui peut être "raccrocher" à un utilisateur.
A noter, certains compteurs sont déjà prévus par Streamer.bot. Par exemple, il est possible de savoir combien de fois une commande a été utilisée au total, et combien de fois un utilisateur s'en est servi. Ce sont des lignes qui sont mentionnées automatiquement parmi les arguments disponibles lorsque le trigger est une commande (regardez attentivement les captures d'écran ci-dessus à ce sujet, vous verrez les lignes counter et userCounter.
Les variables génériques
Les variables génériques sont une famille de variables particulières qui sont disponibles tout le temps et partout. Ce sont, en quelque sorte, des variables "utilitaires".
Le plus simple est de passer tout de suite aux exemples :
- %date% : donne la date au format yyyy/MM/dd
Il est également possible de formatter la date autrement
%date:dd/MM/yyyy% écrira la date comme on en a l'habitude - %time% : donne l'heure au format hh:mm
Il est également possible de formatter l'heure autrement
%time:HH-mm% écrira l'heure sous forme HH-mm avec - au lieu du :
Bref, elles existent, mais ne devraient pas vous servir très souvent.
Les fonctions "inline"
Elles sont bien plus utilisées que les variables génériques car elles permettent de calculer. On en avait déjà donné un exemple plus haut à propos d'un délai, afin de transformer facilement un nombre de minutes (10) en un nombre de millisecondes correspondantes (600000).
On les reconnait car elles sont entourées de symbole dollars $$.
- $math(10+10)$
- $math(%x% * 1.25)$
- $math(%duration% / 1000)$
- $math(%duration% * 60000)$
On voit qu'on peut utiliser les symboles mathématiques courants (+,-,*,/) et qu'on peut aussi bien utiliser des chiffres "en dur" que des arguments entourés de %%. Une page dédiée hors documentation de Streamer.bot donne la liste détaillée de toutes les opérations possibles. On y trouve la plupart des opérations mathématiques, ainsi que quelques outils potentiellement pratiques comme le min, le max, mean (la moyenne), etc.
ATTENTION, la décimale s'écrit avec un . et jamais avec une virgule dans Streamer.bot !
Un dernier point ? L'importance de l'autotype... !
Par défaut, toutes les variables de Streamer.bot sont traitées comme des "strings", c'est à dire des chaînes de texte. Pour tout ce qui est texte, pseudos, URL, etc. ça ne pose aucun problème. Par contre, pour tout ce qui est nombres / chiffres ou True/False, ça peut être très embêtant.
C'est pourquoi je vous recommande de toujours cocher "Autotype" partout où vous le pouvez quand on vous le propose. Cela vous évitera bien des ennuis, notamment quand vous vous lancez dans des calculs ou quand vous souhaitez utiliser des conditions Core / Logic / If-Else.
Je ne détaille pas plus à ce stade car vous devez déjà avoir la tête farcie, mais celles et ceux qui ont pu faire un peu de programmation imagineront facilement les difficultés.
Pour faire simple, quand on a une variable "string", chaine de caractères, tant qu'elle contient quelque chose, qu'elle vaut 1 ou qu'elle soit à True ou true, c'est considéré vrai. Ca veut aussi dire que si elle contient 0 ou False, elle sera considérée True (car elle contient quelque chose...). Elle serait même vraie avec "blabla" ou "trucmuche". C'est fâcheux.
Autre difficulté, si vous faites des calculs mathématiques sur un chiffre qui est considéré comme étant du texte, et pas un chiffre... vous allez avoir des erreurs, ou des résultats incohérents. Par exemple "2" + "2" pris comme des chaînes de caractères peut vous conduire à avoir pour résultat "22" au lieu de "4" attendu... Ou peut vous conduire à ne pas avoir de résultat du tout en raison d'une erreur.
L'autotype vous évite ce genre de difficultés très... désagréables. Utilisez le !
Voilà ! Tout tout tout vous savez tout... ou presque... sur les variables.