Skript-YAML : le bon YAML

[Syst3ms]

Skript-YAML : le bon YML

 

Me voici à nouveau pour un autre tutoriel ! Et vous savez parfaitement que quand je fais un tutoriel, c'est que quelque chose me tient à coeur. Sans plus tarder, commençons.

 

Si vous ne savez pas ce qu'est le YML, faites une recherche, puis lisez ce tuto.

 

Le YML avant :

Le YML est le format de configuration officiel de Bukkit. Skript permettant de faire des pseudo-plugins, il est logique qu'on veuille répliquer le fonctionnement d'un vrai plugin, d'où l'idée du YML. Et le YML dans Skript alors ? Ben, ça puait. Toutes les syntaxes qui offraient la fonctionnalité du YML avaient le même défaut : elles lisaient et interprétaient le fichier en entier à chaque fois.

C'est comme si, pour trouver une réplique dans une pièce de théâtre, vous deviez lire la pièce en entier à chaque fois avant de trouver votre réplique (RPZ la seconde). Pas optimisé DU TOUT. Ah, et si vous voulez une preuve, voici un test de performance réalisé par Rezz :

 

Pour les stats :

• C'est 53 fois plus lent de changer une valeur YML qu'une variable normale et 28 fois plus lent d'en obtenir (get).
  
• Changer une valeur YML prend 25,5 ms contre 0.472 ms pour une variable normale. Ça représente en peu plus de la moitié du temps qu'une balle de baseball reste en contact avec la batte (merci WolframAlpha).
  
• Obtenir une variable YML prend 17,3 ms contre 0,616 ms pour une variable normale
  

Je vous laisse vérifier ces chiffres par vous-mêmes. Gardez en tête que ce sont des moyennes, et qu'il y a des chances qu'elles soient légèrement éloignées de la réalité.

 

Au passage, les 4 addons (oui, quatre) qui ont cette fonctionnalité sont WildSkript, skQuery, Skellett, skUtilities. Déjà que j'aime pas WildSkript en général, alors si vous utilisez le YML de WildSkript, je vais vous réduire en salade de fruits.

 

Bon, comme vous le voyez, j'ai quelques raisons pour dire que le YML tel que vous le connaissez, c'est de la bonne grosse daube. Bon, vous vous doutez bien que je ne vais pas m'arrêter là, donc continuons.

 

Le YML maintenant :

NB : quand je dis "maintenant", je veux dire "ce à quoi c'est censé ressembler maintenant".

 

Récemment, l'addon skript-yaml, développé par Sashie, développeur de skDragon est sorti....

Putain que c'est mieux. Mais bon, il y a un peu d'explications nécessaires pour comprendre pourquoi c'est mieux, et surtout, comment l'utiliser.

 

Le fonctionnement :

 

Avant, on chargeait tout le fichier à chaque fois qu'on essayait de faire quoi que ce soit avec le fichier. Maintenant, ça fonctionne de la façon suivante :

• On charge le fichier en mémoire. Ça veut dire qu'on ne lit et traverse le fichier qu'une fois. Ensuite, les valeurs récupérées sont stockées quelque part dans la mémoire, prêtes à être utilisées.
  
• Là, on fait ce qu'on veut avec nos valeurs. Mais il est crucial de noter que on ne modifie RIEN sur le fichier.
  
• Une fois qu'on a fini d'éditer nos valeurs, il n'y a plus qu'à sauvegarder le YML. C'est le seul moment où on modifie le fichier.
  

Bon, c'est bien gentil de savoir le principe, mais c'est encore mieux de pouvoir l'utiliser concrètement, non ?

 

A) L'utilisation :

 

1. Charger le fichier YML :

 

[re]load [non[(-| )]relative] [y[a]ml] %string% [as %-string%]

Cet effet charge un fichier YML en mémoire.

Le premier "%string%" est le chemin de votre fichier YML qui va être chargé en mémoire, c'est celui qui vous utiliseriez avec n'importe quelle autre syntaxe YML.

Si vous utilisez "[non[(-| )]relative]", alors le chemin commencera à la racine de votre disque dur au lieu du dossier de votre serveur.

Le second "%string%", optionnel, représente l'identifiant donné à ce fichier, utilisé dans les syntaxes suivantes.

 

Vous vous doutez bien qu'on va pas taper tout le chemin à chaque fois, ce serait totalement absurde et ce serait signe d'une mauvaise fonctionnalité, non ? Vous voyez où je veux en venir, hein ?

 

Si ce paramètre est omis, alors on prendra le nom du fichier sans ".yml". Donc pour "config.yml", on gardera "config" comme nom.

 

#Racine
   #Si serveur est sur le disque D:/ (pour Windows), alors la syntaxe ressemblerait à ceci
   load non-relative yaml "RootFolder/MyAwesomePlugin/config.yml"
   #Vous pouvez aussi spécifier le disque vous-mêmes
   load non-relative yaml "C:/RootFolder/MyAwesomePlugin/config.yml"

