Sur Paladium, des milliers de factions et des centaines de milliers de joueurs sont partagés entre des centaines de serveurs, qui peuvent tous modifier la même faction au même instant. Hestia, c'est la bibliothèque qu'on a construite pour tenir cette charge et dans cet article, on vous montre comment.

Le problème

Une faction n'appartient à aucun serveur en particulier. Elle est stockée dans une base de données centrale, et chaque serveur qui en a besoin la lit, la modifie, puis la réécrit. Tant qu'un seul serveur la touche à la fois, tout va bien. Le problème commence quand plusieurs serveurs la modifient en même temps.

Prenons un cas simple. Une faction a 10.000 $ en banque, et deux membres, sur deux serveurs différents, déposent chacun 1.000 $ au même moment.

1. Le serveur A lit la faction, la banque est à 10.000 $.
2. Le serveur B lit la faction au même moment, la banque est toujours à 10.000 $.
3. Le serveur A ajoute 1.000 $, et écrit 11.000 $.
4. Le serveur B ajoute 1.000 $ à ce qu'il avait lu, et écrit lui aussi 11.000 $, par-dessus.

À l'arrivée, la banque affiche 11.000 $ au lieu de 12.000 $. Chaque serveur a fait exactement ce qu'on lui demandait, aucune erreur n'a été levée, et pourtant un dépôt a disparu. C'est ce qu'on appelle une écriture perdue. Et plus il y a de serveurs, plus ça arrive souvent. On l'a mesuré avec 8 serveurs en parallèle qui incrémentent la même factions 2.000 fois, sur ce test nous avons mesuré jusqu'à 86% de perte de donnée.

Il y a aussi un deuxième problème, celui du coût. Pour changer un seul nombre, le serveur réécrit la faction entière, les membres, les grades, les permissions, les claims, etc. Des Ko de données envoyés à chaque modification, multipliés par des centaines de serveurs.

Les solutions habituelles règlent l'un des deux problèmes, jamais les deux.

• Verrouiller la faction le temps de chaque modification. Plus aucune écriture perdue, mais chaque serveur attend son tour, et tout ralentit dès que la charge monte.
• Les transactions optimistes. Le serveur écrit, et si la faction a changé entre-temps, il recommence tout depuis le début. Rien n'est perdu non plus, mais sous forte concurrence, les serveurs passent leur temps à recommencer.
• Dans les deux cas, la faction entière continue de partir sur le réseau à chaque modification.

C'est pour ça qu'on a construit notre propre solution. Et si on en parle aujourd'hui, c'est que le problème n'a rien de propre à Minecraft. N'importe quel système où plusieurs serveurs partagent les mêmes données, un inventaire, un panier, un compte, tombe dessus tôt ou tard.

Redis, en deux mots

Redis, c'est une base de données qui garde tout en mémoire vive plutôt que sur disque. On lui donne une clé, elle renvoie la valeur associée en quelques microsecondes.

Chez nous, chaque faction est un document dans Redis. Tous les serveurs s'y connectent, c'est le point central, la seule source de vérité. Quand un serveur modifie une faction, c'est là qu'il l'écrit, et c'est là que les autres viennent la lire.

Reste une question. Si Redis sait déjà modifier un document champ par champ, pourquoi ne pas s'en servir directement ? Parce que Redis ne connaît pas nos objets complexe. Il sait ajouter 1.000 à un nombre ou insérer un élément dans une liste, mais il faut lui dire précisément quoi faire, champ par champ, à chaque modification.

L'échelle

Pour donner une idée de ce que ça représente chez nous, voici ce que traverse le stockage des factions, sur 9 jours :

• 1.824 factions stockées en permanence, ~20 Ko en moyenne, 380 Ko pour les plus grosse.
• 208 connexions ouvertes en permanence sur le même Redis
• 1,78 milliard de commandes, soit environ 2.300 par seconde, jour et nuit.
• 38,9 millions de lectures de faction, et 4,2 millions d'écriture.
• 124 Go envoyés à Redis, et 16,5 To renvoyés aux serveurs, plus de 20 Mo par seconde en continu.

Hestia

Dans la mythologie grecque, Hestia est la déesse du foyer. Chaque cité avait son foyer commun, un feu qui ne devait jamais s'éteindre, et quand des colons partaient fonder une nouvelle ville, ils emportaient une flamme de ce foyer pour allumer le leur. Un feu central, et partout ailleurs des copies allumées à partir de lui. C'est exactement ce que fait notre projet. Redis est le foyer, la seule source de vérité. Chaque serveur garde sa propre copie des objets, allumée à partir de ce foyer, et toujours synchronisée avec lui.

Concrètement, Hestia est une bibliothèque Java de Shared Object Storage. Tu modifies tes objets Java normalement, tu appelles save, et elle s'occupe du reste :

• Aucune écriture perdue. Les modifications de plusieurs serveurs fusionnent au lieu de s'écraser.
• Atomique. Un objet n'est jamais à moitié écrit, même en cas de coupure au pire moment.
• Plus rapide que la méthode classique. Seul ce qui a changé part sur le réseau, pas l'objet entier.
• Caches locaux synchronisés. Chaque serveur lit ses objets en mémoire, sans aller sur le réseau, et reçoit les modifications des autres en temps réel.
• Verrous distribués. Pour les opérations qui doivent être exclusives, avec une vraie protection si le verrou expire en cours de route.

Comment on l'utilise

Le principe est simple, un objet Java classique, avec quelques annotations.

public class Faction {

    private final String id;

    private long bank;
    private long power;
    @RedisIndex private String name;
    @RedisJsonVersion private long version;
    @RedisJsonOverwrite private long lastActivity;

    @RedisJsonSnapshot
    private transient JsonElement snapshot;

}

Et côté code, rien de plus que ce qu'on écrirait avec n'importe quelle base de données.

final RedisStore<Faction> factions = RedisStore.create(client, RedisStoreConfig.create(Faction.class, Faction::getId));

factions.fetch(id).thenCompose(faction -> {
    faction.setBank(faction.getBank() + 1000L);
    return factions.save(faction);
});

Le développeur ne pense jamais à la concurrence. Il n'y a ni WATCH, ni transaction, ni boucle de nouvelle tentative à écrire. Il modifie son objet, il sauvegarde, et c'est Hestia qui garantit que les 1.000 $ arrivent bien en banque, même si dix autres serveurs touchent la même faction au même moment.

