Effets d'écran et tables de butin : les deux moitiés d'un même coffre
Les poids d'une table de butin déterminent ce qui tombe ; la commande /posteffect détermine le ressenti. Dans les deux cas, ce sont des chiffres à vérifier avant d'écrire le datapack.
Une table de butin pondérée et une commande /posteffect s'écrivent généralement dans des fichiers différents par des personnes différentes, et elles échouent de la même manière : les chiffres ne sont jamais vérifiés avant la publication du datapack. Dans les deux cas, la vérification préalable coûte peu.
La table de butin, c'est de l'arithmétique, pas de l'intuition
Une entrée de table possède un weight, et la probabilité d'une entrée correspond à son poids divisé par la somme de tous les poids de cette table. Il n'y a ni normalisation cachée ni minimum — un poids de 0 signifie que l'entrée ne tombe jamais, et une table dont les poids totalisent n'importe quelle valeur se comporte de la même façon. Le piège, c'est de mélanger les tirages : une table avec rolls: 2 effectue deux tirages, donc une entrée représentant un quart du poids apparaît dans environ la moitié des coffres, et non un quart.
| Entrée | Poids | Part d'un tirage |
|---|---|---|
| Lingot de fer | 20 | 20 ÷ 40 = 50 % |
| Lingot d'or | 12 | 30 % |
| Diamant | 8 | 20 % |
Ajoutez une quatrième entrée de poids 40 et tous les chiffres ci-dessus sont divisés par deux. Tout l'équilibrage tient là, et c'est pourquoi « le taux de diamants semble bizarre » correspond presque toujours à un poids que vous avez oublié de recalculer.
Les tables de butin constituent l'une des plus grandes familles de registres du jeu — les données 26.3 mesurées sur ce site en recensent 1 447 — donc une table que vous ne pouvez pas raisonner numériquement est une table que vous ne finirez jamais de régler à la main.
/posteffect est nouveau dans Java 26.3
La commande /posteffect de Java est apparue en version stable dans la 26.3 et n'existe pas dans la 26.2 ni avant. C'est une commande Java, et Bedrock n'a rien portant ce nom, donc un tutoriel Java ici ne sera pas transposable.
La commande ajoute ou retire un effet d'écran par identifiant sur un ensemble de joueurs — /posteffect add <targets> <effect>, plus remove, clear <targets> et list <target> (un seul joueur). Il n'y a pas d'argument de puissance : un effet est actif ou inactif. Le client vanilla n'en propose que cinq — blur, creeper, entity_outline, invert et spider — la liste d'identifiants est donc assez courte pour être vérifiée à la main plutôt que devinée. Nommer un effet inexistant renvoie quand même un succès, car le serveur ne le vérifie pas : c'est la seconde raison de vérifier avant de valider.
Là où les deux se rejoignent
Un coffre qui lâche un objet rare et un coffre qui lâche un objet courant ne devraient pas avoir la même apparence. Tirez d'abord dans la table pour obtenir la distribution réelle, puis choisissez l'effet d'écran correspondant à la fréquence à laquelle le joueur le verra réellement. Faire l'inverse produit un effet spectaculaire qui se déclenche en permanence, ce qui est perçu comme du bruit.
Pour une construction de village, cela signifie généralement un effet discret comme blur sur la table courante et un effet spectaculaire comme invert réservé à l'entrée de plus faible poids — le même ratio que vous avez déjà calculé.
Construisez la commande /posteffect et tirez dans la table pondérée dans les Outils d'effets d'écran et de butin.