#Si vous êtes vraiment borné et que vous voulez utiliser le chemin à chaque fois, voici comment
   load yaml "plugins/MyAwesomePlugin/config.yml" as "plugins/MyAwesomePlugin/config.yml"
   set yaml value "version" from "plugins/MyAwesomePlugin/config.yml" to 1.0
   broadcast "%yaml value ""version"" from ""plugins/MyAwesomePlugin/config.yml""%"


# Ces deux effets produisent un même identifiant : "config"
load yaml "plugins/MyAwesomePlugin/config.yml"
load yaml "plugins/MyAwesomePlugin/config.yml" as "config"

2. Modifier les valeurs :

[[skript-]y[a]ml] (1¦value|2¦(node|path)[s]|3¦(node|path)[s with] keys|4¦list) %string% (of|in|from) %string% [without string checks]

Comme vous pouvez la voir, cette expression ne diffère pas trop des anciennes. Pour éviter tout risque de conflit, je suggère d'utiliser "skript-yaml" au début.

Le premier "%string%" simplement votre valeur telle que vous l'utiliseriez avec un YML standard. Pas de changements de ce point de vue-là.

Le second est l'identifiant du YML chargé en mémoire. Attention, ce n'est pas le chemin du fichier. En reprenant l'exemple de la syntaxe précédente, on mettrait simplement "config".

Enfin, si vous ajoutez "without string checks", l'expression retournera un texte quoi qu'il arrive, sans essayer de le convertir en nombre ou en booléen. Ça peut rendre votre code un tout petit peu plus rapide.

 

Exemple :

set skript-yaml value "test1.test2" from "config" to "test3"
set skript-yaml list "list.name" from "config" to {_list::*}

set {_test} to skript-yaml value "test1.test2" from "config"
broadcast "%{_test}%"

3. Sauvegarder votre fichier :

 

save [y[a]ml] %string%

Permet de sauvegarder le YML spécifié dans son fichier correspondant. C'est le seul moment où vous modifiez le fichier.

 

Exemple :

save yaml "config"

B) Autres fonctionnalités:

 

Vous vous en doutez sûrement, mais skript-yaml ne se limite pas à ces trois syntaxes. Les syntaxes suivantes ont leur utilité, mais il est probable que vous ne les utiliserez que dans certains cas.

 

Syntaxe :

unload [y[a]ml] %string%

Exemple :

unload yaml "config"

Permet tout simplement de supprimer un YML de la mémoire. À n'utiliser que si vous voulez supprimer les changements non sauvegardés.

 

 

Syntaxe :

[(the|all (of the|the))] [currently] loaded y[a]ml [files]

Exemple :

set {_list::*} to the currently loaded yaml files
broadcast "%{_list::*}%"

Retourne la liste de tous les configurations YML chargées par "load yaml"

 

Syntaxe :

[all] [[skript-]y[a]ml] (node|path)[s] (of|in|from) %string%

Exemple :

set yaml value "test1.test2" from "config" to "test3"
set yaml value "boop.beep" from "config" to "bop"

set {_list::*} to all yaml nodes of "config"
broadcast "%{_list::*}%"

Retourne tous les noms des entrées d'une config YML.

L'exemple au-dessus enverra "test1, test1.test2, boop and boop.beep" dans le chat.

 

Syntaxe :