Comment ça fonctionne

Tout repose sur une idée. On n'envoie jamais l'objet, on envoie ce qui a changé, sous une forme que Redis peut appliquer sans risque, même si l'objet a bougé entre-temps.

Le snapshot

Quand un objet est chargé, Hestia garde une copie de son état d'origine, le snapshot, dans le champ @RedisJsonSnapshot. Au moment de la sauvegarde, elle compare l'objet actuel à ce snapshot, champ par champ, et en déduit une liste d'opérations.

Et c'est là que tout se joue. Hestia ne regarde pas seulement si une valeur a changé, elle regarde comment elle a changé.

• Un nombre qui a bougé devient un incrément. La banque est passée de 10.000 à 11.000 ? Hestia n'envoie pas « la banque vaut 11.000 », elle envoie « ajoute 1.000 à la banque ». Deux serveurs qui ajoutent chacun 1.000 donnent donc bien 12.000.
• Un élément ajouté à une liste devient un ajout en fin de liste, pas une réécriture de la liste.
• Un élément retiré d'une liste devient un retrait de cet élément précis.
• Un champ supprimé devient une suppression de ce champ.
• Le reste est écrit à son emplacement exact, et uniquement lui.

Pour les nombres qui ne s'accumulent pas, un horodatage, une priorité, une valeur recalculée, l'annotation @RedisJsonOverwrite dit à Hestia d'écrire la valeur telle quelle plutôt qu'un incrément.

L'exécution

Cette liste d'opérations part dans Redis sous forme d'une exécution. Redis l'exécute d'un seul bloc, sans jamais rien intercaler au milieu. Soit toutes les opérations passent, soit aucune. Il n'existe aucun moment où un autre serveur pourrait voir la faction à moitié modifiée.

Avant d'appliquer quoi que ce soit, Hestia vérifie aussi que chaque opération a encore du sens. Si un autre serveur a supprimé la faction entre-temps, les opérations qui la concernent sont simplement ignorées, plutôt que de la recréer à moitié.

Le résultat, pour un dépôt en banque sur une faction de 16 Ko :

Et comme le patch ne dépend que de ce qui change, l'écart grandit avec la taille de l'objet. Sur un objet de 130 Ko, la méthode classique envoie 133,5 Ko. Hestia envoie toujours 165 octets.

Rejouer sans doubler

Il reste un cas vicieux. Le serveur envoie son patch, Redis l'applique, mais la réponse se perd en route, une coupure réseau, un timeout. Le serveur ne sait pas si son écriture est passée. S'il renvoie le même « ajoute 1.000 », la banque risque de recevoir 2.000.

Chaque patch porte donc un identifiant unique. La première fois qu'il est appliqué, Hestia laisse une marque dans Redis. Si le même patch revient, il le voit la marque et ne fait rien. Hestia peut donc renvoyer un patch autant de fois que nécessaire, il ne s'appliquera jamais qu'une seule fois.

Le cache

Lire dans Redis à chaque fois qu'un serveur a besoin d'une faction, ce serait beaucoup trop lent. Chaque serveur garde donc toutes les factions en mémoire, dans un cache local. La question, c'est comment garder ces caches à jour.

Chaque objet porte un numéro de version, le champ @RedisJsonVersion, incrémenté à chaque sauvegarde, dans le même patch que le reste. Quand un serveur sauvegarde une faction, Redis lui renvoie l'objet complet après fusion, et le serveur le diffuse aux autres avec sa version. Chaque serveur compare cette version à celle qu'il a déjà, et ignore tout ce qui est plus ancien. Peu importe l'ordre dans lequel les messages arrivent, un cache ne peut jamais revenir en arrière.

Et au lieu de relire toutes les factions régulièrement pour être sûr de n'avoir rien raté, chaque serveur ne demande plus que la liste des versions, quelques octets par faction. Il ne relit ensuite que les factions dont la version a changé.

Les verrous

Fusionner les modifications suffit dans l'immense majorité des cas. Mais certaines opérations doivent être exclusives. Un seul serveur à la fois doit pouvoir traiter un retrait de banque pour s'assurer que le solde est suffisant.

Hestia fournit des verrous distribués pour ça. Le problème classique d'un verrou distribué, c'est qu'il expire. Un serveur prend le verrou mais si l'opération prend trop de temps le verrou expire, un autre serveur le prend, puis le premier termine et écrit comme si de rien n'était. Deux serveurs ont écrit sous le même verrou.

client.getLock().withLockWaiting("faction:bank:" + id, token -> factions.fetch(id).thenCompose(faction -> {
    faction.setBank(faction.getBank() - amount);
    return factions.save(faction, token);
}));

En passant le token du verrou à save, Hestia vérifie dans Redis même, au moment exact de l'écriture, que ce verrou appartient toujours à ce serveur. Si ce n'est plus le cas, l'écriture est refusée.

L'envoi

Dernière pièce, la façon dont les commandes partent vers Redis. Il y a deux stratégies classiques. Envoyer chaque commande dès qu'elle arrive, c'est rapide quand il y en a peu, mais chacune attend sa réponse avant de libérer sa connexion. Tout grouper en pipeline, c'est efficace quand il y en a beaucoup, mais tout le monde attend le groupe.

Hestia fait les deux. Tant qu'une connexion est libre, une écriture part directement, depuis le thread qui sauvegarde, sans attendre personne. Quand toutes les connexions sont occupées, les écritures qui arrivent s'accumulent, et partent groupées en pipeline sur la première connexion qui se libère. Plus la charge monte, plus les groupes grossissent, et plus chaque aller-retour réseau est rentabilisé.

Les lectures suivent la même logique, avec en plus de la déduplication. Si cinquante threads demandent la même faction au même moment, Redis ne reçoit qu'une seule lecture, et chacun récupère sa propre copie de l'objet.

Les bench

Tout ça, on l'a mesuré. Hestia face à la méthode classique, un JSON.SET de l'objet complet pour écrire et un JSON.GET pour lire, sur Redis 8.

