diff --git a/src/lib/translations/fr/wiki.json b/src/lib/translations/fr/wiki.json index f9cfc0a2..c7f2db3d 100644 --- a/src/lib/translations/fr/wiki.json +++ b/src/lib/translations/fr/wiki.json @@ -100,7 +100,7 @@ "title": "Mettre en place un Écran de Configuration" }, "metadata": { - "title": "Références pour les Annotations et les Métadonnées" + "title": "Référence pour les Annotations et les Métadonnées" } }, "misc": { diff --git a/wiki/configuration/advanced-configuring/en.md b/wiki/configuration/advanced-configuring/en.md index 90a81d3a..387742f3 100644 --- a/wiki/configuration/advanced-configuring/en.md +++ b/wiki/configuration/advanced-configuring/en.md @@ -1,9 +1,4 @@ ---- -title: Advanced Configuring -index: 2 ---- - -# Advanced configuring +# Advanced Configuring Simple values are nice and all, but if you have a lot of them it can begin to get unwieldy. In this tutorial, we'll discuss how to organize your config and use processors to get the most out of it. @@ -52,6 +47,7 @@ We simply create a new class, inside our config class, that extends `ReflectiveC In Java, you can print to different output streams in the console. These aren't basic integer or float objects, so we can't just save them in our config! This is where the `ConfigSerializableObject` interface comes in. By implementing its three methods, we can set up any class to be usable as a config object. The interface works via generics, just like `TrackedValue`. The `` in `ConfigSerializableObject` can be swapped out with any serializable class (remember, by default that's primitive types, `String`, `ValueList`, and `ValueMap`), and the value of your object will be translated into that type to be saved to disk, and then converted back into your custom object when read. To do that translating, we need to implement three methods: + - `T getRepresentation()`: here, your value is converted to the serializable class that you specified in the generics (represented by `T`) so that it can be saved. - `YourSerializableClass convertFrom(T)`: this one is called when reading the config file, and converts the representation created by `getRepresentation` back to its original type. - `YourSerializableClass copy()`: makes a copy of the value, which Quilt Config uses internally. @@ -167,6 +163,7 @@ public class ExampleModConfig extends ReflectiveConfig { With that, our config will print "Loading config!" before any of its values are deserialized. Note despite the method name passed to `@Processor` not coming with any parameter information, we still had to put a `Config.Builder` on our method: what's up with that? Processors can be attached to three different types: tracked values, config sections, and config classes. For each, the parameter will be different, as documented in `Processor`'s Javadoc: + - When used on a tracked value, the processor method will take a `TrackedValue.Builder` as its parameter. - When used on a section, the processor method will take a `SectionBuilder` as its parameter. - When used on a config class, the processor method will take a `Config.Builder` as its parameter. @@ -190,7 +187,7 @@ public class ExampleModConfig extends ReflectiveConfig { With that line, we've expanded our logging to now tell us whenever a config value is updated! Neat, but what else can we do with callbacks? -One example of a callback usage is syncing a value between your config field and another. This could be needed for many reasons: your config value is complicated, and you want to make it easier to access, or maybe you need to update the configuration of one of the libraries you depend on when the value is changed ([enigma]() does just that!). +One example of a callback usage is syncing a value between your config field and another. This could be needed for many reasons: your config value is complicated, and you want to make it easier to access, or maybe you need to update the configuration of one of the libraries you depend on when the value is changed ([enigma](https://github.com/QuiltMC/enigma) does just that!). We're going to set up a shortcut to accessing the print stream made available in `printStream`, that doesn't force you to go through two separate getters to use. To do that, we can use a processor applied to the field! `src/main/com/example/example_mod/ExampleModConfig`: @@ -208,7 +205,7 @@ public class ExampleModConfig extends ReflectiveConfig { public void processPrintStream(TrackedValue.Builder builder) { builder.callback(value -> activeStream = printStream.value().getStream()); } - + // ... } } @@ -238,7 +235,7 @@ public class ExampleModConfig extends ReflectiveConfig { } ``` -With our knowledge of processors, this is simple! You can also use the config builder to add new fields, new sections, and update [metadata](https://wiki.quiltmc.org/en/configuration/metadata), on top of changing the format and using callbacks as we've already covered. +With our knowledge of processors, this is simple! You can also use the config builder to add new fields, new sections, and update [metadata](../configuration/metadata), on top of changing the format and using callbacks as we've already covered. ## Adding multiple files diff --git a/wiki/configuration/advanced-configuring/fr.md b/wiki/configuration/advanced-configuring/fr.md new file mode 100644 index 00000000..75315997 --- /dev/null +++ b/wiki/configuration/advanced-configuring/fr.md @@ -0,0 +1,267 @@ +# Configuration Avancée + +Les valeurs simples c'est sympa mais si vous en avez beaucoup ça peut rapidement devenir compliqué à gérer. Dans ce tutoriel, nous allons voir comment organiser votre config et utiliser des processeurs pour en tirer le maximum. + +## Utiliser des sections + +Un simple fichiers avec dizaines de valeurs à la suite peut rapidement devenir complexe à comprendre et à utiliser. Heureusement on peut l'organiser en plusieurs sections en utilisant Quilt Config ! C'est très simple à réaliser. + +Avec des sections, vous pouvez utiliser de l'indentation pour differencier visuellement les parties de votre fichiers de configuration pour faciliter la lecture des utilisateur·ice·s. Nous allons ajouter une section d'exemple qui ressemblera )à ça dans le fichier TOML : + +```toml +# ... + +# This isn't actually used by the mod, but I was completely out of ideas for things to add. +typesOfSoup = ["tomato", "borscht", "chicken noodle", "ramen", "STEW", "mushroom"] + +# Advanced settings for advanced users. +[advanced_settings] + # Whether to automatically append newlines to every message printed. + # default: true + printNewlines = true +``` + +Pour faire cela, nous allons créer une section dans notre code : + +`src/main/com/example/example_mod/ExampleModConfig`: + +```java +public class ExampleModConfig extends ReflectiveConfig { + // ... + @Comment("Advanced settings for advanced users.") + @SerializedName("advanced_settings") + public final AdvancedSettings advancedSettings = new AdvancedSettings(); + + public static class AdvancedSettings extends Section { + @Comment("Whether to automatically append newlines to every message printed.") + @SerializedName("print_newlines") + public final TrackedValue printNewlines = this.value(true); + } +} +``` + +Nous ajoutons simplement une nouvelle classe, dans notre classe de configuration, qui hérite de `ReflectiveConfig.Section`. Ensuite nous devons créer un autre objet dans notre config principale pour ajouter cette section. Notez que cette instance de notre section n'est **pas** contenue dans une `TrackedValue` comme le reste, en fait elle contient elle-même des `TrackedValue` ! Maintenant que l'on a une section, on peut ajouter autant de valeurs que l'on veut dedans. Et si on veut contenir quelque-chose de plus intéressant que des types basiques, des maps ou des listes ? Serialisons un objet personnalisé. + +## Sérialiser des valeurs personnalisées + +En Java, vous pouvez écrire dans plusieurs flux de sortie dans la console. Ce ne sont pas des objets entier ou float basiques donc on ne peut pas simplement les contenir dans notre config ! C'est là que l'interface `ConfigSerializableObject` intervient. En implémentant ses trois méthodes, on peut mettre en place n'importe quelle classe pour pouvoir les utiliser comme objet de configuration. + +L'interface fonctionne avec des generics, comme `TrackedValue`. Le `` dans `ConfigSerializableObject` peut être remplacé par n'importe quelle classe sérialisable (par défaut ce sont les types primitifs, `String`, `ValueList` et `ValueMap`) et la valeur de votre objet sera traduit en ce type pour être sauvegardé en dur puis sera reconverti en votre objet personnalisé en étant lu. Pour faire cette traduction, nous devons implémenter trois méthodes : + +- `T getRepresentation()` : ici, votre valeur est converti en la classe sérialisable que vous avez spécifié dans les generics (représenté par `T`) pour qu'elle puisse être sauvegardée. +- `YourSerializableClass convertFrom(T)` : celle-là est appelée en lisant le fichier de configuration et reconverti la représentation créée par `getRepresentation` en son type original. +- `YourSerializableClass copy()` : réalise une copie de la valeur que Quilt Config utilise internalement. + +Assez avec les explications : voyons un exemple ! + +`src/main/com/example/example_mod/ExampleModConfig`: + +```java +public class ExampleModConfig extends ReflectiveConfig { + // ... + public static class AdvancedSettings extends Section { + // ... + @Comment("What stream to print the message to.") + @SerializedName("print_stream") + public final TrackedValue printStream = this.value(PrintStreamOption.SYSTEM_OUT); + + @SuppressWarnings("unused") // les IDEs ne comprendront pas que toutes les options de cet enum peuvent être utilisées via la config + public enum PrintStreamOption implements ConfigSerializableObject { + SYSTEM_OUT(System.out), + SYSTEM_ERROR(System.err); + + private final PrintStream printStream; + + PrintStreamOption(PrintStream stream) { + this.printStream = stream; + } + + public PrintStream getStream() { + return this.printStream; + } + + @Override + public PrintStreamOption convertFrom(String representation) { + return valueOf(representation); + } + + @Override + public String getRepresentation() { + return this.name(); + } + + @Override + public PrintStreamOption copy() { + // les valeurs d'enum ne peuvent pas être dupliquées + return this; + } + } + } +} +``` + +Cela peut avoir l'air d'être beaucoup de code mais on en a déjà couvert la majorité ! Ici on utilise un `Enum` qui nous permet de définir clairement une liste d'options pour notre valeur. Si vous le vouliez, pour pourriez utiliser une classe normale et avoir un nombre infinie de possibilités pour votre champ de configuration ! Un autre bonus avec l'utilisation d'un `Enum` est que Quilt Config va automagiquement générer un commentaire avec les valeurs possibles dans le fichier de configuration sérialisé. + +L'implémentation des méthodes de `ConfigSerializableObject` est incroyablement simple ici : comme les valeurs de notre enum ont déjà des noms, on utilisé simplement les méthodes `name` et `valueOf(String)` pour sérialiser et désérialiser respectivement. Pratique ! Regardons un autre exemple d'un objet personnalisé qui ne peut pas être représenté comme un enum. + +Disons que l'on veut stocker un point sur une grille 3d dans la config. Nous devrions stocker des coordonées `x`, `y` et `z` pour cette valeur. Faisons cela ! C'est un simple exemple et ne sera pas utilisé dans notre mod. + +```java +public class Vec3i implements ConfigSerializableObject> { + public final int x; + public final int y; + public final int z; + + public Vec3i(int x, int y, int z) { + this.x = x; + this.y = y; + this.z = z; + } + + @Override + public Vec3i copy() { + return this; + } + + @Override + public Vec3i convertFrom(ValueMap representation) { + return new Vec3i(representation.get("x"), representation.get("y"), representation.get("z")); + } + + @Override + public ValueMap getRepresentation() { + return ValueMap.builder(0) + .put("x", this.x) + .put("y", this.y) + .put("z", this.z) + .build(); + } +} +``` + +Ici on utilise une `ValueMap` au lieu d'un `String` comme type sérialisé. Cela nous permet de facilement distinguer les champs `x`, `y` et `z` et c'est le type que vous utiliserez presque à chaque fois pour sérialiser des objets complexes comme celui-ci. On ne va pas aller trop en profondeur ici, le code est assez parlant maintenant que l'on comprend l'interface `ConfigSerializableObject`. + +## Utiliser des processeurs + +Maintenant que nous avons tout apprit sur les valeurs, apprenons à faire des choses malveillantes : voici les `Processeur`s. +Cette annotation sournoise vous permet de configurer votre config et ses valeur, ainsi que d'ajouter des callbacks de modifications, qui vous permettent d'appeler du code quand une valeur est modifiée. +L'annotation fonctionne en vous permettant de désigner du code qui sera appelé à la construction de la config. +D'abord, mettons en place un simple processeur qui écrit dans la console quand la config commence à être chargée. + +`src/main/com/example/example_mod/ExampleModConfig`: + +```java +@Processor("processConfig") +public class ExampleModConfig extends ReflectiveConfig { + public void processConfig(Config.Builder builder) { + System.out.println("Loading config!"); + } + + // ... +} +``` + +Avec ça, notre config écrira "Loading config!" dans la console avant qu'aucune de ses valeurs n'ai été désérialisé. Notez que bien que le nom de la méthode soit passée à `@Processor` sans information sur des paramètres, nous devons quand même mettre un `Config.Builder` dans notre méthode : mais pourquoi ? +Les processeurs peuvent être attachés à trois différents types : des valeurs de la configuration, des sections de la configuration ou des classes de configuration. Dans chacun des cas, le paramètre sera différent comme expliqué dans la Javadoc de `Processor` : + +- Quand utilisé avec une valeur, la méthode du processeur prendra un `TrackedValue.Builder` comme paramètre. +- Quand utilisé avec une section, la méthode du processeur prendra un `SectionBuilder` comme paramètre. +- Quand utilisé avec une classe de configuration, la méthode du processeur prendra un `Config.Builder` comme paramètre. + +Mais on peut faire plus avec les processeur qu'écrire n'importe quoi dans la console ! Voyons ce que l'on peut faire avec cet object `Builder` qui nous a été donné. +Sur les valeur et les classes de configurations, nous pouvons utiliser une méthode appelée `callback` pour mettre en place du code qui est appelé quand la config est modifiée ! + +`src/main/com/example/example_mod/ExampleModConfig`: + +```java +@Processor("processConfig") +public class ExampleModConfig extends ReflectiveConfig { + public void processConfig(Config.Builder builder) { + System.out.println("Loading config!"); + builder.callback(config -> System.out.println("Updated!")); + } + + // ... +} +``` + +Avec cette ligne, on a développé notre logging pour nous dire quand une valeur de la config est modifiée ! Sympa, mais que peut-on faire d'autres avec ces callbacks ? + +Un exemple d'utilisation de callback est de synchroniser entre deux champs de la configuration. Cela pourrait être nécessaire pour plusieurs raisons : la valeur de votre config est compliquée et vous voullez la rendre plus accessible, ou peut-être que vous devez modifier la configuration d'une des librairies dont vous dépendez quand une valeur est modifiée (c'est ce que fait [enigma](https://github.com/QuiltMC/enigma) !). +Nous allons mettre en place un racourcit pour accéder au flux de sortie rendu disponible par `printStream`, cela ne vous force pas à utiliser deux getters pour l'utiliser. Pour faire cela, on va utiliser un processeur appliqué au champ ! + +`src/main/com/example/example_mod/ExampleModConfig`: + +```java +@Processor("processConfig") +public class ExampleModConfig extends ReflectiveConfig { + // ... + public static class AdvancedSettings extends Section { + // ... + @Processor("processPrintStream") + public final TrackedValue printStream = this.value(PrintStreamOption.SYSTEM_OUT); + public transient PrintStream activeStream = printStream.value().getStream(); + + public void processPrintStream(TrackedValue.Builder builder) { + builder.callback(value -> activeStream = printStream.value().getStream()); + } + + // ... + } +} +``` + +En utilisant notre callback, nous mettons à jour la variable `activeStream` à chaque fois que le flux de sortie est changé. Cela le garde parfaitement synchronisé avec le champ `printStream` en tout temps ! Notez que l'on marque cette variable avec le mot clef `transient` qui dit à Java (et donc aussi à Quilt Config !) de ne pas sérialiser la valeur. +Maintenant au lieu de se casser la tête avec `ExampleModConfig.INSTANCE.advancedSettings.printStream.value().getStream()` on peut simplement faire `ExampleModConfig.INSTANCE.advancedSettings.activeStream`, simplifiant nos vie un petit peu quand on utilise la config. Le pouvoir des processeurs en action. + +## Changer le format de la config + +Voyons comment choisir un format de fichier pour sauvegarder votre config. Quilt Config ne fournit pour l'instant que deux sérialisateurs : `json5`, une extension du format JSON qui permet une syntax plus propre et des commentaire, et `toml`, qui est la valeur par défaut. Si vous voulez utiliser `json5`, nous pouvons le faire en utilisant un `Processor` ! +Nous aurons besoin d'appliquer ce processeur globalement à notre configuration comme nous allons changer le format via l'objet `Config.Builder` fournit par un processeur de classe de configuration. + +Ce processeur a besoin d'être appelé avant que la config soit lue donc nous allons le mettre directement sur la classe : + +`src/main/com/example/example_mod/ExampleModConfig`: + +```java +@Processor("processConfig") +public class ExampleModConfig extends ReflectiveConfig { + public void processConfig(Config.Builder builder) { + // ... + builder.format("json5"); + } + + // ... +} +``` + +Avec notre connaissance des processeurs, c'est très simple ! Vous pouvez également utiliser le config builder pour ajouter des nouveaux champs, nouvelles sections et mettre à jour les [métadonnées](../configuration/metadata) en plus de changer le format et utiliser des callback comme nous l'avons déjà montré. + +## Ajouter plusieurs fichiers + +Pour des très gros mods, un seul fichier de configuration peut vite devenir difficile à géré, même découpé en sections. +Heureusement, Quilt Config est designé pour permettre d'ajouter facilement plusieurs fichiers de configuration : par défaut, vos fichiers de configuration sont tous placés dans leurs propres dossiers. +Pour ajouter un deuxième fichier dans ce dossier, nous devons créer une autre classe de configuration : appelons là `ExampleModConfig2`. +Nous devrons aussi changer le nom de notre fichier de config originale pour être plus spécifique : + +`src/main/com/example/example_mod/ExampleModConfig`: + +```java +public class ExampleModConfig extends ReflectiveConfig { + public static final ExampleModConfig INSTANCE = QuiltConfig.create(ExampleMod.MOD_ID, "main", ExampleModConfig.class); +} +``` + +Au lieu d'utiliser l'ID du mod comme nom de notre classe, nous appelons notre config originale `main`. +Maintenant créons une deuxième config : + +`src/main/com/example/example_mod/ExampleModConfig2`: + +```java +public class ExampleModConfig2 extends ReflectiveConfig { + public static final ExampleModConfig2 INSTANCE = QuiltConfig.create(ExampleMod.MOD_ID, "secondary", ExampleModConfig2.class); +} +``` + +La même chose qu'avec notre originale mais en utilisant la classe `ExampleModConfig2` à la place de `ExampleModConfig` partout. Nous l'appelons aussi `secondary` pour aller avec le nom `main` de notre config originale. +Maintenant vous pouvez ajouter les champs que vous voulez ! Avec Quilt Config, vous pouvez répéter ce procédé autant que vous le voulez, tant qu'aucunes des configs n'ont des noms en doublons. diff --git a/wiki/configuration/getting-started/en.md b/wiki/configuration/getting-started/en.md index be768eb7..13384ab5 100644 --- a/wiki/configuration/getting-started/en.md +++ b/wiki/configuration/getting-started/en.md @@ -1,4 +1,4 @@ -# Getting started with Quilt Config +# Getting Started with Quilt Config [Quilt Config](https://github.com/QuiltMC/quilt-config) is Quilt's powerful configuration API. It allows developers (that's you!) to easily set up values that can be changed by the user in order to change the behaviour of your mod. It's built into [Quilt Loader](https://github.com/QuiltMC/quilt-loader) to allow any Quilt mod to leverage it without having to pull in new dependencies or run any setup. diff --git a/wiki/configuration/getting-started/fr.md b/wiki/configuration/getting-started/fr.md index 81dcc524..88e288e5 100644 --- a/wiki/configuration/getting-started/fr.md +++ b/wiki/configuration/getting-started/fr.md @@ -66,7 +66,7 @@ public class ExampleMod implements ModInitializer { Comme le champ `message` est une `TrackedValue` et pas un simple `String`, nous devons appeler sa méthode `value` pour récupérer sa valeur et pouvoir l'écrire dasn la console. Nous pourrons aussi utiliser la méthode `setValue` pour changer la valeur depuis le code. -Maintenant notre mod écrit un message personalisé dans la console au démarage ! Bien que cela nous permettrait facilement d'obtenir 1 million de téléchargements, Quilt Config nous permet de faire beaucoup plus que ça. +Maintenant notre mod écrit un message personnalisé dans la console au démarage ! Bien que cela nous permettrait facilement d'obtenir 1 million de téléchargements, Quilt Config nous permet de faire beaucoup plus que ça. ## Utiliser des annotations @@ -87,7 +87,7 @@ Nous n'allons pas montrer les changements dans le code pour utiliser chacune de - `IntegerRange` est une annotation : elle ajoute un nouvelle fonctionnalité à notre champ, au délà de la déclaration normale. `IntegerRange` nous permet de limiter les valeurs possibles de notre champ `Integer`, pour qu'elles soient contenues entre `min` et `max` (de manière inclusive). - Nous avons changé le type de `String` à `Integer`. Pourquoi `Integer` au lieu de `int` comme nous l'utiliserions pour un champ numérique normal ? `int` est un _type primitif_, ce qui signifie que ce n'est pas une classe ! Comme les generics ne peuvent prendre que des classes, Java fournit des classes pour chaque primitive. `boolean` devient `Boolean`, `float` devient `Float`, `double` devient `Double`, `char` devient `Character`, etc, etc. -Quelque chose de primordial à ne pas oublier est que vous ne pouvez pas simplement mettre n'importe quelle classe dans les generics de `TrackedValue` : Quilt Config doit savoir comment le serialiser. Par défaut, tous les [types primitifs](https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html) sont serialisables ainsi que la classe `String`. Nous expliquerons comment dire à Quilt Config comment serialiser une classe plus tard mais d'abord : plus de fun avec des annotations ! +Quelque chose de primordial à ne pas oublier est que vous ne pouvez pas simplement mettre n'importe quelle classe dans les generics de `TrackedValue` : Quilt Config doit savoir comment le sérialiser. Par défaut, tous les [types primitifs](https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html) sont sérialisables ainsi que la classe `String`. Nous expliquerons comment dire à Quilt Config comment sérialiser une classe plus tard mais d'abord : plus de fun avec des annotations ! Nouvelle valeur ! @@ -121,7 +121,7 @@ Problème résolu ! Maintenant notre champ suit la convention de Java dans le co ## Maps and lists -Deux des structures de données les plus communes utilisées en Java sont les `Map` et les `List`. Quilt Config fournit des versions pratiques et serialisables de ces structures de données avec `ValueMap` et `ValueList` ! +Deux des structures de données les plus communes utilisées en Java sont les `Map` et les `List`. Quilt Config fournit des versions pratiques et sérialisables de ces structures de données avec `ValueMap` et `ValueList` ! En commençant avec les maps, `ReflectiveConfig` nous fournit une méthode `map` pour nous aider à créer une valeur par défaut facilement. diff --git a/wiki/configuration/metadata/en.md b/wiki/configuration/metadata/en.md index 82578a3f..827e2d84 100644 --- a/wiki/configuration/metadata/en.md +++ b/wiki/configuration/metadata/en.md @@ -29,16 +29,18 @@ On startup and when the annotated field is changed, checks if the `String` value - Can only be applied once per member Allows you to set up methods that will run before the config is initialized. Takes a `String` parameter that matches the method name of a method inside your class: this method will be run before config initialization. You must give the method one parameter corresponding to the type annotated with `@Processor`: + - When used on a tracked value, the processor method will take a `TrackedValue.Builder` as its parameter. - When used on a section, the processor method will take a `SectionBuilder` as its parameter. - When used on a config class, the processor method will take a `Config.Builder` as its parameter. Processors allow you to do a large variety of things, including: + - Running custom code when values are edited - Adding new values and sections programmatically - Dynamically updating metadata -You can see example processors and a more in-depth look at their usage in the [advanced configuring tutorial](https://wiki.quiltmc.org/en/configuration/advanced-configuring). +You can see example processors and a more in-depth look at their usage in the [advanced configuring tutorial](../configuration/advanced-configuring#using-processors). ## `@SerializedName` diff --git a/wiki/configuration/metadata/fr.md b/wiki/configuration/metadata/fr.md new file mode 100644 index 00000000..a88f4cf3 --- /dev/null +++ b/wiki/configuration/metadata/fr.md @@ -0,0 +1,64 @@ +# Référence pour les Annotations et les Métadonnées + +Quilt Config est plein d'annotations qui vous permettent toutes d'étendre les fonctionnalités de votre config ! Cette page sert de référence, donnant un apperçu des fonctionnalités de chaque annotation. Des informations plus en profondeurs peuvent être trouvées dans la Javadoc de chaque annotation. + +## `@Comment` + +- Utilisable sur les champs et les sections de configuration +- Peut être répété à l'infini sur un élément + +Vous permet d'attacher des commentaires à vos champs qui sont sauvegardés comme métadonnées. Par défaut ils seront sérialisés dans le fichier de configuration dans les formats `toml` et `json5`. Comme ils sont sauvegardés comme métadonnée, vous pouvez y accéder n'importe où où vous avez acès aux `TrackedValue` pour les champs de votre config, signifiant que vous pouvez les afficher dans des écrans de configuration ou autre. + +## `@FloatRange` et `@IntegerRange` + +- Utilisables sur les champs de configuration de type `Float` et `Integer` respectivement +- Ne peut être utilisée qu'une fois par élément + +Au démarage et quand les champs avec ces annotations sont modifiés, vérifie si les valeurs des champs sont bien contenues entre les `min` et `max` fournient, de manière inclusive. Si ce n'est pas le cas, lance une erreur `TrackedValueException`. + +## `@Matches` + +- Utilisable sur les champs de configuration de type `String` +- Ne peut être utilisée qu'une fois par élément + +Au démarage et quand les champs avec cette annotations sont modifiés, vérifie si les valeurs de ces champs correspondent à l'[expression régulière](https://regexr.com/) fournie. Si ce n'est pas le cas, lance une erreur `TrackedValueException`. + +## `@Processor` + +- Utilisable sur les champs, les sections et les classes de configuration +- Ne peut être utilisée qu'une fois par élément + +Permet de mettre en place des méthodes qui seront appelées avant que la config ne soit initialisée. Prend un paramètre `String` qui correspond le nom d'une méthode dans votre classe : cette méthode sera appelée avant l'initialisation de la config. Vous devez une paramètre à la méthode correspondant au type avec l'annotation `@Processor` : + +- Quand utilisé avec une valeur, la méthode du processeur prendra un `TrackedValue.Builder` comme paramètre. +- Quand utilisé avec une section, la méthode du processeur prendra un `SectionBuilder` comme paramètre. +- Quand utilisé avec une classe de configuration, la méthode du processeur prendra un `Config.Builder` comme paramètre. + +Les processeurs vous permettent de faire une grande variété de choses, comme par exemple : + +- Appeler du code personnalisé quand des valeurs sont modifiées +- Ajouter des nouvelles valeurs et sections via du code +- Changer dynamiquement les métadonnées + +Vous pouvez voir des processeurs d'exemple et une apperçu plus en profondeur de leurs usages dans le [tutoriel de configuration avancée](../configuration/advanced-configuring#utiliser-des-processeurs). + +## `@SerializedName` + +- Utilisable sur les champs et section de configuration +- Ne peut être utilisée qu'une fois par élément + +Ajoute une métadonnée `String` utilisée comme le nom qui sera sérialisé dans le fichier de configuration. Le nom par défaut reste en fallback : si le nom sérialisé n'est pas présent dans le fichier pendant la désérialisation, le nom par défaut sera utilisé. Le nom par défaut sera toujours utilisé pour écrire dans le fichier. + +## `@SerializedNameConvention` + +- Utilisable sur les champs, les section et les classes de configuration +- Ne peut être utilisée qu'une fois par élément + +Ajoute des métadonnées sur la convention de nommage pour chaque champ dans la classe de configuration qui dictent quel convention utiliser pour sauvegarder dans la config. Cela transformera le nom par défaut du champ pour appliquer la convention contenue dans les métadonnées. Si le nom a une annotation `@SerializedName` elle prendra la priorité sur celle-ci. Les options de conventions de nommages sont documentées dans `NamingSchemes`. Quand cette annotation est utilisée sur un champs ou une section dans un parent qui a aussi cette annotation, remplace la valeur du parent pour cet élément seulement (par exemple, si une classe a cette annotation avec une certaine convention et un champs dans cette classe a aussi cette annotation avec une autre convention, le champ prendra la convention de son annotation à lui). + +## `@Alias` + +- Utilisable sur les champs et les section de configuration +- Peut être répété à l'infini sur un élément + +Ajoute des métadonnées précissant d'autres noms pour cet élément. Ces noms seront pris en compte pendant la désérialisation mais ne seront jamais écrit dans le fichier de configuration. Vous pouvez par exemple utiliser cette annotation avec d'anciens noms utilisés pour un champs afin de faciliter la mise à jour des configurations ! diff --git a/wiki/items/armor/fr.md b/wiki/items/armor/fr.md index d855c904..73934bce 100644 --- a/wiki/items/armor/fr.md +++ b/wiki/items/armor/fr.md @@ -58,7 +58,7 @@ public int getEnchantability() { --- Nous allons maintenant définir le son d'équipement de l'armure. -Si vous voulez ajouter un son personalisé, référez vous à [Ajouter des Sons](../misc/sounds). +Si vous voulez ajouter un son personnalisé, référez vous à [Ajouter des Sons](../misc/sounds). Si vous voulez utiliser un son existant, vous pouvez utiliser `SoundEvents.ITEM_ARMOR_EQUIP_GENERIC`, comme dans l'exemple ci-dessous.