y[a]ml[s] %strings% (is|are) loaded
y[a]ml[s] %strings% ((are|is) not|(is|are)n[']t) loaded

Même pas besoin d'exemple pour celui-là, retourne vrai si la config YML spécifée a été chargée en mémoire.

 

 

Syntaxe :

[skript-]y[a]ml [(node|path)[s]] %strings% (of|in|from) %string% has value
[skript-]y[a]ml [(node|path)[s]] %strings% (of|in|from) %string% does(n't| not) have value

Exemple :

set skript-yaml value "test.test" from "config" to "test"
yaml path "test.test" in "config" has value: # toujours vrai
   broadcast "has value"

Retourne vrai si le chemin spécifié existe/a une valeur.

 

Syntaxe :

[the] comment[s] (of|from) [y[a]ml] node[s] %strings% (of|in|from) %string%
[the] (comment[s] (at|on) [the] top of |header (of|from)) %string%

Exemple :

set the comments of yaml node "test" from "config" to "First line" and "Second line"
delete the comments of yaml node "test" from "config"

set {_header::*} to "First line" and "Second line"
set the comments at the top of "config" to {_header::*}
delete  the comments at the top of "config"

set the header of "config" to "First line" and "Second line"
delete  the header of "config"
set the header of "config" to {_header::*}

Obtient, édite ou supprime les commentaires ou le header d'une config YML :

• Les headers ne contiennent pas '#' donc ajoutez-les si vous le voulez
  
• Les commentaires doivent se trouver à la racine. Exemple : 'root', et non 'root.something'
  
• On peut passer plusieurs valeurs aux commentaires et headers
  
• Cette expression ne modifie pas le fichier
  

(ndlr : c'est une traduction)

 

 

En espérant que ça vous ait aidé, je vous dis à plus tard.

Je dirais même plus, à l'année prochaine ! HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAAAAAAA !!!!

 

...elle est nulle je sais.

...vous vous y attendiez hein ?

...c'est bien ce que je pensais.

 

...

 

...Qu'est-ce que vous foutez à lire ça ?

 

(c'est ironique je vous rassure)

[noftaly]

Super tuto ! Mais tu ne nous as pas dit comment récupérer une valeur :( (à moins que j'ai mal compris -> fort probable)

[Syst3ms]

C'est la syntaxe de "modifier les valeurs".

[noftaly]

Donc par exemple

set {_maVariable} to skript-yaml value "test1.test2" from "config"

c'est ca ?

[Syst3ms]

Oui, c'est ça

[noftaly]

Ok bah j'ai un problème alors ^^

 

function loadYML():
   unload yaml "GA-Messages"
   if dir "plugins/GiveAll" doesn't exist:
       create dir "plugins/GiveAll"
   if file "plugins/GiveAll/messages.yml" does not exist:
       download from "https://raw.githubusercontent.com/noftaly/GiveAll/master/messages.yml" to "plugins/GiveAll/messages.yml"
   load yaml "plugins/GiveAll/messages.yml" as "GA-Messages"

function YMLValue(node: text) :: text:
   set {_res} to skript-yaml value "%{_node}%" from "GA-Messages"
   return colored {_res}

on load:
   loadYML()
   wait 1 second
   set {_bc} to YMLValue("Prefixes.Prefix")
   broadcast "Debug: (Préfix) %{_bc}%"

 

Et ca ne fonctionne pas... Mon dossier se créé, mon fichier se créé, le contenu de mon GitHub se colle dans mon .yml, mais cette ligne

broadcast "Debug: (Préfix) %{_bc}%"

me renvoie "Debug: (Préfix) <none>"

 

Lien de mon yml

 

Merci d'avance :)

[Soufreur78]

Trés bon tuto @Syst3ms.

Mais imaginons j'ai mon fichier "Stats" avec dedans 1 .yml par joueur (Le nom du .yml c'est l'UUID du player)

 

Si le joueur meurt et je veux rajouter +1 aux morts du joueur dans son .yml :

- Je dois load, modifier, sauvegarder ?

 

Et si le joueur fait /stats et que je veux récupérer les valeurs dans son .yml !

- Je load, récupére les données, unload ?

 

C'est vraiment utile de load puis sauvegarde/unload à chaque petite action ?

Ou alors je load le fichier du joueur quand il se connecte et puis sauvegarde quand il se déconnecte ?

[Syst3ms]

Trés bon tuto @Syst3ms.

Mais imaginons j'ai mon fichier "Stats" avec dedans 1 .yml par joueur (Le nom du .yml c'est l'UUID du player)

 

Si le joueur meurt et je veux rajouter +1 aux morts du joueur dans son .yml :

- Je dois load, modifier, sauvegarder ?

 

Et si le joueur fait /stats et que je veux récupérer les valeurs dans son .yml !

- Je load, récupére les données, unload ?

 

C'est vraiment utile de load puis sauvegarde/unload à chaque petite action ?

Ou alors je load le fichier du joueur quand il se connecte et puis sauvegarde quand il se déconnecte ?

C'est plutôt le dernier cas qu'il faut choisir.

Imagine que tu devais mettre load & save à chaque fois.

Et bah en gros, le YML avant ça faisait ça.

[Soufreur78]

C'est plutôt le dernier cas qu'il faut choisir.

Imagine que tu devais mettre load & save à chaque fois.

Et bah en gros, le YML avant ça faisait ça.

Ok merci pour cette réponse rapide :)

 

Je me doutais bien qu'il fallait utiliser la derniére solution mais :

- On peut stocker combien de fichier en mémoire sans risque ? Car si je load le .yml de chaque joueur le temps qu'il soit connecté ça va faire beaucoup de chose en mémoire (Il n'y a que 30 lignes dans les .yml des joueurs).

- Et si j'ai bien compris quand je vais load le .yml -> Modifier une valeur-> Si je get la valeur modifiée : je vais bien récupérer la valeur comme elle a été modifiée juste avant ? Car le .yml n'a pas été sauvegardé

[Syst3ms]

Quand tu récupères une valeur, ça la prend depuis la mémoire, sinon ce serait totalement inefficace. Si tu as un quelconque problème de mémoire, c'est que tu auras réussi à causer un erreur mémoire à Java. Donc non, il y a peu de chances que ça arrive.

 

Il faut que tu retiennes ceci : seul l'effet 'save' - et 'load' si on veut - accèdent au fichier, rien d'autre.