Le chiffre le plus important, c'est la charge Redis. Avec 16 serveurs en parallèle sur des objets de 130 Ko, la méthode classique sature Redis à 92 %. Avec Hestia, le même Redis encaisse 3,6 fois plus d'écritures, en restant à un cinquième de sa capacité. Ce n'est plus Redis qui limite, c'est le serveur lui-même.

Et face à l'autre méthode correcte, la transaction optimiste (WATCH / MULTI), qui ne perd rien elle non plus mais recommence à chaque conflit, Hestia est près de 4 fois plus rapide. Sur les 2.000 incréments concurrents, la transaction a dû recommencer 10.248 fois. Hestia, zéro.

Pour l'envoi hybride, avec 64 serveurs en parallèle sur de petits objets et une latence réseau de 1 ms, Hestia monte à 15.987 écritures par seconde, contre 7.313 en envoyant chaque commande séparément. Plus de 2 fois plus.

Paladium est l'un des plus gros serveur minecraft français, ouvert depuis 2015, avec plus de 700.000 joueurs uniques et jusqu'à 6.000 connectés en simultané. Comme tout serveur qui grandit, on a dû faire face à la triche, à grande échelle. Nemesis, c'est notre réponse à ce problème, faite maison plutôt que prise toute faite. Dans cet article, on ouvre le capot et on vous montre comment elle tourne.

La triche sur Minecraft

Minecraft fait confiance au client par défaut. Quand le jeu du joueur annonce une position, le serveur l'enregistre, sans vraiment se demander si le déplacement était possible. Pareil en combat, le client signale qu'il a touché quelqu'un, le serveur applique les dégâts. La vitesse, la portée, la cadence des coups, tout repose sur ce que le client veut bien raconter.

Et le jeu est écrit en Java, un langage qui n'a aucune vocation de sécurité par défaut. Son code s'ouvre et se modifie directement. On peut aussi laisser les fichiers tranquilles et injecter du code dans une partie déjà lancée. Ou rester carrément en dehors, avec un logiciel externe qui lit ce qui se passe dans le jeu et agit à sa place.

Deux façons de voir le problème

On peut résumer l'anti-cheat à deux questions.

Est-ce que ce que fait le joueur est physiquement possible ? Le serveur regarde en continu la vitesse, la réaction, la précision, et vérifie que tout ça reste cohérent avec ce qu'un humain peut faire.

Est-ce que la machine du joueur est fiable ? On vérifie en continu l'intégrité du jeu qui tourne, pour s'assurer qu'aucun cheat ne montre au joueur une info qu'il ne devrait pas avoir, même sans toucher à un seul mouvement.

La plupart des serveurs n'ont pas la possibilité d'interagir avec le client comme nous le faisons. Paladium a son propre launcher, et ça change tout. Nemesis peut donc répondre aux deux questions, pas seulement à la première.

Du simple mod au matériel

Tricher, ça va du très simple au très poussé.

• Le client modifié. Le plus courant, on ajoute des mods qui donnent un avantage, avec les mêmes outils que n'importe quel mod légitime.
• L'injection. Le jeu n'est pas touché sur le disque. Une bibliothèque est chargée à la volée dans une partie déjà lancée, la même technique d'injection utilisée par des mods parfaitement légitimes.
• Le cheat natif. Du code bas niveau, hors Java, branché au jeu via la passerelle prévue entre Java et du code natif (JNI). Plus dur à écrire, mais aussi plus dur à repérer avec les outils habituels de détection côté Java.
• La lecture mémoire externe. Un programme complètement séparé, qui lit et modifie directement la mémoire du jeu depuis l'extérieur, sans jamais tourner dedans, comme n'importe quel logiciel utilisateur normal.
• Le driver kernel. La même chose, mais depuis un pilote système avec les privilèges du système lui-même, invisible pour la plupart des logiciels de sécurité classiques.
• Le matériel dédié. Une carte branchée physiquement sur la machine, qui lit la mémoire directement par le bus, ce qu'on appelle du DMA, sans jamais exécuter la moindre ligne de code sur l'ordinateur ciblé.

La philosophie

C'est une philosophie qui traverse tout Nemesis, peu importe le côté, serveur ou client, bloquer autant que possible avant même de parler de sanction. Ça se joue en plusieurs temps. D'abord, on essaie d'empêcher le cheat de fonctionner directement, rendre le mouvement impossible, rejeter le paquet, empêcher l'effet du cheat plutôt que juste le repérer. Si le cheat est trop profond pour être bloqué proprement, le jeu se ferme plutôt que de continuer à tourner dans un état qu'on ne peut plus garantir fiable. La sanction n'arrive qu'en dernier recours, si rien de tout ça n'a suffi. L'idée, c'est de ne pas punir un joueur qui a simplement eu la curiosité de tester un cheat public trouvé sur internet, sans rien faire de spécifique contre Paladium.

Notre protection anti x-ray est un exemple concret de cette philosophie de blocage, côté serveur. Normalement, ton jeu reçoit d'un coup les infos de tous les blocs autour de toi, même ceux enterrés que tu ne vois pas, minerais compris. Un cheat x-ray n'a qu'à lire ces infos que ton jeu possède, et te montrer les minerais cachés. Avec Nemesis, tous les minerais d'un chunk t'arrivent déguisés en simple pierre, et le serveur ne t'envoie le vrai bloc qu'au moment où il devient réellement visible à tes yeux. Le cheat n'a donc rien à lire, l'info n'existe pas encore de son côté.

Il y a un détail technique en plus derrière ça. Pour que ta latence ne crée pas de petit décalage au moment où un bloc devient visible, le serveur anticipe. Il prédit ta trajectoire et ta vitesse, liste tous les minerais que tu pourrais voir, et les envoie en avance dans une zone sécurisée de la mémoire de ton client. Le passage de pierre à minerai se fait donc directement dans ton jeu, au bon moment, sans délai perceptible. Et niveau sécurité, même si un x-ray arrivait à fouiller cette zone, il ne verrait que les minerais tout proches de toi, et seulement pendant un très court moment.

Ce qu'on regarde côté serveur

Cette partie tourne entièrement côté serveur, sans rien demander au client, et répond à la première question posée plus haut. Est-ce que ce que fait le joueur est physiquement possible ?

Le principe est simple. À partir de tous les paquets envoyés par le joueur, le serveur construit un clone numérique de son client, et le simule en parallèle pour vérifier qu'il respecte bien les règles du jeu. On ne fait pas que du calcul de déplacement, c'est une vraie simulation de bout en bout.

Concrètement, c'est un vrai jeu qui tourne en parallèle, sans la partie graphique. Le ping, les TPS, les mouvements, les interactions, tout est simulé. Il faut voir ça comme un deuxième serveur, avec tous les joueurs dessus, qui compare en permanence chaque joueur à son clone. Cette couche sert souvent de garde-fou pour ce que le client aurait raté, mais pour limiter les faux positifs, malgré un taux d'erreur déjà très faible, elle reste très majoritairement soumise à une revue manuelle avant sanction.

Ce qu'on regarde côté client

Reste la deuxième question posée plus haut. Est-ce que la machine du joueur est fiable ? Ici, on ne regarde plus seulement les paquets que le jeu envoie, on regarde son état réel pendant qu'il tourne.

Si on reprend le spectre vu plus haut, un exemple simplifié par niveau :

• Client modifié. Tout ce qui tourne dans le jeu doit correspondre à quelque chose qu'on connaît et qu'on attend. Un mod inconnu ou modifié chez un joueur, c'est un signal.
• Injection. On regarde ce qui est réellement chargé dans le processus du jeu, pas juste ce qui a été lancé au démarrage. Du code qui débarque après coup, sans passer par le chargement normal, c'est un signal.
• Cheat natif. Quand le jeu discute avec du code natif, on surveille ces échanges. Un appel qui n'a rien à faire là, c'est un signal.
• Lecture mémoire externe. On garde un œil sur qui vient lire la mémoire du jeu depuis l'extérieur. Si un accès ne vient pas légitimement du jeu lui-même, c'est un signal.
• Driver kernel / matériel dédié (DMA). Driver kernel ou carte branchée physiquement dans la machine, même combat, on a un contrôle total sur la mémoire dans laquelle le jeu tourne, et donc de quoi détecter tout ce qui la touche. Ça passe par plusieurs vérifications, notamment des copies chiffrées et des hash d'intégrité, qui disent à tout moment si une zone a été modifiée, ou même simplement lue, des try/catch qui réagissent au moindre accès suspect, ou encore des honeypots, des zones volontairement exposées pour piéger qui vient y toucher.

Il y a aussi tout un pan dédié à protéger Nemesis lui-même, pas seulement à repérer la triche. De l'anti-debug à plusieurs niveaux, pour qu'on ne puisse pas brancher un débogueur dessus et l'observer tourner. De l'anti-VM, pour repérer si le jeu tourne dans une machine virtuelle plutôt que sur une vraie machine, un classique pour qui veut analyser tranquillement sans risquer son vrai poste. Et une énumération des process externes, pour savoir ce qui tourne à côté du jeu et repérer les outils d'analyse ou de triche connus.

Ce sont des exemples volontairement simplifiés. En réalité, Nemesis embarque plus de 40 vecteurs de détection différents, mis à jour tous les jours. Et c'est presque jamais blanc ou noir. Le plus souvent, une détection est un score cumulé sur plusieurs signaux, avec des centaines de micro-facteurs qui comptent pour chaque chose.

Ce qu'on regarde pour les doubles comptes

Un ban qui saute juste en recréant un compte, ça ne sert à rien. Cette partie répond à cette question précise. Comment savoir que deux comptes différents sont en réalité le même joueur ? La détection s'appuie sur un score qui agrège un grand nombre de vecteurs, matériels et logiciels, croisés ensemble plutôt que jugés un par un.

Côté matériel, l'idée est de rattacher une sanction à la machine, pas seulement au compte. Il y a d'abord une vraie liste d'identifiants classiques, le disque, la carte mère, et une dizaine d'autres composants au total. Rien d'exotique, c'est le genre de HWID que la plupart des anti-cheats sérieux utilisent.

Et puis il y a un étage plus poussé, actuellement en test chez certains joueurs, qui s'appuie sur un vrai concept de recherche académique, la PUF (Physically Unclonable Function). Même deux composants strictement identiques, sortis de la même chaîne de fabrication, ne sont jamais parfaitement identiques au niveau physique. Les tolérances de fabrication créent des micro-variations invisibles à l'œil mais mesurables électriquement. Sur la RAM, ça se traduit par deux approches connues dans la littérature, mesurer le temps de décroissance naturel d'une cellule mémoire une fois qu'on arrête de la rafraîchir, ou mesurer les micro-latences d'accès en lecture et en écriture. Dans les deux cas, le résultat dépend directement des propriétés électriques réelles des transistors de cette barrette précise, impossible à reproduire ailleurs par du logiciel. Même logique côté micro. Chaque microphone a une réponse en fréquence légèrement différente, due aux tolérances de fabrication de sa membrane et de sa capsule. En captant un court échantillon audio et en analysant cette courbe de réponse, on obtient une signature propre à cet exemplaire précis de microphone, même face à un modèle strictement identique sorti de la même usine. Dans les deux cas, c'est une empreinte qu'on ne change pas en réinstallant Windows ou en recréant un compte, elle est littéralement gravée dans le matériel. La RAM et le micro ne sont d'ailleurs que la partie émergée de cette recherche. Derrière, on creuse le fonctionnement le plus profond d'une machine, avec un vrai travail de recherche, pour inventer des identifiants qui n'existent littéralement nulle part ailleurs.

Petit fun fact au passage, un de ces tests a fini par griller une carte graphique, une carte de dev, sur laquelle ce risque était attendu et assumé. On teste vraiment, en conditions réelles, sur des pistes très peu documentées, voire pas du tout. C'est précisément ce genre de travail qui pousse Nemesis au niveau le plus haut possible. Et pour être clair, il n'y a jamais eu le moindre risque pour les joueurs là-dedans, ce genre de chose ne passe jamais en production avant d'avoir traversé un paquet de paliers de test.

Côté réseau, on ne compare pas juste deux adresses IP identiques. La corrélation se fait par géolocalisation et par score de probabilité. Des comptes qui se connectent régulièrement depuis des zones cohérentes entre elles pèsent plus lourd dans le score qu'une simple coïncidence d'adresse. On détecte aussi les IP non résidentielles, typiquement des VPN ou des proxys utilisés pour masquer une connexion. Et il y a le reste, empilé avec tout ça, l'historique de pseudo et de skin d'un compte, sa date de création, le fait qu'il se soit déjà connecté sur d'autres serveurs, la façon de jouer elle-même, parce qu'un même joueur garde ses habitudes d'un compte à l'autre. Pris séparément, aucun de ces signaux ne suffit, mais empilés, ça pousse l'analyse très loin. Un compte qui coche trop de ces cases est automatiquement flag, il passe sous surveillance, avec une analyse manuelle plus poussée derrière, et peut se retrouver soumis à des restrictions invisibles ou à des tests aléatoires, sans jamais le savoir.

On est d'ailleurs assez confiants dans ce système pour avoir désactivé les bans par IP. On ne sanctionne plus que par empreinte matérielle, ce qui garantit le meilleur niveau de sécurité sans jamais pénaliser un foyer entier ou un joueur qui hérite d'une IP réattribuée par son fournisseur.

De la détection à la sanction

C'est la partie que les joueurs vivent le plus directement, autant être clair. Comme on l'a vu, le système bloque avant de sanctionner, et une détection ne bannit personne automatiquement par défaut. Avant qu'un vecteur ait le droit de sanctionner sans intervention humaine, il passe par une phase de validation qui peut durer plusieurs mois, réglages, confrontation à des cas réels, observation dans la durée. Le seuil est strict, au moins un mois consécutif sans le moindre faux positif avant toute automatisation. Et rien n'est figé. Maintenance, mises à jour, sécurité, des détections sont retirées, désactivées un temps ou ajoutées, à intervalles pas toujours prévisibles. Le système change presque tous les jours sans que ça se voie de l'extérieur.

Le délai entre détection et sanction va de quasi instantané à environ 24 heures, selon la gravité du cas, cumulée avec un facteur aléatoire. Ce facteur empêche les développeurs de cheat de corréler le moment de la sanction avec ce qui l'a déclenchée. Un délai fixe après le même type d'action leur dirait ce qui a été repéré. Les sanctions quasi instantanées sont réservées aux cas qui présentent un risque direct pour l'expérience d'autres joueurs. Par exemple, un tricheur sur le point de tuer ou de piller un autre joueur. Dans ce cas, protéger cet autre joueur en temps réel passe avant la protection contre la corrélation. La vraie condition est plus complexe que ce simple exemple. Plein de facteurs rentrent en compte pour garantir la sécurité malgré tout, mais l'idée reste toujours de trouver le bon curseur.

Résultat, sur plus d'un an d'utilisation réelle, un taux de faux positif proche de zéro. On ne prétend pas à la perfection, personne ne le peut honnêtement. Mais au moindre doute, le cas part en revue humaine plutôt qu'en automatique. C'est plus lent, on l'assume. Un joueur banni à tort coûte bien plus cher en confiance que le temps passé à vérifier.

Et si une sanction est contestée, on ne répond pas sur parole. Tous les logs de détection sont conservés, et anonymisés. Ils gardent le contexte technique du cas, ce qui a déclenché la détection et dans quelles conditions, détaché de l'identité du joueur. Quand une contestation arrive, on reprend le cas intégralement à partir de ces logs. On rejoue ce que le système a vu et on revérifie chaque étape, avec un humain aux commandes. Si la détection tient, la sanction tient. Si quelque chose cloche, elle saute.

En chiffres

Sur les six derniers mois :

• 8.900 détections, tous vecteurs confondus (plusieurs peuvent concerner un même joueur).
• 1.124 sanctions automatiques, appliquées sans intervention humaine.
• 2.020 bans pour triche au total, depuis la mise en place du système.
• Un délai moyen de détection de 193 secondes.

Côté ingénierie, pour Nemesis au global, +1.500 commits, pour plus de 57.000 lignes de code au total.

La suite

La direction pour la suite, un programme complètement à part du jeu, avec un composant qui tourne au niveau du noyau, donc au même niveau de privilège que l'OS lui-même. C'est le chemin qu'ont pris les anti-cheats les plus poussés sur d'autres jeux (Vanguard chez Riot, EasyAntiCheat, BattlEye), pour une raison simple. À ce niveau, on voit l'état réel de la machine sans dépendre de ce que Windows ou un programme utilisateur veut bien montrer, et le composant peut être actif avant même que le jeu soit lancé.

Un programme séparé du jeu, à ce niveau de privilège, enlève des contraintes inhérentes à toute vérification qui tourne dans le même processus que ce qu'elle surveille. C'est aujourd'hui un chantier de recherche et développement. Ça ne va pas rajouter un meilleur niveau de détection, celui-ci est déjà là où il doit être. Ça va surtout permettre un travail plus simple, pensé pour durer sur le long terme.

La transparence

Aujourd'hui nous publions cet article parce que les joueurs de Paladium ont le droit de comprendre, au moins dans les grandes lignes, ce qui tourne sur leur machine. La confiance se gagne en montrant le travail, pas en le promettant. Ensuite parce qu'on est fiers de ce qu'on a construit. On estime que Nemesis est aujourd'hui le meilleur anti-cheat Minecraft existant. C'est une opinion, on l'assume. Et ça nous semblait valoir le coup de le raconter, même en partie.

On ne compte pas s'arrêter là. À moyen terme, on prévoit de mettre en place un système d'audit externe, des personnes extérieures à Paladium qui viendront vérifier ce qu'on affirme ici, régulièrement. Sur le long terme, on réfléchit aussi à ouvrir tout ça au plus grand nombre. Rien de concret à annoncer pour l'instant, juste une intention, celle de rendre ce sujet plus accessible et plus partagé.

Merci

Merci à Paladium pour la confiance et pour l'opportunité de mener un projet comme celui-ci depuis le début.

Cet article n'est ni une incitation à la triche, ni une provocation envers qui que ce soit. On documente simplement ce qu'on a construit, parce qu'on aime ce travail et qu'on a envie de le partager.

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Corrections

• Correction de l'hud de l'armure qui persistait lorsqu'on mourrait.
• Correction de l'hud de l'armure qui ne retirait pas les bonnes pièces d'armure lorsqu'on les retirait depuis son inventaire.
• Correction de l'indicateur du canal du chat actuel qui avait des instabilités
• Correction du bug de duplication
• Correction des effets force, faiblesse et résistance
• Correction des stats de certains outils/armures vanilla
• Correction du /craft
• Correction des rtp en minage
• Correction du seedplanter qui ne perdrait pas de durabilité lors de son utilisation
• Correction de l'effet speed qui ne fonctionnait plus lorsque le joueur était téléporté

Modifications

• Modification du chat qui peut désormais être positionné en bas à gauche de l'écran selon ce qui a été choisi dans les paramètres (/settings)
• Modification de l'indicateur du canal de chat du joueur qui est désormais accroché au chat

Préparez vos bases, rassemblez vos membres et affûtez vos armes : le gameplay faction de Paladium s’apprête à évoluer !

Gestion de faction, progression collective, organisation des bases, classements et nouveaux défis… De nombreuses nouveautés arrivent pour donner davantage de profondeur à la vie en faction.

Mais ce n’est pas tout ! Les donjons vont également devenir plus dangereux avec l’arrivée de nouveaux mini-boss et boss prêts à défendre leurs trésors.

On vous fait visiter tout ça ? Allez, suivez-nous !

Une nouvelle interface de faction

L' interface de faction a été entièrement repensé afin de regrouper plus clairement toutes les informations importantes : membres, classement, banque, Arbre de technologie, régions et annuaire.

Chaque faction pourra customiser son propre blason depuis une interface dédiée ou bien importer des images/Gif.

L’arbre de technologie

Les factions disposeront désormais de leur propre arbre de technologie.

En accomplissant des objectifs collectifs, en réunissant des ressources et en investissant l’argent de la faction, les joueurs pourront débloquer progressivement de nouveaux objets, blocs et avantages.

L’arbre sera divisé en plusieurs branches, notamment :

• Pillage
• Défense
• Global

Chaque membre pourra ainsi contribuer à la progression de la faction.

Une gestion des membres plus personnalisée

Le système de grades permettra de personnaliser précisément les permissions accordées à chaque membre.

Les responsables de faction pourront également créer des régions à l’intérieur de leurs claims et définir quels grades peuvent construire, casser des blocs ou interagir dans chaque zone.

Un système de ligues pour les factions

Les factions pourront désormais se mesurer les unes aux autres grâce à un nouveau système de ligues.

Leur activité et leurs performances leur permettront de progresser dans le classement et d’atteindre des divisions toujours plus prestigieuses.

Une refonte du chat

Le chat évolue afin de rendre les échanges entre joueurs plus vivants, en un simple coup d'œil vous pouvez voir le rang/le logo de faction et le serveur ou se trouve le joueurs dans le chat.

Du nouveau dans les donjons

Les donjons s'enrichissent de nouveaux sons pour tout les monstres pour donner plus de vie à vos combats, 12 nouvelles salles de combat ont été ajoutées ainsi que de nombreux nouveaux mini-boss et boss.

En parallèle, un travail d’équilibrage des récompenses a aussi été effectué afin de mieux répartir les drops dans les donjons et garantir une progression continue.

Les donjons intégreront également un système de notes, permettant d’évaluer les performances des joueurs à la fin de leur run. Les jarres disséminées un peu partout dans chaque salle permettront améliorer cette note.

Un système de matchmaking

Les donjons profiteront aussi d’un système de matchmaking.

Les joueurs pourront ouvrir un groupe ou et permettre à d’autres joueurs inconnu de le rejoindre afin de partir plus facilement en donjon.

6 sorts à récupérer

Les donjons permettront aussi d’obtenir 6 sorts différents à récupérer en jeu. Ces sorts seront répartis en 3 raretés, ajoutant une nouvelle couche de progression et de récompense à l’exploration des donjons.

Des niveaux de difficulté à débloquer

Chaque donjon proposera plusieurs niveaux de difficulté pour récupérer de meilleur récompense.

Le joueur devra d’abord terminer le donjon une première fois en facile pour débloquer le mode normal, puis terminer le mode normal pour débloquer le mode difficile.

Préparez votre faction, organisez vos membres et équipez-vous : de nouveaux défis vous attendent sur Paladium V12 !

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Corrections

• Correction de l'Infernal Knocker sur les joueurs
• Correction de l'invitation des joueurs en donjon
• Correction de la compétence "Expert Légendaire" sur la LG de chaos

Optimisations

• Optimisation significative des drawers
• Optimisation du système d'achievement
• Optimisation de l'utilisation de netty dans le réseau

Ajouts et modifications

• Ajout du voicechat sur tous les serveurs
• Ajout d'une zone "Casino" sur le serveur Aeloria (ouverture à 17h)
• Modification du temps d'invocation du Wither Supreme (24h -> 12h)

Suppressions et désactivations

• Retrait de l'évent noel
• Retrait du donjon frigoria
• Désactivation de l'enchantement knockback

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Corrections

• Correction de la position de téléportation avec un /tpa ou /home si la position se trouve dans les airs
• Correction de pouvoir mettre un home sous la bedrock
• Correction de pouvoir définir une balise de ciblage au-dessus de la couche 256
• Correction de l'impossibilité de switch un wither bloqué par une frozen obsidian

Optimisations

• Optimisation du serveur en cas de nombreux joueurs
• Optimisation des Falling Block (désactivation de l'animation)
• Optimisation des spawner controller en mode automatique

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Corrections

• Correction du voice chat qui se désactive lors d'un passage sur un serveur sans le voice chat activé
• Correction d'un crash quand un joueur parle avec le voice chat dans certains cas rares
• Correction d'un crash OpenGL avec le rendu des flèches plantées dans le corps qui causait d'énormes chutes de FPS et problème d'affichage
• Correction de l'affichage de l'armure antique avec le voice chat
• Correction de l'affichage des armures RPG avec le voice chat
• Correction du wither prédateur ne cassant pas les blocs avec les projectiles
• Correction de l'affichage de l'armure vanilla avec le voice chat
• Correction de la bonne actualisation de la position d'un wither après une Switch Arrow
• Correction des soucis de connexion Microsoft sur le launcher
  

Ajouts et modifications

• Ajout de messages d'erreurs plus précis dans l'utilisation d'une Switch Arrow
• Ajout d'un cooldown entre les messages similaires
• Ajout d'un cooldown entre chaque /msg
• Désactivation du HangGlider au-dessus de la couche 256
• Désactivation de pouvoir contrôler un wither au-dessus de la couche 256
• Désactivation de pouvoir voler avec l'effet superman au-dessus de la couche 256
• Désactivation de pouvoir voler avec un balai au-dessus de la couche 256
• Désactivation de pouvoir voler avec un ravirok au-dessus de la couche 256
• Désactivation de l’aimant en warzone
  

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Correction

• Correction de pouvoir utiliser des commandes en étant mute en changeant les majuscules

Ajout et modification

• Mise en test du système de voice chat sur les serveurs de donjon
• Ajout d’un son lors du switch d’un wither (uniquement pour le joueur qui switch)
• Modification de l’effet de nausée avec une Switch Arrow
• Modification du comportement de la Switch Arrow, celle-ci téléportera le wither à l’emplacement d’où elle a été tirée

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Équilibrage Wither suprême

• Réduction du temps de vie passée à 15 min
• Rayon d'explosion réduit à 12.5b
• Dans la zone du réceptacle à Wither, l'utilisation de la foreuse et du Giant fish est désactivé
• Le réceptacle à Wither ne peut être posé qu'à partir de la couche 5 ou plus
• Cooldown de 24h par faction pour l'invocation d'un Wither suprême

Corrections

• Correction du nombre de slots de rune sur les armures Frigoria
• Correction de l'application des runes sur les armures ne possédant pas de slot de rune
• Correction de la possibilité de réparer les équipements frigoria avec les différentes essences du donjon
• Correction de certains "fatal error"
• Correction de crash lors du /lobby
• Correction d'un délai de 5s à la connexion d'un serveur
• Correction d'erreurs de synchronisation (#requesting) lors d'un changement de serveur
• Correction du gain des cosmétiques dans les box
• Correction de la perte du contenu du backpack avec la gamerule keepInventory
• Correction de crash avec le bloc "Couronne de Noël"
• Correction de pouvoir voler en retirant l'armure antique
• Correction du clear de cadeau en changeant de serveur
• Correction de la limite de caractères dans les macros BetterNEI

Ajouts et modification et amélioration

• Modification du système de pousse des plantations
• n'est plus soumis au nombre de joueurs
• augmentation de la vitesse des plantations vanilla (+17%)
• fonctionne dans tous les chunks autour du joueur (3x3)
• Amélioration des outils internes de schematics
• Amélioration des outils de modération
• Amélioration de la synchronisation
• Ajout du marteau antique
• Amélioration de certains messages d’erreurs
• Amélioration de l’anticheat
• Modification du prix des blaze rod

Optimisations

• Optimisation majeure de la synchronisation

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Optimisations

• Optimisation des serveurs donjons
• Optimisation de l'utilisation des machines
• Optimisation majeure des serveurs
• Optimisation de la synchronisation des EEP
• Modification de la stratégie de déploiement automatique des serveurs

Corrections

• Correction de la détection des clés renommées dans les donjons
• Correction de l'affichage des tooltips d'item dans la popup d'inspection de drawer au /ah
• Correction d'un bug de metadata avec les portes
• Correction des points de sort gagnés en montant de niveau (0.2 -> 1)
• Correction du niveau requis pour les backpack
• Correction d'un crash avec le baby wither
• Correction de pouvoir mettre l'enchantement fake water protection sur un item incassable
• Correction du /agenda
• Correction du "press %s to open inventory"
• Correction de pouvoir rejoindre le serveur Farmland-Edit
• Correction d’un crash dans l’inventaire créatif
• Correction d'un crash avec les armures des donjons lors du changement de serveur
• Correction de l'achat d'items à l'adminshop avec un inventaire plein
• Correction de serveurs bloqués à 0 joueurs
• Correction du lobby-afk
• Correction du bon démarrage automatique des SOD (Server On Demand)
• Correction de l'affichage et du reset du classement hebdomadaire des donjons
• Correction de l'évent luckyblock "Divinity Grade"
• Correction majeure de la synchronisation
• Correction de crash sur les serveurs donjons
• Correction de pouvoir poser des "town market" en dehors de son village de faction
• Correction du nombre max de "town market" dans son village de faction
• Correction de la consommation du bloc "town market" lors de l'utilisation
• Correction d'un mauvais gain d'exp dans les bouteilles de métier
• Correction du prix minimum lors de la mise en avant au /market
• Correction de pouvoir rejoindre un serveur en cours de redémarrage

Ajouts et suppressions

• Suppression du gain d'XP de faction lorsqu'on place un "town market"
• Suppression du gain d'XP de faction lorsqu'on claim un AP
• Ajout des cosmétiques de noël
• Ajout de la box antique
• Ajout du serveur /noël
• Ajout du marteau antique
• Ajout du donjon "frigoria"
• Ajout de sécurité sur le démarrage d'un serveur en cas de soucis de synchronisation
• Ajout d'une sécurité pour ne pas pouvoir lancer un donjon en cas de redémarrage

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Optimisations

• Optimisation des serveurs factions
• Optimisation du serveur donjon
• Optimisation du serveur warzone
• Optimisation des lobby

Corrections

• Correction de l'application des stats de rune en serveur autre que donjon
• Correction du niveau max de donjon qui ne se met pas toujours à jour
• Correction de l'affichage du tooltip rpg dans la page "sell" du market
• Correction de différents crashs liés aux donjons
• Correction du niveau de déblocage du chervil et kiwano
• Correction d'un écran noir lors de la mort dans les donjons
• Correction du niveau requis pour craft le totem fleuri
• Correction des jetons de métiers
• Correction de l'impossibilité de pouvoir /f sethome
• Correction de l'application de statistiques RPG en serveur autre que RPG
• Correction de la hauteur du tooltip RPG
• Correction de la difficulté du donjon si un joueur quitte
• Correction d'outils de modération
• Correction de la dimension mineur
• Correction du palier de donjon requis pour la capture stone
• Correction du déblocage des "barn fence"
• Correction de l'essence requise pour réparer l'épée vitalys

Ajouts et suppressions

• Modification de la taille des sacs à dos de donjon
• Ajout de l'affichage des statistiques de rune dans le Market
• Désactivation de pouvoir mettre en bouteille l'XP de métier des donjons
• Suppression des notifications de démonstration de Minecraft
• Modification du nombre de runes par équipement (3 -> 1)
• Modification des stats de base des runes
• Ajout du give automatique de 5 keyring pour les grades divinité
• Modification du message d'erreur quand le chat est désactivé
• Désactivation de l'attaque "magnet" du donjon Nimbria si le joueur est déjà attiré par une autre entité
• Ajout de paramètres pour mieux gérer le nombre d'entités dans les salles donjons
• Modification du nombre de mobs dans les salles de donjon
• Retrait du niveau requis pour utiliser l'autoclick Helios
• Modification des loots de la zone de capture
• Modification des loots des largages

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Optimisations

• Modification du nom des serveurs dans le chat
• Ajout de nouvelles astuces dans les donjons
• Modification de la fréquence des astuces dans les donjons
• Affichage de la popup "skip" dans les donjons même si la salle est terminée
• Ajout du type de serveur en gold dans le chat si c'est le serveur actuel
• Désactivation de la commande /rpg profile hors du serveur donjon
• Affichage de la durabilité sur le tooltip des items rpg ( si F3 + H activé)
• Modification des trades du marchand "Mammon" dans les donjons
• Optimisation de la recherche de joueurs dans le donjon
• Ajout d'un overlay quand on est sous poison dans le donjon
• Désactivation des enderpearl en donjon
• Ajout de la possibilité d'ouvrir le market dans le hub du donjon

Corrections

• Correction de pouvoir signaler un message depuis n'importe quel serveur
• Correction de l'ouverture "10 + 1" clé dans les box
• Correction de ne pas recevoir la clé de box si l'inventaire était plein
• Correction des grades heros, legend, divinity pour lesquels les permissions ne fonctionnaient pas
• Correction de ne pas pouvoir accepter une invitation de donjon depuis un serveur faction
• Correction d'un crash en rejoignant les donjons
• Correction d'une mauvaise téléportation en faisant /spawn dans un donjon
• Correction du nombre de joueurs dans le tab
• Correction de l'affichage des armures de donjon avec des cosmétiques
• Correction du blocage de certains items en donjon
• Correction du déblocage des crafts avec les parchemins
• Correction d'un double affichage dans l'arbre de compétence donjon
• Correction de l'état de mort des monstres corps à corps du donjon Manélios
• Correction de certains portails ne fonctionnant pas dans les salles donjons
• Correction de la description de l'effet d'invisibilité sur l'armure antique
• Correction de certaines salles de combat ne se terminant pas automatiquement une fois tous les monstres tués
• Correction du nombre de joueurs dans le tab en serveur donjon
• Correction d'un crash en fusionnant 2 runes sans stats en commun
• Correction du gain d'expérience des familiers en montant de niveau de métier
• Correction du gain d'expérience faction en montant de niveau de métier
• Correction de pouvoir ouvrir le market avec le @p dans le chat dans les régions où le /market est désactivé
• Correction du niveau requis pour utiliser le cavern hammer
• Correction des prérequis "tuer [...]" avec les custom spawner
• Correction du niveau requis pour utiliser l'autoclick
• Correction du niveau requis pour craft la sealed xp bottle
• Correction de l'animation dans l'interface de fin du donjon
• Correction de l'affichage du monstre Nimbria volant

Équilibrage :

• Augmentation du nombre de monstres dans les donjons (par salle)
• Augmentation des points de vie des Boss et Miniboss dans les donjons (tous les donjons sauf Vitalys)
• Augmentation des chances d'apparition des monstres distance (par salle)
• Réduction de l'apparition des armures/épée dans les coffres
• Réduction de la durabilité des armures de donjon
• Réduction de la durabilité des épées de donjon
• Réduction des gains d'XP de donjon
• Réduction des gains d'XP métier obtenue via les donjons
• Amélioration du délai d'attaque des monstres des donjons
• Amélioration de la vitesse des monstres des donjons
• Modification des stats des sets d’armures des donjons
• Modification du knockback des monstres des donjons
• Modification des prix de l'adminshop

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Optimisations

• Désactivation de l'anti-afk dans les spawn
• Optimisation de la recherche de BetterNEI
• Désactivation du home de faction dans les AP
• Désactivation de la foreuse dans les AP

Corrections

• Correction d'un problème de rendu avec les dégradés de couleurs
• Correction de l'application des réductions dans le shop
• Correction de la formule de l'adminshop
• Correction du give des cosmétiques dans la box en endium
• Correction du freeze lors du passage en fullscreen (f11)
• Correction du renouvellement du grade premium dans la boutique IG
• Correction d'un crash de BetterNEI lors d'une interaction avec un PNJ
• Correction d'un bug de duplication avec le luckystats
• Correction du cap du KOTH sur le toit
• Correction de l'impossibilité d'utiliser la LG de Chaos dans la phase de PVP Sans Restriction
• Correction de la possibilité de claim en combat
• Correction de différents crash serveur

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Optimisations

• La zone de capture donnera maintenant 1 de gloire de faction toutes les 3 minutes
• Désactivation de l'endium caveblock en f5
• Désactivation des moon piece dans le spawn du serveur WarZone
• Modification du nombre de point de l'endium nugget ore dans la dimension mineur (600 -> 501)
• Modification du système de reward du palashop
• Mise à jour majeure du framework d'interface (zephyr-ui)
• Modification du système de reward du classement Summer Rush
• Désactivation de la possibilité de réparer les rollers
• Modification de la phase PVP Boosté : speed & jump -> force 3
• Déplacement de la zone de capture dans la zone pvp
• Obligation de devoir être sur le sol pour pouvoir capturer la zone de capture

Corrections

• Correction de crash serveur
• Correction de la récompense hebdomadaire du summer rush
• Correction d'une mauvaise réduction de dégâts avec une armure abimée

Ajouts et suppressions

• Suppression de l'event luckyblock "roller"
• Ajout d'un craft sur les rollers
• Ajout d'un cooldown de 3 minutes pour pouvoir retourner dans la zone pvp après sa mort

Un wiki complet est mis à votre disposition. Vous pouvez vous y référer pour le fonctionnement des nouveaux items.

Optimisations

• Optimisation du serveur et du réseau
• Amélioration de la synchronisation
• Amélioration d'outils internes
• Désactivation du rendu du feu sur le largage

Corrections

• Correction du nom des interfaces de backpack
• Correction d'un bug de position à la couche 256
• Correction du wither assoiffé avec les slimepad